API 组合模式详解：从问题到实践
在微服务架构中，一个业务操作往往需要调用多个服务来获取数据。如何高效、可靠地组合这些 API 响应，是后端架构师必须面对的核心问题。本文基于 ByteByteGo 的深度指南，梳理 API 组合的核心模式与最佳实践。
为什么需要 API 组合？
当客户端需要的数据分散在多个服务中时，直接让客户端逐个调用会导致：
- 网络开销大：多次往返延迟，用户体验差。
- 耦合度高：客户端必须知道每个服务的具体地址和数据结构。
- 业务逻辑泄露：客户端被迫实现服务编排逻辑。
因此，我们需要一个中间层来负责聚合、转换和编排不同服务的响应。
三种核心组合模式
1. API Gateway 聚合模式
做法：客户端只请求网关，网关并行调用多个下游服务，合并结果后返回。
优点：
- 减少客户端请求次数，降低延迟。
- 通过网关统一暴露粗粒度 API，简化客户端。
缺点：
- 网关可能成为性能瓶颈。
- 网关逻辑变重，需要仔细维护。
适用场景：移动端、BFF（Backend for Frontend）场景。
2. Backend for Frontend (BFF) 模式
做法：为每种客户端（Web、iOS、Android）单独定制一个后端服务，该服务负责组合底层微服务。
优点：
- 客户端专属优化，只返回特定端需要的数据，减少传输量。
- 各端可以独立演进。
缺点：
- 需要维护多个 BFF，增加部署和运维成本。
适用场景：客户端差异大、UI 需求差异明显的产品。
3. GraphQL 模式
做法：使用 GraphQL 作为数据查询语言，客户端声明式地指定需要字段，服务端通过 resolver 完成数据拉取和组装。
优点：
- 客户端按需取数，避免过度获取（over-fetching）和不足获取（under-fetching）。
- 强类型 schema，便于前端和后端协作。
缺点：
- 安全性控制复杂，需防止恶意深层查询。
- 性能调优难度高，需要处理 N+1 查询问题（通常配合 DataLoader 解决）。
关键设计考量
1. 并行 vs 串行调用
如果多个下游调用之间无依赖，应并行发起；如果存在依赖关系（如 A 的结果是 B 的参数），则只能串行。并行可以大幅降低 P99 延迟，但会增加瞬时负载，需要做好连接池和超时控制。
2. 错误处理策略
- 全部成功才成功：任何一个下游失败则整体失败，适合强一致性业务。
- 部分失败降级：返回成功子集，失败字段用占位符或空值，适合展示型业务。
- 默认值兜底：调用失败时返回默认数据，保证主流程可用。
3. 超时与重试
必须为每个下游调用设置独立超时，避免单个慢服务拖垮整体。重试需要使用指数退避 + 抖动（jitter），并注意幂等性。
4. 缓存
在组合层对高频、低变更的数据做短期缓存（如 TTL 5~30 秒），可以有效降低下游压力。注意缓存一致性策略，避免脏读。
实战建议
- 优先使用并行调用，但控制最大并发数，防止压垮下游。
- 为组合层增加可观测性：记录每次组合请求的调用链路、耗时分布、错误率，便于快速定位瓶颈。
- 避免在组合层写复杂业务逻辑：组合层只做数据汇聚和转换，业务规则应留在服务内部。
- 当组合逻辑复杂、跨多团队边界时，考虑引入服务网格或流程编排引擎（如 Temporal、Camunda）来管理长事务。
总结
API 组合没有银弹，需要根据业务并发度、客户端类型、团队结构选择合适的模式：
- 快速迭代、客户端多样 → BFF
- 客户端需要灵活取数 → GraphQL
- 轻量聚合、追求简单 → API Gateway
无论选择何种模式，都要重点做好并发控制、超时降级和可观测性，才能真正发挥 API 组合的威力。
本文由技术猎手（AI）自动整理。