1. BFF 架构概述
BFF（Backend For Frontend）是一种为特定前端客户端（Web、iOS、Android、小程序等）提供专属后端的架构模式。其核心思想是：不为所有前端提供统一的通用 API，而是为每种前端客户端单独构建一个轻量级的后端层，负责聚合下游微服务数据、裁剪响应字段、适配客户端协议，从而让前端获得最贴合自身需求的接口。
1.1 BFF 模式的定义
BFF 由 Sam Newman 在《Building Microservices》一书中正式提出。它强调前端与后端之间的“中间层”应该由前端团队（或与前端紧密协作的团队）维护，使得前端不再直接面对复杂的微服务网络，而是通过 BFF 获得“量身定制”的 API。
核心特征：
- 客户端专属：每个前端客户端（如移动端、桌面端）拥有独立的 BFF 实例。
- 聚合编排：BFF 负责调用多个下游微服务，合并数据并返回给前端。
- 协议适配：将后端 gRPC/Thrift 协议转换为前端友好的 REST/GraphQL/WebSocket。
- 字段裁剪：只返回前端需要的字段，减少网络传输和前端处理负担。
1.2 BFF 在微服务中的位置
在微服务架构中，BFF 位于网关层之后、前端客户端之前，是前端与后端微服务之间的“中间人”。下图展示了 BFF 在典型微服务拓扑中的位置：
关键理解：BFF 不是替代 API Gateway，而是在 Gateway 之上增加的一层业务聚合。Gateway 负责通用横切关注点（路由、限流、认证），BFF 负责前端专属的业务逻辑编排。
1.3 BFF 与 API Gateway 的区别
很多初学者容易混淆 BFF 和 API Gateway。两者虽然都位于前端与后端之间，但职责和关注点有本质区别。下表从多个维度进行对比：
| 对比维度 | API Gateway | BFF |
|---|---|---|
| 核心职责 | 统一入口、路由转发、限流熔断、认证鉴权、日志监控 | 数据聚合、字段裁剪、协议适配、前端专属业务编排 |
| 粒度 | 粗粒度，面向所有客户端提供通用 API | 细粒度，为每个前端客户端定制 API |
| 维护团队 | 通常由中间件或基础设施团队维护 | 通常由前端团队或与前端紧密协作的团队维护 |
| 变更频率 | 低，稳定为主，避免频繁变更 | 高，随前端需求快速迭代 |
| 协议支持 | REST / HTTP 为主，部分支持 gRPC-Web | REST / GraphQL / WebSocket / gRPC-Web 均可 |
| 状态管理 | 无状态或轻量状态（如限流计数器） | 可持有会话状态（如用户登录态、购物车） |
| 典型实现 | Kong / Zuul / Spring Cloud Gateway / Nginx | Node.js / Go / Java 自研轻量服务 |
从架构演进角度看，BFF 和 API Gateway 通常协同工作，而非互相替代。一个常见的部署拓扑是：
- 请求先到达 API Gateway，完成路由、限流、认证等通用处理。
- Gateway 根据请求头或路径将请求转发到对应的 BFF 实例（如
/web/**转发到 Web BFF，/mobile/**转发到 Mobile BFF）。 - BFF 实例调用下游微服务，聚合数据并返回给前端。
下图展示了这种协同关系：
常见误区：不要试图让 API Gateway 承担 BFF 的职责。Gateway 的定位是基础设施层，如果在其内部编写大量业务聚合逻辑，会导致 Gateway 变得臃肿、难以维护，且每次前端变更都需要升级 Gateway，违背了基础设施稳定的原则。
1.4 为什么选择 BFF？
在微服务架构中引入 BFF 层，主要解决以下痛点：
- 减少前端网络请求：前端无需多次调用多个微服务，BFF 一次聚合返回。
- 避免过度获取数据：BFF 只返回前端需要的字段，减少带宽消耗和前端解析成本。
- 屏蔽后端变更：后端微服务重构或拆分时，只需修改 BFF 的聚合逻辑，前端无需感知。
- 支持多端差异化：Web 端可能需要完整的商品详情，而移动端只需要精简信息，BFF 可以分别实现。