1. BFF 架构概述

1.1 BFF 的定义

BFF（Backend For Frontend，服务于前端的后端） 是一种架构模式，由 Sam Newman 在《Building Microservices》一书中正式提出。其核心思想是：为每一种前端客户端（Web、iOS、Android、IoT 等）单独构建一个专属的后端服务，该服务负责适配特定前端的交互需求，而不是让所有前端共享同一个通用后端 API。

BFF 的本质是 前端与后端之间的中间层，它承担以下职责：

• 数据聚合：从多个下游微服务中获取数据，按前端视图模型进行组装。
• 协议转换：将后端微服务的内部协议（gRPC、Thrift、AMQP）转换为前端友好的 HTTP/REST 或 GraphQL。
• 裁剪与过滤：只返回前端实际需要的字段，避免过度获取（Over-fetching）或不足获取（Under-fetching）。
• 会话管理：处理前端特有的认证、授权、Cookie/Session 逻辑。
• 设备适配：根据客户端设备类型（屏幕尺寸、网络带宽、操作系统）调整响应格式和数据量。

1.2 BFF 在微服务架构中的位置

在典型的微服务架构中，BFF 位于 客户端与 API Gateway 之间，或者 客户端与微服务之间（当没有 API Gateway 时）。下图展示了 BFF 在整体架构中的位置与交互关系：

从图中可以看出，BFF 层处于 客户端与 API Gateway 之间，形成清晰的四层结构：

1. 客户端层：Web、iOS、Android 等前端应用，各自有不同的交互模式和数据需求。
2. BFF 层：每个前端对应一个专属 BFF，负责前端专属的业务编排和数据适配。
3. API Gateway 层：统一入口，负责路由、限流、认证、日志等横切关注点。
4. 微服务层：领域服务，提供原子化的业务能力。

1.3 BFF 与 API Gateway 的区别

BFF 和 API Gateway 是微服务架构中两个不同层次的组件，经常被混淆。下表从多个维度对比两者的核心差异：

为了更直观地理解两者的职责边界，下图展示了 BFF 与 API Gateway 在请求处理流程中的分工：

1.4 何时引入 BFF

并非所有微服务架构都需要 BFF。以下场景强烈建议引入 BFF 层：

• 多客户端并存：同时维护 Web、iOS、Android 等多个前端，且各端交互差异明显。
• 前端频繁迭代：前端业务逻辑变化快，需要后端快速响应，而不影响其他客户端。
• 后端微服务粒度细：微服务数量超过 10 个，前端需要跨服务聚合数据。
• 设备适配需求强：需要根据设备类型、网络状态、屏幕尺寸返回不同数据。
• 前端团队自治：前端团队希望拥有独立的后端控制权，减少跨团队协调成本。