event-driven-architecture

事件驱动架构模式

关于设计、实现和运维事件驱动系统的专家指南，涵盖事件溯源、CQRS、消息代理、Saga 协调和最终一致性管理等经过验证的模式。

何时使用此技能

• 设计采用异步、解耦通信的系统
• 实现事件溯源和 CQRS 模式
• 构建需要最终一致性和高可扩展性的系统
• 管理微服务之间的分布式事务
• 处理实时事件流和数据管道
• 实现发布-订阅或消息队列架构
• 设计具有复杂事件流的响应式系统

核心原则

1. 将事件视为一等公民

事件表示系统中已经发生的不可变事实。使用过去时命名（OrderCreated、PaymentProcessed），并包含所有必要的上下文。

2. 最终一致性

系统在一段时间后达成一致，而非立即达成。以牺牲强一致性为代价，换取更高的可用性和可扩展性。

3. 松散耦合

服务通过事件通信，不存在直接依赖，从而能够独立演进和部署。

4. 异步通信

操作不会阻塞等待响应，从而提升系统响应能力和韧性。

5. 事件驱动思维

围绕发生了什么（事件）而非要做什么（命令）进行设计。

快速参考

主题	加载参考资料
事件结构、类型和特征	skills/event-driven-architecture/references/event-fundamentals.md
事件溯源模式及其实现	skills/event-driven-architecture/references/event-sourcing.md
采用读写分离的 CQRS 模式	skills/event-driven-architecture/references/cqrs.md
消息代理（RabbitMQ、Kafka、SQS/SNS）	skills/event-driven-architecture/references/message-brokers.md
用于分布式事务的 Saga 模式	skills/event-driven-architecture/references/saga-pattern.md
编排与协同模式	skills/event-driven-architecture/references/choreography-orchestration.md
最终一致性和冲突解决	skills/event-driven-architecture/references/eventual-consistency.md
最佳实践、反模式和测试	skills/event-driven-architecture/references/best-practices.md

工作流

1. 设计阶段

• 识别事件：需要捕获哪些业务事实？
• 定义边界：哪些事件属于领域事件，哪些属于集成事件？
• 选择模式：事件溯源？CQRS？Saga？协同还是编排？
• 选择技术：高吞吐量场景用 Kafka？路由场景用 RabbitMQ？还是 AWS 托管服务？

2. 实现阶段

• 事件架构：定义带有相关 ID 的版本化事件结构
• 事件存储：实现具有乐观并发控制的只追加存储
• 投影：根据事件创建读模型，以优化查询
• 处理器：确保以幂等方式处理至少一次投递
• Saga：为失败实现补偿事务

3. 运维阶段

• 监控：跟踪事件延迟、处理时间和失败率
• 重放：构建重放事件的能力，以便调试和恢复
• 版本管理：同时支持多个事件架构版本
• 扩展：按聚合 ID 分区，水平扩展消费者
• 测试：通过契约测试，独立测试处理器

常见错误

事件设计错误

• ❌ 使用命令而不是事件（CreateOrder，而不是 OrderCreated）
• ❌ 事件可变或缺少版本管理
• ❌ 事件缺少相关 ID 或因果 ID
• ✓ 使用不可变、过去时、自包含的事件

一致性问题

• ❌ 假设服务之间能立即保持一致
• ❌ 未处理重复事件投递
• ❌ 处理器缺少幂等性
• ✓ 面向最终一致性进行设计，并使用幂等处理器

架构误区

• ❌ 同步事件链（等待响应）
• ❌ 事件与特定服务实现耦合
• ❌ 缺少 Saga 补偿策略
• ✓ 异步即发即忘、聚焦领域的事件、补偿事务

运维缺口

• ❌ 不支持事件重放
• ❌ 缺少事件延迟监控
• ❌ 没有架构注册表或版本管理
• ✓ 支持重放、受到监控且由架构管理的事件

模式选择指南

适用事件溯源的场景：

• 需要完整记录所有变更的审计跟踪
• 需要时间查询（“时间 T 时的状态”）
• 基于相同事件构建多个投影
• 通过事件重放进行调试或恢复

适用 CQRS 的场景：

• 读写比高（10:1 以上）
• 查询需求复杂
• 需要独立扩展读取能力
• 读写分别采用不同的最优数据库

适用 Saga 的场景：

• 跨服务分布式事务
• 需要在不使用 2PC 的情况下实现原子性
• 复杂的多步骤工作流
• 需要补偿逻辑

选择编排式的场景：

• 工作流简单（2–4 个步骤）
• 希望服务具有高度自治性
• 已建立事件驱动文化
• 没有复杂依赖

选择协调式的场景：

• 工作流复杂（5 个以上步骤）
• 存在顺序依赖
• 需要集中式可见性
• 工作流中包含业务逻辑

资源

• 书籍：“Designing Event-Driven Systems”（Stopford），“Versioning in an Event Sourced System”（Young）
• 网站：eventuate.io、event-driven.io、Martin Fowler 的事件溯源文章
• 工具：Kafka、EventStoreDB、RabbitMQ、Axon Framework、MassTransit
• 模式：事件溯源、CQRS、Saga、Outbox、CDC、事件流