📚 课程目录第2章 BFF架构模式

2. BFF 架构模式：BFF 在前后端分离中的位置，与 API Gateway 的区别与联系

在微服务与前后端分离架构中，BFF（Backend For Frontend）与 API Gateway 是两个常被混淆的组件。理解它们各自的职责、部署位置以及协作方式，是设计 BFF 层参数配置与路由策略的前提。

2.1 前后端分离架构中的三层模型

传统的单体后端在前后端分离后，逐步演变为“前端 → 网关层 → 微服务”的三层模型。BFF 的出现进一步将网关层拆分为“通用网关 + 前端专属 BFF”。

  架构演进要点： 从“前端直连微服务”到“前端 → API Gateway → 微服务”，再到“前端 → API Gateway → BFF → 微服务”，每一层都承担了不同的解耦职责。

2.2 BFF 与 API Gateway 的核心职责对比

API Gateway 作为系统级入口，关注横切关注点；BFF 作为前端专属适配层，关注用户体验与数据定制。两者并非替代关系，而是互补协作。

对比维度	API Gateway	BFF
部署粒度	全局统一部署，所有前端共享	按前端类型独立部署（Web / Mobile / IoT）
核心职责	认证鉴权、限流熔断、协议转换、路由分发	数据聚合、字段裁剪、Schema 版本适配、前端参数配置
变更影响	变更影响所有下游服务与前端	变更仅影响对应前端，隔离性好
业务逻辑	不包含业务逻辑，纯基础设施	可包含轻量业务编排与数据转换
版本管理	通常不管理 API Schema 版本	核心职责：管理前端与后端之间的 Schema 版本
典型技术	Kong / Zuul / Spring Cloud Gateway / APISIX	Node.js / GraphQL / 自定义 BFF 中间件

实践建议： 在大型项目中，API Gateway 负责“安全与流量管控”，BFF 负责“数据与体验适配”。两者串联形成完整请求链路：前端 → API Gateway → BFF → 微服务。

2.3 两者的联系：协作模式与请求链路

BFF 通常部署在 API Gateway 之后，作为微服务的前端代理。API Gateway 将请求路由到对应的 BFF 实例，BFF 再调用多个微服务聚合数据。

典型请求链路示例

// 移动端首页请求链路
1. 移动端 App 发起 GET /api/v2/homepage
2. API Gateway 验证 Token，检查限流
3. Gateway 根据路径前缀 /api/v2/ 路由到 Mobile BFF 集群
4. Mobile BFF 并行调用：用户服务(用户信息) + 商品服务(推荐列表) + 订单服务(待处理)
5. BFF 聚合数据，按移动端 Schema 版本裁剪字段
6. 返回 JSON 响应给移动端

2.4 何时需要引入 BFF？

并非所有项目都需要 BFF。以下场景强烈建议引入：

多前端类型共存： Web、iOS、Android、小程序各自需要不同的数据结构与字段粒度。
后端微服务粒度太细： 前端一个页面需要调用 5 个以上微服务，聚合逻辑复杂。
前后端 Schema 版本不同步： 后端接口升级频繁，前端需要版本兼容层。
前端专属参数配置复杂： 如动态路由参数、分页策略、缓存 TTL 等需要按前端类型独立配置。

避坑提示： 不要将 BFF 变成“胖中间层”。BFF 只做数据聚合与格式转换，不应包含核心业务逻辑或数据库操作，否则会退化为“分布式单体”。

2.5 BFF 与 API Gateway 的架构决策矩阵

下表帮助团队在架构选型时快速判断各组件应承担的责任：

决策问题	由 API Gateway 处理	由 BFF 处理
用户登录 Token 校验	✅ 是	❌ 否
接口调用频率限制	✅ 是	❌ 否
Web 端需要字段 A，移动端不需要	❌ 否	✅ 是
后端接口返回 v1 格式，前端需要 v2 格式	❌ 否	✅ 是
跨服务数据聚合（如用户+订单+商品）	❌ 否	✅ 是
协议转换（HTTP → gRPC）	✅ 是	可选
动态路由参数注入（如租户 ID）	可选	✅ 是

2.6 本章小结

BFF 的位置： 位于 API Gateway 之后、微服务之前，按前端类型独立部署。
核心区别： API Gateway 关注系统级横切关注点，BFF 关注前端专属数据适配与参数配置。
协作关系： 请求链路为 前端 → API Gateway → BFF → 微服务，返回路径为 微服务 → BFF → 前端。
引入时机： 多前端共存、微服务粒度细、Schema 版本频繁变更时，BFF 是必要的架构组件。