基于函数计算的 BFF 架构

什么是 BFF

BFF 全称是 Backends For Frontends (服务于前端的后端)，起源于 2015 年 Sam Newman 一篇博客文章《Pattern: Backends For Frontends —— Single-purpose Edge Services for UIs and external parties》。

微服务和前后端分离的流行，在后端服务边界上通常会有一个 API 层，向下调系统内的多个微服务，经过聚合、适配和裁剪等一些列的处理后，向上为前端提供 HTTP 协议的 API。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YnEirFFV-1585817798409)(https://data-analysis.cn-shanghai.log.aliyuncs.com/logstores/article-logs/track_ua.gif?APIVersion=0.6.0&title=%E5%9F%BA%E4%BA%8E%E5%87%BD%E6%95%B0%E8%AE%A1%E7%AE%97%20BFF%20%E6%9E%B6%E6%9E%84&author=%E5%80%9A%E8%B4%A4&src=article)]

然后随着移动端的兴起，出现了 H5、iOS 和 Android 等多端并存的开发场景，由于移动端的屏幕尺寸比较小，所以显示的信息和传统 Web 端会有较大的区别，而且移动端对于访问连接数和数据量也有更高的要求。此时通用 API 层的开发就会碰到一些困境，比如需要为不同的端提供不同的 API。而这些 API 的设计与不同端上的展示逻辑相关性较强，所以不太适合由后端团队或者 API 团队来负责。因为这些 API 的维护人员会夹在前后端之间去做协调和取舍，非常的心累。

Sam Newman 先后在 REA 和 SoundCloud 两家公司实践了为不同的端做独立的 Backend API，称之为 BFF。以解决不同端对 API 的差异化需求的问题。

BFF 的好处

历史遗留业务支撑

一些老系统的接口规范可能比较陈旧，比如说不是 Restful 的。借助于 BFF 层做一些接口转换，更好的适配端上技术发展的需求。

协调稳定的中台和多变的端需求

端上变化快主要体现在两个方面：

技术革新：端上的技术更新比较快，js 框架层次不穷。移动端也有很多选择，有 H5、Java/OC、Kotlin/Swift、React Native、Flutter等等。
业务变化：前端的产品变化往往会比后端的业务变化更频繁。

补齐端侧的差异化投放能力

有些产品在投放到不同的国家、语种、人群中时，可以在 BFF 层做一些转换，比如后端的报错可以在这里做一些和用户语种相关的翻译。

横向聚合和基于聚合的优化

有一些产品模块会涉及到多个中台服务，BFF 可以作为边缘服务层，起到聚合 API 的作用。

端上的业务效能评估

在端上尝试一种新的体验难免要改变 API。如果没有 BFF，为了 A/B 测试需要同时修改前端和 API。假如移动和 Web 团队都需要跑 A/B 测试怎么办？一个团队可能需要等待另一团队。

BFF 让不同团队可以独立的进行试验。您可能会发现，首先在 BFF 中实施实验性 API 更改，然后将试验移植到 A/B 测试中，然后再将其移植到核心 API 中，更为方便。

BFF 的一些问题

资源成本高

不管 BFF 多简单，都需要提供一台服务器运行，严格一点的话，还需要提供几套环境部署。比如一些大公司内部
要求，不管多么简单应用都需要 4 台服务器，并且服务器的审批流程可能会比较慢长。

并发性难以保障

BFF 层一般由前端的同学开发，然而保证 BFF 高可用，对前端的同学往往是个挑战。当访问量突增时，可能出现 BFF 这层先被打爆，导致整个系统架构可用性被拉低。

运维困难

谁开发谁运维，然后前端的同学可能缺乏运维线上应用经验，BFF 的运维也是个很大的问题。

Serverless For Backend

由于 Serverless 特别是函数计算，在应用部署之后，假如没有访问量就不会消耗计算资源，更不会产生费用。当访问量增加以后，平台会以百毫秒级别的速度对应用进行扩容，访问量下降以后背后的计算资源（函数实例）也会随之收缩。同时也给用户提供了开箱即用监控报警和日志检索功能。

函数计算弹性伸缩、按量付费和免运维的优势正好是对应了传统 BFF 的缺点。所以将 BFF 部署到函数计算平台就可以非常完美的解决上述 BFF 的问题。

当部署成本下降以后，也为 BFF 拆解得更小提供了可能性。此时端侧可以按照业务模块来组织对应的 BFF 模块。比如说，运营平台的前端开发自己负责对应的 BFF 模块开发，设备中心的前端负责自己的 BFF，相互之间可以少一些冲突，真正做到谁享受谁负责。

基于函数计算的方案

函数计算平台的 BFF 架构方案有四层：端侧、网关层、BFF 层和中台服务。

端侧可以保持自己熟悉的技术方案进行开发。比如网页端可以选择 React 或者 Vue.js，移动端可以选择 Java/Kotlin 或者 Objective C/Swift。也可以选择 React Native 或者 Flutter 这种跨多端的方案。

网关层有两种选择：API Gateway 和 HTTP Trigger。API Gateway 的功能丰富，支持限流，但是会产生额外的费用。HTTP Trigger 支持简单的路由映射，绑定域名，虽然不支持限流但是免费的，适用于轻量级应用。

BFF 层建议按照业务模块进行拆分，不同的功能模块建不同的函数，如果不同端的模块之间的接口差异较大也可以拆解成不同的函数。然后通过 Fun 工具把这些函数组织成若干个项目。项目的拆解可以考虑按照维护的团队进行拆分，不同的团队维护不同项目，减少之间的交叉和冲突。

SFF 研发流程

下面我们从本地开发、发布流程和服务监控三个方面看看 SFF 的研发流程怎么弄。

本地研发

本地工程分为三个部分

APP/H5 - React Native 或者 Vue.js 等端侧技术
SFF - FC 函数，常见的有 express 或者 egg
中台 API 接口 - 可以选择 API Mock 或者直连测试环境。

本地调试。偏好命令行的开发者可以使用 funcraft工具通过 fun local start 本地启动服务。偏好桌面 GUI 的开发者可以使用函数计算提供的 VSCode Plugin。

单元测试可以选中自己喜欢的测试框架：Mocha 或者 Jest

下面是一种建议的项目结构

sffdemo
├── README.md
├── function
│   ├── package.json
│   ├── template.yml
│   └── user.js
├── package.json
└── src├── component├── layout├── model├── page└── service

src 目录放置 APP 或者 H5 的代码。function 目录放置 bff 代码，可以用 ROS 模板 template.yml 描述函数，使用 fun 工具进行发布。

发布流程

日常开发建议使用命令行发布，安装和配置 fun 工具以后，在 BFF 项目中放置一个 template.yml 的 ROS 描述文件，然后借助于 fun deploy 命令进行快速部署。

新手也可以选择去函数计算控制台，使用 ZIP 文件包上传的方式发布。

对于更复杂的场景可以配置 CI/CD。比如说代码仓库选择 Gitlab/Github，构建系统选择 Travis CI/Gitlab CI/Jenkins ，提交代码到代码仓库自动触发构建和发布。更多细节可以参考Serverless 实战 —— Funcraft + OSS + ROS 进行 CI/CD

服务监控

关于可观察性方面，函数计算提供了开箱即用的监控、日志和报警。

成本优势

用户的应用负载通常具备多种类型，对资源的规格和弹性要求各不相同。函数计算提供了预付费和后付费计量模式，帮助您在不同场景下获得显著的成本优势。预付费是指用户先判断应用的资源需求，预先购买指定数量的资源消费券后再使用。预付费的优点是单价低，比后付费便宜 70% 左右；缺点是应用负载动态变化，按照峰值购买资源将导致较低的资源利用率。后付费是指用户根据应用实际使用的资源按需付费。函数计算按量资源是根据实例执行请求的时间付费，精确到百毫秒。如果没有请求，则无需付费。因此可以认为按量资源的利用率是 100%。后付费的优点是资源利用率高，缺点是单价高。函数计算的自动伸缩能够让您将预付费和后付费资源无缝结合起来，在不同场景下都能获得有竞争力的成本。

更具体的费用计算和成本优化方案可以参考函数计算成本优化最佳实践

小结

每个人对 Serverless 的定义和落地都可能有不一样的理解。借助于函数计算带来的 Serverless 优势，BFF 真正的做到了谁享受谁负责、低成本和免运维。

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的技术圈。”