Java Composition在微服务架构中的应用

Java Composition 在微服务架构中的应用

一 概念与原则

• 组合优于继承（Favor composition over inheritance）：在微服务中优先通过“服务通过 API 协作”来复用与扩展能力，避免以“继承框架/基类”来组织业务，从而降低耦合、保持业务逻辑封闭性，并减少跨团队的管理倒置与协同成本。
• 组合模式要点：以“接口/抽象定义能力、容器类持有并委托组件、运行时可替换组件”的方式构建对象与行为，从而获得更好的灵活性、可维护性与更浅的继承层次。

二 典型落地场景

• API 组合模式（API Composition）用于跨服务查询
  • 场景：订单详情页需要聚合订单/厨房/配送/账务等多服务数据。
  • 做法：由API Composer（可为前端、BFF或API 网关）按主键/外键并行调用各服务的查询 API，再将结果组合为视图对象返回。
  • 选型建议：数据按主键可定位、查询为主、对最终一致性容忍度较高时优先采用；若查询复杂或性能要求高，可评估 CQRS/读模型。
• 服务内组合（对象组合）用于可插拔能力与横切关注点
  • 场景：在 Java/Spring 服务内将校验、风控、审计、缓存、消息等抽象为组件，由组合容器持有并按需装配与替换，形成不同的处理管道/策略。
  • 做法：定义统一组件接口，通过构造函数/Setter/工厂注入；容器在执行业务时委托各组件完成具体步骤，便于单元测试与运行时替换。

三 模式对比与选型

• 补充：当查询强一致、跨多服务聚合代价过高时，可引入 CQRS 维护读模型/视图数据库以支撑高效查询。

四 Java 代码示例

• 服务内组合（组合模式 + Spring 风格）

// 1) 组件接口
interface Step { void execute(Context ctx); }

// 2) 具体组件
@Component
class AuthStep implements Step {
  public void execute(Context ctx){ if(!ctx.authenticated) throw new SecurityException("未认证"); }
}
@Component
class PermissionStep implements Step {
  public void execute(Context ctx){ if(!ctx.hasPermission) throw new AccessDeniedException("无权限"); }
}
@Component
class BusinessStep implements Step {
  public void execute(Context ctx){ ctx.result = "OK"; }
}

// 3) 组合容器（编排与委托）
@Component
class WorkflowProcessor {
  private final List<Step> steps;
  // 通过构造注入，形成可插拔管道
  public WorkflowProcessor(AuthStep auth, PermissionStep perm, BusinessStep biz){
    this.steps = List.of(auth, perm, biz);
  }
  public void process(Context ctx){
    for(var s : steps) s.execute(ctx);
  }
}

// 4) 上下文与使用示例
class Context { boolean authenticated; boolean hasPermission; String result; }

// 在Controller/Service中注入 WorkflowProcessor 并调用

• API 组合（BFF 聚合示例）

@RestController @RequestMapping("/api/order")
public class OrderController {
  @Autowired private OrderServiceClient orderClient;
  @Autowired private KitchenServiceClient kitchenClient;
  @Autowired private DeliveryServiceClient deliveryClient;
  @Autowired private AccountingServiceClient accountingClient;

  @GetMapping("/{id}")
  public OrderDetails findOrder(@PathVariable String id){
    var o = orderClient.findById(id);
    var k = kitchenClient.findByOrderId(id);
    var d = deliveryClient.findByOrderId(id);
    var a = accountingClient.findByOrderId(id);
    return OrderDetails.builder()
      .orderId(o.id).status(o.status).payStatus(a.status)
      .prepareStatus(k.status).estimatedPrepareTime(k.estimate)
      .deliveryStatus(d.status).estimatedDeliveryTime(d.estimate)
      .build();
  }
}

• 工程要点
  • 为各下游服务定义清晰 DTO/契约与错误码；在 BFF 层做并行调用与超时/降级/熔断；必要时引入缓存与读模型优化查询性能。

五 实践建议

• 优先组合、慎用继承：服务边界以 API 协作，避免把业务塞进框架继承体系，减少管理倒置与逻辑封闭性破坏。
• 明确 Composer 的位置：跨服务查询优先由BFF/网关承担；若由客户端聚合，需确保同域网络与性能可控。
• 面向接口编程与依赖注入：服务内以接口+DI装配组件，便于替换/测试与A/B实验；为组件定义统一执行接口以便编排。
• 可观测性与容错：为聚合链路提供日志/指标/追踪，并实现超时、重试、降级、熔断策略，避免雪崩。
• 文档与契约：为 API Composer 与各下游服务维护一致且可执行的契约/示例，降低协同成本与误用风险。