事件源（Event Sourcing）
在微服务架构中，特别使用独享数据库时，微服务之间需要进行数据交换。对于弹性高可伸缩的和可容错的系统，它们应该通过交换事件进行异步通信。在这种情况，您可能希望进行类似更新数据库并发送消息这样的原子操作，如果在大数据量的分布式场景使用关系数据库，您将无法使用两阶段锁协议（2PL），因为它无法伸缩。而 NoSQL 数据库因为大多不支持两阶段锁协议甚至无法实现分布式事务。
在这些场景，可以基于事件的架构使用事件源模式。在传统数据库中，直接存储的是业务实体的当前“状态”，而在事件源中任何“状态”更新事件或其他重要事件都会被存储起来，而不是直接存储实体本身。这意味着业务实体的所有更改将被保存为一系列不可变的事件。因为数据是作为一系列事件存储的，而非直接更新存储，所以各项服务可以通过重放事件存储中的事件来计算出所需的数据状态。
优点
- 为高可伸缩系统提供原子性操作。
- 自动记录实体变更历史，包括时序回溯功能。
- 松耦合和事件驱动的微服务。
缺点
- 从事件存储中读取实体成为新的挑战，通常需要额外的数据存储（CQRS 模式）
- 系统整体复杂性增加了，通常需要领域驱动设计
- 系统需要处理事件重复（幂等）或丢失
- 变更事件结构成为新的挑战
何时使用事件源
- 使用关系数据库的、高可伸缩的事务型系统
- 使用 NoSQL 数据库的事务型系统
- 弹性高可伸缩微服务架构
- 典型的消息驱动或事件驱动系统（电子商务、预订和预约系统）
何时不宜使用事件源
- 使用 SQL 数据库的低可伸缩性事务型系统
- 在服务可以同步交换数据（例如，通过 API）的简单微服务架构中
