BFF 网关模式开发指南

1. BFF 网关模式开发指南

BFF 是近些年新衍生出来的一种开发模式, 或者说是一种适配模式的系统, BFF 全称为 Backend OF Front 意为后端的前端, 为了适配微服务模式下前端后端系统接口调用混乱而出现的。在如今微服务盛行的趋势下, 大型系统中划分出了数十个服务模块, 例如商品, 门店, 运费, 红包, 订单, 优惠券, CMS, 用户, 搜索, 推荐, 广告等等系统, 前端也有小程序, APP, 网页等端。由此产生了很多问题:

1.2. 痛点

1. 前端问题: 每次需求开发前端要对接多个系统来确认接口信息, 不同的数据要找不同的系统, 各个接口散落一地, 开发调试的效率极低。
2. 后端问题: 后端同样也需要各自包装数据信息来提供前端处理, 重心变成如何为前端提供数据, 因为需要根据不同的版本、客户端、用户、定位等特征来判别, 很多时间浪费在展示层, 而不能专注于业务逻辑处理, 每个后端系统各自为战, 都有自己的接口规则, 各种历史版本问题都不能完全统一, 所有系统都严重耦合了版本问题。
3. 变更不灵活: 当产品想要更新需求时, 更是牵一发而动全身, 某一块的小改动需要在各个系统之间找接口来回沟通, 大部分系统都要重新上线一次。

如下面, 前后端的沟通链路过多。

1.3. BFF 网关定位

鉴于此痛点, 需要一个中间层来适配前后端服务, BBF 由此而生, 它负责将所有下游后端接口进行统一调用, 下游接口只需要提供 RPC 接口供网关使用, BFF 网关提供 WEB 接口来让前端调用, 最后将数据进行组装拼接, 根据前端的需求来返回数据。

所以 BFF 的核心定位就是: “统一下游接口, 为前端提供服务”。

只有把握好服务这个概念, 才能做好 BFF 网关系统, 其他系统可以扯皮甩锅, 但 BFF 网关不可以, 它与生俱来的使命就是把这两边拉扯起来, 所有不合理不合适, 繁琐无用的逻辑都需要 BFF 网关去处理, 后端只要做好业务逻辑, 前端做好展示, 其他的都可以交给 BFF 网关。

1.4. BFF 网关特点

1.4.1. 琐碎

BFF 网关主要为前端进行服务, 前端不关心版本、客户端、定位、用户身份等情况, 只接收渲染数据即可, 而这些逻辑都需要耦合到 BFF 网关中, 以版本、客户端、定位、用户等特征作为纬度, 其中版本最为最复杂的分支, 可能贯彻整个系统生涯几十个版本类型都需要做兼容, 由此还需要兼顾不同客户端的展示要求和用户特征, 所以 BFF 网关中必然需要做大量判断分支, 根据上百种情况组合判断来生成-唯一版本-唯一端-唯一用户的数据结构。

1.4.2. 数据琐碎

BFF 不需要数据库, 这点会在下面说明, 所以有很多数据需要以静态变量的形式存放在代码里, 或者是使用配置中心来动态配置, 例如图片地址、各种色值、模块固定文字、处理标识等, 这些琐碎的数据都会存放在 BFF 网关中进行维护, 如果放在前端, 修改时必须要进行发版, 时间周期太长, 而存放在后端的话, 又会打散数据, 不能从一个地方作为主要数据窗口进行管理。

1.4.3. 逻辑琐碎

衍生第一点说到的, BFF 网关作为下游接口的聚合, 每次流程需要调用数十个后端接口, 再根据版本、端、用户进行逻辑处理, 历史逻辑与新需求杂糅在一起, 实现新功能的同时要不断兼顾历史逻辑, 只能是加入大量的分支判断, 最后变成了 if 大爆炸, 或者使用策略模式进行优化, 但无论如何怎么包装都无法掩盖琐碎的逻辑。

1.4.4. 性能

BFF 网关的耗时主要有两部分

1. 内部处理耗时
2. 下游 RPC 接口耗时

BFF 作为最直接和前端交互的接口, BFF 的耗时将直接影响用户浏览体验, 所以 BFF 性能一定要最优, 不断压缩耗时来提高接口响应性能, 内部逻辑优化时, 首先观察下游接口耗时情况, 各个模块之间难免重复调用接口, 可以使用编排框架将下游接口调用进行优化。然后使用线程池进行并发处理, 能够并发处理的一定要并发执行, 这样可以极大降低下游接口耗时, 提供接口处理能力。

