3. BFF 架构设计原则

BFF（Backend For Frontend）并非简单的代理层，而是一种以前端体验为中心的架构模式。其核心设计原则决定了中间件集成的质量与可维护性。本章深入剖析五大原则，帮助你在实际项目中构建稳健、高效的 BFF 层。

3.1 五大原则概览

3.2 单一职责：一个 BFF 只服务一种前端

BFF 的粒度应与前端应用一一对应。移动端、桌面 Web、小程序各自拥有独立的 BFF 层，避免共享逻辑导致“牵一发而动全身”。

• 隔离变更风险：移动端接口升级不影响 Web 端。
• 独立优化：移动端可针对弱网做数据压缩，Web 端可做预加载。
• 简化中间件：每个 BFF 的中间件链只需处理一种客户端的特定需求。

3.3 关注点分离：业务逻辑与传输逻辑解耦

BFF 层不应包含核心业务逻辑，其职责是编排与适配。中间件应聚焦于：

• 数据聚合：从多个下游服务拉取数据，合并为单一响应。
• 格式转换：将后端 Protobuf/Thrift 协议转为前端友好的 JSON。
• 错误处理：统一异常码，屏蔽后端错误细节。

业务规则（如价格计算、权限校验）应下沉到后端服务，BFF 只做“搬运与组装”。

// ❌ 错误：BFF 中包含业务逻辑
function calculateDiscount(price, userLevel) {
  if (userLevel === 'vip') return price * 0.8;
  return price;
}

// ✅ 正确：BFF 只调用业务服务
async function getProductDetail(productId) {
  const [product, user] = await Promise.all([
    productService.get(productId),
    userService.getCurrent(),
  ]);
  return { ...product, discount: user.level }; // 折扣由前端或业务服务计算
}

3.4 前端友好：输出即所需

BFF 的核心价值在于减少前端的数据处理负担。中间件应主动对后端响应进行“降维”与“整形”。

• 字段裁剪：只返回前端需要的字段，减少传输体积。
• 结构扁平化：将嵌套对象拍平，避免前端深层解构。
• 枚举映射：将后端数字枚举转为前端可读的字符串。

3.5 无状态设计：可水平扩展的基础

BFF 实例不应在内存中保存任何请求间共享的状态（如 Session、本地缓存）。所有状态应外置到 Redis、数据库或下游服务。

• 弹性伸缩：无状态意味着可以随时增加或减少实例。
• 故障恢复：实例崩溃后，新实例立即接管，无数据丢失。
• 中间件幂等：每个中间件函数应设计为幂等，多次执行结果一致。

3.6 可观测性：让中间件行为透明

BFF 作为流量入口，必须提供完整的可观测性能力，以便快速定位问题。

// 中间件链路追踪示例（伪代码）
app.use(async (ctx, next) => {
  const span = tracer.startSpan('bff-request');
  ctx.state.traceId = span.traceId;
  await next();
  span.finish();
});

3.7 原则协同：BFF 中间件架构图

下图展示了五大原则如何在 BFF 中间件层协同工作，形成从请求入口到后端服务的完整链路。

3.8 原则冲突与权衡

在实际项目中，五大原则并非总是完全兼容，需要根据场景做出权衡：

• 单一职责 vs 运维成本：为每个端创建独立 BFF 会增加部署和监控的复杂度。对于流量较小的端，可考虑共享 BFF 但通过路由隔离。
• 前端友好 vs 性能：过度裁剪和转换可能增加 BFF 的 CPU 开销。建议对高频接口做缓存，或使用流式传输减少序列化成本。
• 无状态 vs 缓存效率：完全无状态意味着每次请求都要重新拉取数据。可在 BFF 前加一层分布式缓存（如 Redis），既保持无状态又提升响应速度。