arch-event-driven

一句话概述

组件通过经由代理发布和响应事件来通信，而不是彼此直接调用。生产者不知道谁会消费；消费者也不知道事件由谁产生。

何时使用此技能

• 需要独立扩展的松耦合组件。
• 实时数据处理、流处理或分析流水线。
• 各步骤自然形成“发生了 X，现在由 Y 响应”的业务工作流。
• 下游消费者可随时添加或移除，且无需生产者知情的系统。

何时不使用此技能

• 有严格的事务一致性要求——事件最终才会保持一致。
• 同步请求-响应是自然的通信方式——强行改为异步会增加延迟和复杂性。
• 只有少数几个组件且都运行在同一进程中的小型系统——使用事件架构有些大材小用；直接调用更简单。

核心内容

两种拓扑（Richards 和 Ford）：

• 代理拓扑——组件向主题发布事件；订阅者进行消费；没有中央协调者。最适合每一步都是小规模响应的编排式工作流。
• 中介者拓扑——中央中介者负责编排工作流，并向事件处理器发送命令。最适合具有明确步骤顺序、需要某个角色了解完整流程的工作流。

事件与命令。

• 事件描述已发生的事情，使用过去时（OrderPlaced、PaymentSettled）。生产者声明一个事实；订阅者决定是否响应。领域事件（参见 ddd-domain-event）在模型层面体现这一概念；在 EDA 中，相同的事件会经由代理流转。
• 命令是执行某项操作的祈使请求（PlaceOrder、SettlePayment）。它只面向一个特定处理器。事件会扇出；命令则只发给一个目标。

编排与协调。

• 编排——组件独立响应事件；整体工作流由各组件的本地决策逐步形成。去中心化、易于扩展，但难以掌握全局。
• 协调——协调者（中介者、saga、工作流引擎）指示每个组件接下来要做什么。集中化、更易于推理，但复杂性集中在一点。

代理的选择。

• 带持久日志的主题（Kafka）：事件会保留一段时间；订阅者可以重放。适用于分析、审计和后加入的消费者。
• 提供投递保证的队列（RabbitMQ、SQS）：事件投递一次后即被移除。适用于工作队列模式。
• 进程内总线（Spring ApplicationEventPublisher）：事件只在单个 JVM 内传递；开销低；适用于单体应用内部的解耦。

**模式约束。**事件模式是事件驱动系统的公共 API。应像管理任何外部契约一样严格管理版本：只进行向后兼容的变更；新增字段时提供默认值；弃用的字段应保留，直到消费者完成迁移。

决策启发

• 对于步骤不超过 4 个且参与者集合稳定的工作流，选择编排；步骤增多或补偿操作不简单时，选择协调。
• 根据实际需求选择代理：需要重放 → 基于日志；只需投递一次 → 队列；进程内部通信 → 内存总线。
• 在单体应用中采用事件驱动同样可行（进程内事件）——使用 EDA 不需要 Kafka。
• 从一开始就配套使用模式注册表。模式失控漂移时，事件驱动系统会最快腐化。

反模式

• 用命令伪装成事件的“事件驱动”（UpdateOrderEvent）——这仍然是 RPC，只是延迟更高。必须使用过去时命名。
• **事件充当方法调用。**生产者发出事件后，立即监听特定消费者的响应——这是伪装成异步的同步 RPC。如果你需要这样的交互，请使用真正的请求-响应模式。
• **模式混乱。**生产者未经协调就更改事件负载，导致消费者悄无声息地出错。
• **没有重放策略。**关键事件丢失后无法恢复。应审慎选择代理的保留策略。
• **为 12 步工作流使用编排式协作。**没人能理清全貌。应改用编排模式。

另请参阅

• arch-microservices — 事件驱动是微服务的一种常见通信风格（另一种是 REST/gRPC）。
• arch-saga — 通过事件／命令编排分布式事务。
• arch-event-sourcing — 当事件是状态的真实来源，而不只是通信机制时。
• arch-cqrs — 通常与 EDA 配合使用：写入会生成事件；读取则从事件派生的物化视图中投影数据。
• ddd-domain-event — 模型层面的事件概念，通常会成为线上的事件。

参考资料

• Richards 与 Ford，Fundamentals of Software Architecture，第 14 章（事件驱动架构风格）。
• Adam Bellemare，Building Event-Driven Microservices（O'Reilly）。
• Khononov，Learning DDD，第 15 章（事件驱动架构）。