event-driven-architecture
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseEvent-Driven Architecture Patterns
事件驱动架构模式
Expert guidance for designing, implementing, and operating event-driven systems with proven patterns for event sourcing, CQRS, message brokers, saga coordination, and eventual consistency management.
本文提供设计、实现和运维事件驱动系统的专业指南，涵盖经过验证的事件溯源（Event Sourcing）、CQRS、消息中间件、Saga协调以及最终一致性管理等模式。
When to Use This Skill
适用场景
- Designing systems with asynchronous, decoupled communication
- Implementing event sourcing and CQRS patterns
- Building systems requiring eventual consistency and high scalability
- Managing distributed transactions across microservices
- Processing real-time event streams and data pipelines
- Implementing publish-subscribe or message queue architectures
- Designing reactive systems with complex event flows
- 设计采用异步、解耦通信的系统
- 实现事件溯源（Event Sourcing）和CQRS模式
- 构建需要最终一致性与高可扩展性的系统
- 管理跨微服务的分布式事务
- 处理实时事件流与数据管道
- 实现发布-订阅或消息队列架构
- 设计具有复杂事件流的响应式系统
Core Principles
核心原则
1. Events as First-Class Citizens
1. 事件作为一等公民
Events represent immutable facts that have occurred in the system. Use past tense naming (OrderCreated, PaymentProcessed) and include all necessary context.
事件代表系统中已发生的不可变事实。使用过去式命名（如OrderCreated、PaymentProcessed），并包含所有必要上下文。
2. Eventual Consistency
2. 最终一致性
Systems achieve consistency over time rather than immediately. Trade strong consistency for higher availability and scalability.
系统通过时间推移达到一致性，而非即时一致性。以强一致性换取更高的可用性与可扩展性。
3. Loose Coupling
3. 松耦合
Services communicate through events without direct dependencies, enabling independent evolution and deployment.
服务通过事件通信，无直接依赖，支持独立演进与部署。
4. Asynchronous Communication
4. 异步通信
Operations don't block waiting for responses, improving system responsiveness and resilience.
操作无需阻塞等待响应，提升系统响应能力与韧性。
5. Event-Driven Thinking
5. 事件驱动思维
Design around what happened (events) rather than what to do (commands).
围绕已发生的事实（事件）而非需要执行的操作（命令）进行设计。
Quick Reference
快速参考
| Topic | Load reference |
|---|---|
| Event structure, types, and characteristics | |
| Event sourcing pattern and implementation | |
| CQRS pattern with read/write separation | |
| Message brokers (RabbitMQ, Kafka, SQS/SNS) | |
| Saga pattern for distributed transactions | |
| Choreography vs orchestration patterns | |
| Eventual consistency and conflict resolution | |
| Best practices, anti-patterns, testing | |
| 主题 | 参考文档路径 |
|---|---|
| 事件结构、类型与特性 | |
| 事件溯源模式与实现 | |
| 读写分离的CQRS模式 | |
| 消息中间件（RabbitMQ、Kafka、SQS/SNS） | |
| 分布式事务的Saga模式 | |
| 编排与Choreography模式对比 | |
| 最终一致性与冲突解决 | |
| 最佳实践、反模式与测试 | |
Workflow
工作流程
1. Design Phase
1. 设计阶段
- Identify Events: What business facts need to be captured?
- Define Boundaries: Which events are domain vs integration events?
- Choose Patterns: Event sourcing? CQRS? Sagas? Choreography or orchestration?
- Select Technology: Kafka for high throughput? RabbitMQ for routing? AWS managed services?
- 识别事件：需要捕获哪些业务事实？
- 定义边界：哪些是领域事件，哪些是集成事件？
- 选择模式：事件溯源？CQRS？Saga？编排还是Choreography？
- 选择技术：高吞吐量场景选Kafka？路由场景选RabbitMQ？还是AWS托管服务？
2. Implementation Phase
2. 实现阶段
- Event Schema: Define versioned event structures with correlation IDs
- Event Store: Implement append-only storage with optimistic concurrency
- Projections: Create read models from events for query optimization
- Handlers: Ensure idempotent, at-least-once delivery handling
- Sagas: Implement compensating transactions for failures
- 事件Schema：定义带关联ID的版本化事件结构
- 事件存储：实现带乐观并发控制的追加式存储
- 投影：从事件中创建读模型以优化查询
- 处理器：确保幂等性、至少一次交付的处理逻辑
- Sagas：为故障场景实现补偿事务
3. Operation Phase
3. 运维阶段
- Monitoring: Track event lag, processing time, failure rates
- Replay: Build capability to replay events for debugging/recovery
- Versioning: Support multiple event schema versions simultaneously
- Scaling: Partition by aggregate ID, scale consumers horizontally
- Testing: Test handlers in isolation with contract testing
- 监控：跟踪事件延迟、处理时间、失败率
- 重放：构建事件重放能力以用于调试/恢复
- 版本管理：同时支持多个事件Schema版本
- 扩容：按聚合ID分区，水平扩展消费者
- 测试：通过契约测试隔离测试处理器
Common Mistakes
常见错误
Event Design Errors
事件设计错误
- ❌ Using commands instead of events (CreateOrder vs OrderCreated)
- ❌ Mutable events or missing versioning
- ❌ Events without correlation/causation IDs
- ✓ Immutable, past-tense, self-contained events
- ❌ 使用命令而非事件（例如用CreateOrder代替OrderCreated）
- ❌ 事件可变或缺少版本管理
- ❌ 事件未包含关联/因果ID
- ✅ 不可变、过去式、自包含的事件
Consistency Issues
一致性问题
- ❌ Assuming immediate consistency across services
- ❌ Not handling duplicate event delivery
- ❌ Missing idempotency in handlers
- ✓ Design for eventual consistency, idempotent handlers
- ❌ 假设跨服务的即时一致性
- ❌ 未处理重复事件交付
- ❌ 处理器缺乏幂等性
- ✅ 按最终一致性设计，实现幂等处理器
Architecture Mistakes
架构错误
- ❌ Synchronous event chains (waiting for responses)
- ❌ Events coupled to specific service implementations
- ❌ No compensation strategy for sagas
- ✓ Async fire-and-forget, domain-focused events, compensating transactions
- ❌ 同步事件链（等待响应）
- ❌ 事件与特定服务实现耦合
- ❌ Saga无补偿策略
- ✅ 异步即发即弃、聚焦领域的事件、补偿事务
Operational Gaps
运维缺口
- ❌ No event replay capability
- ❌ Missing monitoring for event lag
- ❌ No schema registry or version management
- ✓ Replay-ready, monitored, schema-managed events
- ❌ 无事件重放能力
- ❌ 缺少事件延迟监控
- ❌ 无Schema注册表或版本管理
- ✅ 支持重放、可监控、Schema受控的事件
Pattern Selection Guide
模式选择指南
Use Event Sourcing When:
何时使用事件溯源：
- Need complete audit trail of all changes
- Temporal queries required ("state at time T")
- Multiple projections from same events
- Event replay for debugging/recovery
- 需要完整的变更审计追踪
- 需执行时态查询（如“时间点T的系统状态”）
- 从同一事件生成多个投影
- 需通过事件重放进行调试/恢复
Use CQRS When:
何时使用CQRS：
- High read:write ratio (10:1+)
- Complex query requirements
- Need to scale reads independently
- Different databases for read/write optimal
- 读写比高（10:1以上）
- 查询需求复杂
- 需要独立扩展读能力
- 读写操作需使用不同的最优数据库
Use Sagas When:
何时使用Saga：
- Distributed transactions across services
- Need atomicity without 2PC
- Complex multi-step workflows
- Compensation logic required
- 跨服务的分布式事务
- 无需两阶段提交（2PC）即可实现原子性
- 复杂的多步骤工作流
- 需要补偿逻辑
Choose Choreography When:
何时选择Choreography：
- Simple workflows (2-4 steps)
- High service autonomy desired
- Event-driven culture established
- No complex dependencies
- 简单工作流（2-4步）
- 期望高服务自治性
- 已建立事件驱动文化
- 无复杂依赖
Choose Orchestration When:
何时选择编排：
- Complex workflows (5+ steps)
- Sequential dependencies
- Need centralized visibility
- Business logic in workflow
- 复杂工作流（5步以上）
- 存在顺序依赖
- 需要集中式可见性
- 工作流中包含业务逻辑
Resources
资源
- Books: "Designing Event-Driven Systems" (Stopford), "Versioning in an Event Sourced System" (Young)
- Sites: eventuate.io, event-driven.io, Martin Fowler's event sourcing articles
- Tools: Kafka, EventStoreDB, RabbitMQ, Axon Framework, MassTransit
- Patterns: Event Sourcing, CQRS, Saga, Outbox, CDC, Event Streaming
- 书籍：《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
- 模式：Event Sourcing、CQRS、Saga、Outbox、CDC、Event Streaming