1.4.5. 缓存

切勿在 BFF 网关中使用缓存

此处指的缓存主要是 Redis 等中间件缓存, BFF 网关主要数据来源都是通过调用下游接口获取, 这里是最耗时的, 如果想要减少下游接口耗时, 应该使用并发或者编排能力, 而不可以通过缓存下游接口数据来实现。

1. 成本问题: 下游接口数据会根据传入的定位、用户等信息查询, 当系统用户量大、覆盖城市多时, 需要缓存的数据量将剧增, 而数据缓存后再次访问概率很低, 造成严重的缓存空间浪费。
2. 一致性问题: BFF 网关的引入主要是为了统一后端接口, 性能是网关的一大指标, 但不能为了性能将所有下游接口数据进行缓存, 从而牺牲数据一致性, 后续展示时一旦出现问题, 将增加排查难度。

1.4.6. 降级

任何时候都不要将错误直接返回给用户, 不论是下游的错误还是系统内部的错误, 这一点完全可以交给 BFF 网关来做, 这里降级可以分为两类型处理。

1. 下游接口降级: 当下游接口出现超时或数据异常时, 一定要做好降级措施, 例如增加接口超时时间判断, 及时中断调用, 不要因为某个下游接口而影响整体性能, 当下游接口报错时, 也要做好异常捕获, 整体页面可以直接丢弃这部分数据不做展示, 而不能完全不展示。
2. 异常整体降级: 在 BFF 网关内部处理逻辑中难免会有错误发生, 或者下游核心的定位、商品等接口异常, 这里就需要做整体降级, 例如模拟一个友情提示页面等, 提示用户稍等重新刷新, 或者在未开通城市里可以引导用户切换地址, 整体页面的降级尽量交给 BFF 网关来做, 而不要分散到不同的前端来做。

1.5. BFF 网关划分

1.5.1. 接口粒度

如上图, BFF 网关的下游接口较多, 如何聚合下游接口进行划分是一个需要考虑的问题, 这里提供的建议是按照页面来划分, 例如在首页可以提供首页接口返回整体展示效果, 购物车页面提供购物车接口, 以页面为单位划分可以方便前后端的统一处理, 当然如果页面内容太多时, BFF 网关接口可能耗时较多, 可以同页面拆分开来, 让前端并行加载接口, 这样既能降低整体页面加载时间, 也能让 BFF 网关减少下游接口调用。

1.5.2. 数据安全

BFF 网关虽然也叫网关, 但数据安全方面例如安全攻防等主要还是外层去做, BFF 只负责数据的调用组装, 不要再赋予其他太多功能, 但 BFF 网关一定要有限流逻辑, 可以采用 Sentinel 等框架实现, 防止某个前端异常进行大量请求, 打垮 BFF 网关导致所有前端异常。

1.5.3. 上线注意

BFF 网关较为单薄, 没有依赖的数据库等大型中间件, 可能只是用到比较轻量的配置中心和消息队列, 所以上线时初始化参数较少, 但因为 BFF 网关需要做版本、定位、客户端等特征的数据处理, 所以一定要做好灰度上线, 防止新功能影响到历史版本、不同定位下的用户浏览。

1.5.4. 优势总结

BFF 网关的引入:

1. 降低后端开发联调成本: 直接提供 RPC 接口将基础数据返回即可
2. 降低前端开发联调成本: 直接对接一两个接口就可以拿到全部数据, 并且可以将很多前端写死的逻辑交给 BFF 网关做下发, 提高前端展示的灵活性。
3. 方便需求迭代升级: 当大量前端逻辑移植到 BFF 网关, 很多需求的上线不再依赖前后端发版, 直接让 BFF 快速上线更新即可。
4. 提高用户体验: BFF 网关可以较低成本的做异常降级处理, 为前后端包装错误提示, 统一异常捕获类型。
5. 提高系统性能: 虽然引入 BFF 网关相当于多加了一层, 但 BFF 网关可以通过并发调用下游接口, 或者线程池的形式提高接口处理性能, 而不需要像之前前端去逐个调用接口, 规范了整体接口调用执行逻辑。