中介者模式如何降低微服务耦合度

中介者模式是微服务架构中应对多服务交叉调用引发的局部网状耦合的轻量级协调方案——它不替代注册中心或网关，不处理业务逻辑、不持有数据、不决策事务，而是以纯事件驱动的方式，专注编排调用顺序、转换上下文、统一兜底重试与降级，将原本散落在各服务中的if-else编排逻辑剥离为独立、透明、职责单一的协调层；用Spring Cloud Function或EventBridge等事件总线实现时，它仅作为消息路由与状态同步的“智能管道”，行云流水地串联订单、库存、积分等有界上下文，让系统真正解耦于协作边界而非徒增一层“上帝服务”。

中介者模式不是微服务的“胶水”，而是协调边界行为的轻量层

中介者模式在微服务中不替代服务注册中心或 API 网关，它解决的是“多个服务在同一个业务流程中频繁交叉调用、彼此感知过多”的局部耦合问题。比如订单创建时，要同时通知库存扣减、积分增加、物流预占、风控校验——如果每个服务都直接调用其他服务，就会形成网状依赖，任意一个下游变更都可能波及全部。

这时中介者（通常是一个轻量级协调服务或模块）不处理业务逻辑，只负责编排调用顺序、转换上下文、兜底失败重试或降级，把“谁该什么时候调谁”从各服务代码里抽出来。

• 它不持有业务数据，也不参与事务决策，只做消息路由和状态同步
• 适合出现在跨域协作场景，例如“履约中心”作为中介协调订单、仓储、配送三个有界上下文
• 不能替代 Saga 或 TCC 分布式事务，但可封装其执行逻辑，降低各服务对补偿流程的感知

用 Spring Cloud Function + EventBridge 实现轻量中介者

避免自建重逻辑中介服务，优先利用事件驱动能力解耦。以 AWS EventBridge 或 Spring Cloud Stream 为例，中介者本质是事件处理器：

• 定义统一事件类型：OrderCreatedEvent、InventoryReservedEvent
• 中介服务订阅 OrderCreatedEvent，触发并行/串行下游事件：ReserveInventoryCommand、GrantPointsCommand
• 各微服务只监听自己关心的命令事件，不依赖对方的 HTTP 接口或 SDK
• 失败时由中介服务发 CompensateOrderCreationEvent，而非让订单服务硬编码调用库存回滚接口

关键不是写多少代码，而是把 if-else 编排逻辑、重试策略、超时熔断规则，从订单服务的 OrderService.create() 方法里移出，放到独立的 OrderOrchestrator 中。

容易踩的坑：把中介者写成“上帝服务”

常见错误是让中介者承担太多：查数据库、做风控判断、生成 PDF、发短信——这违背了单一职责，反而制造新的单点瓶颈和部署僵化。

• 中介者函数体应控制在 200 行以内，纯编排，无业务规则
• 禁止在中介者里调用 InventoryService.reserve() 这类具体方法，只发事件或调用 inventory-reserve 这类抽象通道
• 不要给中介者加缓存或复杂配置，它应该像管道一样透明；所有可观测性（traceId 透传、耗时打点）必须保留，否则链路追踪会断在中介节点
• 如果发现中介者需要访问 3 个以上数据库或调用 5+ 外部系统，说明拆分粒度错了，应回头审视有界上下文是否合理

什么时候不该用中介者？

两个服务之间只有简单的一对一同步调用（如用户服务查角色权限），用 REST 或 gRPC 直连更清晰。中介者的价值只在“一对多”“多对一”或“多对多”的协作流中显现。

真正难的不是写中介者，是识别哪些交互属于同一业务闭环——这需要领域事件建模能力，而不是设计模式套用。很多团队强行加一层中介，结果把 OrderService 和 PaymentService 的耦合，转成了跟 OrderMediator 的耦合，而后者又依赖两者，等于没解耦。

今天关于《中介者模式如何降低微服务耦合度》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！