转载

基于函数计算的 BFF 架构

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

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

基于函数计算的 BFF 架构

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

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

基于函数计算的 BFF 架构

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 架构方案有四层:端侧、网关层、BFF 层和中台服务。

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

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

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

基于函数计算的 BFF 架构

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

基于函数计算的 BFF 架构

服务监控

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

基于函数计算的 BFF 架构

成本优势

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

基于函数计算的 BFF 架构

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

原文  https://juejin.im/post/5e85a8566fb9a03c802791c0
正文到此结束
Loading...