什么是 BFF

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

让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：域名与空间、虚拟空间、营销软件、网站建设、柳林网站维护、网站推广。

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

然后随着移动端的兴起，出现了 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 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的技术圈。”

分享文章：基于函数计算的BFF架构-创新互联
文章路径：http://chengdu.cdxwcx.cn/article/csgogi.html