基于函数计算的 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。

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

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

BFF 的好处

历史遗留业务支撑

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

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

端上变化快主要体如今两个方面：

• 技术革新：端上的技术更新比较快，js 框架层次不穷。移动端也有不少选择，有 H五、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 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的技术圈。”