一、聚合器微服务模式（Aggregator）

核心思想

一个聚合服务作为中间层，接收客户端请求，并行/串行调用多个底层原子微服务，汇总、加工各服务返回数据，统一组装成完整结果返回前端。

适用场景

1. 前端页面需要多模块数据（订单+用户+商品+物流信息）；
2. 底层服务拆分细碎，客户端多次调用成本高；
3. 需要统一数据格式、字段合并、过滤、计算。

流程

客户端 → 聚合服务 → 并行调用服务A/服务B/服务C → 聚合服务整合数据 → 返回统一VO

优缺点

• 优点：简化前端、统一数据处理、减少客户端网络请求；
• 缺点：聚合服务成为性能瓶颈，聚合逻辑复杂后维护成本高。

二、代理微服务模式（Proxy / Gateway Proxy）

核心思想

代理服务（网关/中转服务）仅做请求转发、路由、协议转换，不做数据聚合与业务计算，直接透传客户端请求至目标微服务，原样返回下游结果。

细分两类

1. 反向代理网关：API网关，负责路由、鉴权、限流、SSL、日志；
2. 服务代理：内部服务中转，用于协议兼容（HTTP转Dubbo/gRPC）、旧系统适配。

适用场景

1. 统一入口管控所有微服务（API网关最典型）；
2. 新旧技术栈互通，协议转换；
3. 统一拦截切面：认证、监控、熔断。

流程

客户端 → 代理服务（鉴权/路由）→ 直达目标微服务 → 原数据原路返回

优缺点

• 优点：解耦客户端与服务地址、统一管控流量、协议兼容；
• 缺点：仅转发无数据处理，多数据组合场景不适用。

三、分支微服务模式（Branch）

核心思想

聚合器模式的扩展，支持条件分支调用：根据请求参数动态判断调用哪些下游服务，部分分支并行执行、部分按需跳过，灵活组合多服务调用。

与聚合器区别

聚合器固定调用全部依赖服务；分支模式按需选择性调用，带业务判断逻辑。

适用场景

1. 多业务分支：下单时，普通商品调库存，虚拟商品跳过物流；
2. 动态多渠道查询：根据用户身份走不同数据源；
3. 复杂多条件组合查询。

流程

客户端 → 分支服务 → 根据参数判断分支： 分支1：调用服务A、B 分支2：仅调用服务C 分支3：并行A+C → 汇总分支结果统一返回

优缺点

• 优点：调用灵活、减少无效服务请求、适配多分支业务；
• 缺点：分支判断逻辑堆积，易产生复杂业务耦合。

三者核心对比表

注意：本文归作者所有，未经作者允许，不得转载