3. BFF 架构模式：Per-Frontend BFF、共享 BFF 与分层 BFF
在微服务与前端分离的架构中，BFF 的部署形态直接决定了聚合层的职责边界、团队协作效率与运维复杂度。业界主要演化出三种模式：每前端一个 BFF（Per-Frontend BFF）、共享 BFF 和分层 BFF（Edge BFF + 业务 BFF）。面试中常要求候选人对比其适用场景、隔离性与性能开销。
3.1 三种模式核心对比
| 维度 | Per-Frontend BFF | 共享 BFF | 分层 BFF |
|---|---|---|---|
| 部署单元 | 每个前端独立部署 | 所有前端共用 | Edge 层 + 业务层独立部署 |
| 隔离性 | 高（故障隔离、版本隔离） | 低（一个变更影响所有前端） | 中（Edge 层隔离，业务层共享） |
| 代码复用 | 低（重复逻辑多） | 高（公共逻辑集中） | 中（业务层复用，Edge 层定制） |
| 运维成本 | 高（实例数多） | 低（实例数少） | 中（两层运维） |
| 团队自治 | 强（前端团队全权负责） | 弱（需跨团队协调） | 强（Edge 层归前端，业务层归后端） |
| 典型场景 | 大型电商、多端差异化大 | 内部管理系统、端差异小 | 全球化部署、CDN 边缘计算 |
面试高频点：面试官常追问“共享 BFF 是否就是 API Gateway？”——共享 BFF 侧重聚合编排，API Gateway 侧重路由、限流、认证，两者可合并部署但职责不同。
3.2 Per-Frontend BFF：为每个前端独立构建
每个前端（Web、iOS、Android、小程序）拥有专属的 BFF 服务，独立开发、独立部署、独立扩缩容。前端团队可以完全控制 BFF 的接口契约与聚合逻辑。
- 优势：故障隔离——移动端 BFF 崩溃不影响 Web 端；版本独立——可针对低版本 App 保留旧接口；团队自治——前端团队无需等待后端排期。
- 劣势：重复代码——多个 BFF 可能实现相同的用户信息聚合；运维成本——每增加一个前端，就增加一套 BFF 部署。
- 适用条件：前端类型超过 3 种、各端交互差异显著、团队按端组织。
3.3 共享 BFF：统一聚合层
所有前端共享同一个 BFF 服务，通过参数或路由区分端类型。共享 BFF 通常作为微服务网关的下一跳，负责公共的聚合、裁剪与格式转换。
- 优势：代码复用高——公共逻辑只写一次；资源利用率高——实例数少；运维简单——只需维护一个服务。
- 劣势：变更风险大——一个接口改动可能影响所有前端；耦合度高——各端需求冲突时难以调和；扩缩容粒度粗——无法按端独立扩缩。
- 适用条件：前端类型少（≤2）、各端交互逻辑高度相似、团队规模小。
避坑提示：共享 BFF 容易退化为“上帝服务”，所有聚合逻辑堆在一个代码库中，最终变成单体瓶颈。建议通过模块化分包、接口版本化、按端路由隔离来缓解。
3.4 分层 BFF：Edge BFF + 业务 BFF
将 BFF 拆为两层：Edge BFF 部署在 CDN 边缘节点或 API Gateway 侧，负责设备适配、协议转换、静态缓存；业务 BFF 部署在数据中心，负责业务聚合、编排与数据裁剪。两层通过内部 RPC 或 HTTP 通信。
- Edge BFF 职责：User-Agent 解析、响应压缩、国际化、A/B 测试分流、静态资源缓存。
- 业务 BFF 职责：调用下游微服务、数据聚合、字段过滤、错误码统一、鉴权校验。
- 优势：边缘层卸载通用逻辑，减少回源请求；业务层专注核心聚合，职责单一；支持全球多区域部署。
- 劣势：网络延迟增加一跳；两层部署与监控复杂度上升；需要维护两套代码库。
3.5 模式选型决策树
面试中常以“你们团队如何选择 BFF 模式”作为开放题。以下决策步骤可作为回答框架：
- 前端类型数量：若 ≥3 且差异大 → 优先 Per-Frontend BFF；若 ≤2 → 考虑共享 BFF。
- 团队组织方式：按端划分团队 → Per-Frontend BFF；按功能划分团队 → 共享 BFF 或分层 BFF。
- 全球化部署需求：需要 CDN 边缘卸载 → 分层 BFF；仅单区域部署 → 前两种模式。
- 运维人力：团队小、希望减少运维 → 共享 BFF；团队大、愿意投入 → Per-Frontend 或分层。
- 演进路径：从共享 BFF 起步，当出现“一个接口改不动”时，逐步拆出 Per-Frontend BFF 或引入 Edge 层。
案例参考：某头部电商平台早期使用共享 BFF，随着小程序、海外版 App 上线，接口定制需求激增，最终迁移为 Per-Frontend BFF + 公共库抽取模式，将用户鉴权、日志上报等通用逻辑下沉为 SDK，各端 BFF 独立部署。
3.6 面试追问与避坑
| 追问点 | 回答要点 |
|---|---|
| Per-Frontend BFF 如何避免代码重复？ | 抽取公共 SDK / npm 包；使用 BFF 框架的中间件复用；将通用聚合下沉到微服务层。 |
| 共享 BFF 如何做灰度发布？ | 按端标识路由到不同版本；使用流量染色或 Header 路由；逐步切流。 |
| 分层 BFF 的延迟如何优化？ | Edge 层与业务层部署在同一区域；使用 gRPC 替代 HTTP；Edge 层做响应缓存。 |
| 三种模式能否混合使用？ | 可以。例如核心业务用 Per-Frontend BFF，公共数据（如配置、字典）走共享 BFF，边缘节点部署 Edge BFF 做全局前置处理。 |
常见误区：不要认为“共享 BFF 一定不好”或“Per-Frontend BFF 一定最好”。面试官看重的是你能否根据业务阶段、团队规模、运维能力做出合理权衡，并给出演进路径。