事件驱动拓扑是什么
事件驱动架构有两种典型拓扑。Broker 拓扑里没有中心协调者，各组件订阅事件、处理后再发布新事件，链条靠事件自然延伸，耦合低但整体流程是隐式的。Mediator 拓扑由中心编排器调度各步骤，流程定义集中，错误处理与补偿能统一收口，代价是编排器容易演变成瓶颈甚至分布式单体。两者在耦合度、可观测性与变更影响评估上的取向正好相反，也常在同一系统里分层组合使用。
基本信息
| Broker 拓扑 | 事件链式触发，无中心组件，依赖事件契约维系 |
|---|---|
| Mediator 拓扑 | 中心编排器按流程定义调度步骤，状态集中在流程实例 |
| 选择依据 | 步骤数量、参与者稳定性、是否有严格补偿顺序 |
| 可观测性 | Broker 需要跨事件追踪；Mediator 可查流程实例状态 |
| 组合方式 | 大流程用编排器分段，段内用事件链，兼顾清晰与解耦 |
典型使用场景
- 订单履约：订单创建后依次触发库存、支付、发货，步骤固定时用编排器更易管控
- 通知与积分：与主流程弱相关的动作，用事件广播让各消费者自理
- 多步骤带补偿的长流程：退款、改签等需要逆序补偿，编排器统一处理更清晰
- 插件式扩展：新消费者只需订阅事件，不必改动发布方，适合用 Broker
- 跨团队集成：事件契约稳定时，各团队按事件自治，避免流程耦合
- 审批与工单：步骤明确、需要可视化跟踪进度的流程，用编排器更合适
两种拓扑对比
| 维度 | Broker 拓扑 | Mediator 拓扑 |
|---|---|---|
| 控制方式 | 事件链式触发，无中心 | 中心编排器按流程定义调度 |
| 耦合 | 低，只依赖事件契约 | 中，依赖编排器与流程定义 |
| 可观测性 | 需要跨事件关联与追踪 | 流程实例状态集中，进度可见 |
| 错误处理 | 各消费者自处理，容易发散 | 编排器统一补偿与重试 |
| 主要风险 | 事件链无人整体负责，出现循环或孤儿事件 | 编排器承载过多规则，退化为分布式单体 |
共享约定
共享约定
# 1 事件命名用过去时，表达已经发生的事实：OrderCreated
# 2 关联标识：同一流程的事件携带统一的 correlation_id，便于串联
# 3 幂等：消费方按事件 ID 去重，两种拓扑都必须遵守
# 4 补偿显式：失败路径对应的补偿订阅方与动作要写清楚
# 5 循环防护：给事件链设置最大跳数与超时，检测自触发循环
# 6 文档：维护事件流向图；新增订阅时同步更新，避免隐式依赖简单链路选 Broker，多步骤且需要严格补偿顺序的流程选 Mediator：判断标准是「谁来为整条链路的最终结果负责」，没有明确答案时不要用纯事件链。
两种拓扑可以分层组合：大流程的前几步用编排器串起来，每个步骤内部用事件驱动处理副作用，复杂度被限制在可控范围内。