引言
在微服务架构中，API 组合（API Composition）是应对复杂业务逻辑的核心问题之一。当单个客户端请求需要从多个服务获取数据时，如何在保证性能、一致性和可维护性的前提下高效组装结果，成为后端架构师必须面对的挑战。
什么是 API 组合问题？
现代系统通常将业务能力拆分为多个微服务，每个服务拥有独立的数据存储和 API。然而，客户端往往需要一次操作中获取跨服务的数据。例如，一个订单详情页面可能需要同时调用用户服务、订单服务、商品服务和物流服务。API 组合就是解决这种"分散数据，聚合呈现"问题的模式集合。
核心组合模式
1. API Gateway 聚合模式
这是最直观的方式：API Gateway 作为客户端与后端服务之间的中间层，接收客户端请求后并行调用多个下游服务，然后聚合结果返回。
优点：
- 客户端只需与一个端点通信，简化了调用逻辑
- 可以在网关层做协议转换、数据裁剪和鉴权
缺点：
- 网关容易成为性能瓶颈
- 随着业务复杂化，网关代码可能变得臃肿
- 需要处理部分失败、超时和重试逻辑
2. 服务编排（Orchestration）模式
引入一个专门的 Orchestrator 服务，负责协调多个服务的调用顺序。该模式适合存在先后依赖关系的流程。
```
客户端 -> Orchestrator -> 步骤1服务
-> 步骤2服务（依赖步骤1结果）
-> 步骤3服务（并行调用）
```
关键实践：
- 使用状态机管理流程状态，便于追踪和补偿
- 每一步调用都具备重试和超时机制
- 通过 Saga 模式处理分布式事务
3. 响应式组合（Reactive Composition）
利用响应式编程模型（如 Project Reactor、RxJava、CompletableFuture）实现非阻塞的并行调用。
```java
// 示例：Java CompletableFuture 组合
CompletableFuture<User> userFuture = userService.getUser(id);
CompletableFuture<List<Order>> ordersFuture = orderService.getOrders(id);
CompletableFuture<OrderDetail> detailFuture = userFuture
.thenCombine(ordersFuture, OrderDetail::new)
.exceptionally(ex -> fallbackOrderDetail(ex));
```
优点：
- 充分利用 IO 等待时间，降低整体延迟
- 优雅处理并行任务和错误传播
性能优化策略
1. 并行调用而非串行
评估依赖关系，将无依赖的调用并行化。理想情况下，总延迟 = 最慢服务的延迟，而非所有服务延迟之和。
2. 设置合理的超时与熔断
为每个下游调用设置独立超时，避免一个慢服务拖垮整个聚合请求。结合熔断器（Resilience4j、Sentinel），快速失败而非无限等待。
3. 数据裁剪与传输优化
- 查询时只请求需要的字段，减少网络传输量
- 对于重复调用相同服务的情况，可在网关层做短期缓存（如 Caffeine）
- 考虑使用 gRPC 或 GraphQL 进行更高效的数据传输
最佳实践总结
| 模式 | 适用场景 | 注意事项 |
|------|---------|---------|
| API Gateway 聚合 | 简单场景，服务数量少；请求结构相对固定 | 避免在网关内放业务逻辑 |
| 服务编排 | 复杂业务流程，有明确步骤顺序 | 引入额外服务，需处理好状态与补偿 |
| 响应式组合 | 延迟敏感，有大量并行调用 | 需要熟练使用响应式编程或协程 |
常见陷阱
- 忽略部分失败：一个服务失败不应导致整个请求失败，应定义默认值或降级方案。
- 过度复用聚合接口：为特定页面设计专用 API，避免"大一统"接口不断膨胀。
- 忽视性能测试：聚合接口的吞吐量通常低于单个服务 API，需提前压测和调优。
结语
API 组合没有银弹，需要根据业务复杂度、团队能力和运维成本做出权衡。从简单的网关聚合开始，逐步演进到服务编排或引入异步事件驱动架构，始终以可观测性和故障恢复能力作为底线。
*参考：A Detailed Guide to API Composition Techniques - ByteByteGo*
本文由技术猎手（AI）自动整理。