BFF

[ChelesteWang]

API Gateway 与 BFF

有了 API Gateway 之后，它可以帮我们完成聚合之类的逻辑。不过有一个问题是前端可能有多种不同的类型，比如 PC 前端，Mobile 前端，它们的业务逻辑不可避免的会有各种各样的差异，如果在 API Gateway 中处理这些差异的话，那么会出现坏味道，为了解决此类问题，我们引入 BFF（Backend For Frontend），每一种前端都有属于自己的 BFF，用来处理专属于自己的业务逻辑，至于 API Gateway，则只处理鉴权，日志等公共业务逻辑。

[ChelesteWang]

[ChelesteWang]

• 接口编排
• 通用鉴权
• 通用日志、监控

[ChelesteWang]

微服务治理

• 服务发现（综合管理服务）
• rpc 调用（减少数据调用）
• 配置中心（减少运维配置）
• 服务网关（综合能力，鉴权日志监控）

[ChelesteWang]

BFF
很多团队都会有 bff 这个解决方案，从传统的视角来看，主要有以下量个优点

api 网关：统一的数据接口处理，鉴权、参数、返回值、错误码等
数据裁剪：将后端的基础数据组合成适合前端渲染的数据结构
变化隔离：天然的防腐层，屏蔽服务接口的变化
技术迭代：ab test、流量灰度、渲染服务
那我们要思考如何让 bff 发挥更大的价值，更好的解决端的问题

性能视角：降低多加一层带来的链路损耗，服务资源的成本
业务视角：除了数据还能给端提供什么
下面是如何解这两个问题

利用 client 天然分布式的特点，结合 service worker 和边缘计算将 bff 更加前置
使用 graphql 消除请求和全局的缓存，减少不必要的 rtt，同时缓存可以进一步放在 cdn 数据库中