本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 事件溯源模式
事件溯源模式通常与 [CQRS 模式](cqrs-pattern.md) 一起使用，以将读取与写入工作负载分离，并优化性能、可扩展性和安全性。数据以一系列事件的形式存储，而不是直接更新数据存储。微服务重播事件存储中的事件，以计算其数据存储的适当状态。此模式为应用程序的当前状态提供了可见性，并提供了有关应用程序如何实现该状态的附加上下文。事件溯源模式可与 CQRS 模式有效配合，因为即使命令和查询数据存储具有不同的架构，也可以为特定事件复制数据。
通过选择此模式，您可以识别并重建应用程序在任何时间点的状态。这会生成持久的审计跟踪记录，并使调试变得更加容易。但是，数据最终会变得一致，这可能不适合某些用例。
这种模式可以通过使用 Amazon Kinesis Data Streams 或亚马逊 EventBridge来实现。
## Amazon Kinesis Data Streams 实施
在下图中，Kinesis Data Streams 是集中式事件存储的主要组件。事件存储以事件形式获取应用程序的变更，并保存在 Amazon Simple Storage Service (Amazon S3) 上。
![\[Amazon Kinesis Data Streams 实施\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/modernization-data-persistence/images/enabling-diagram4.png)
工作流程包含以下步骤：
1. 当“/withdraw”或“/credit”微服务发生事件状态变更时，它们会通过将消息写入 Kinesis Data Streams 来发布事件。
1. 其他微服务（例如“/balance”或“/creditLimit”）会读取消息的副本，筛选其相关性，然后将其转发以供进一步处理。
## 亚马逊的 EventBridge 实施
下图中的架构使用 EventBridge了。 EventBridge 是一项使用事件连接应用程序组件的无服务器服务，这使您可以更轻松地构建可扩展的、事件驱动的应用程序。事件驱动架构是一种构建松散耦合的软件系统的风格，这些系统通过发射和响应事件来协同工作。 EventBridge 为 AWS 服务发布的事件提供[默认事件总线](https://docs.aws.amazon.com//eventbridge/latest/userguide/create-event-bus.html)，您也可以为特定域的[总线创建自定义事件总线](https://docs.aws.amazon.com//eventbridge/latest/userguide/create-event-bus.html)。
![\[亚马逊的 EventBridge 实施\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/modernization-data-persistence/images/enabling-diagram5.png)
工作流程由以下步骤组成：
1. “OrderPlaced” 事件由 “Orders” 微服务发布到自定义事件总线。
1. 需要在下单后采取行动的微服务（例如“/route”微服务）由规则和目标启动。
1. 这些微服务会生成一条将订单运送给客户的路径并发出 “RouteCreated” 事件。
1. 需要采取进一步措施的微服务也是由 “RouteCreated” 事件启动的。
1. 事件被发送到事件存档（例如存 EventBridge 档），以便在需要时可以重播这些事件进行重新处理。
1. 如有需要，历史订单事件会发送到新的 Amazon SQS 队列（重播队列）进行重新处理。
1. 如果目标未启动，则会将受影响的事件放入死信队列 (DLQ) 中，以供进一步分析和重新处理。
若为以下情况，您应该考虑使用这种模式：
+ 事件用于完全重建应用程序的状态。
+ 您需要在系统中重播事件，并且可以随时确定应用程序的状态。
+ 您希望能够撤消特定事件，而不必从空白的应用程序状态开始。
+ 您的系统需要可以轻松序列化的事件流，以创建自动日志。
+ 您的系统需要大量读取操作，但写入操作较少；可将大量读取操作导向内存数据库，并随事件流不断更新。
**重要**
如果您使用事件溯源模式，则必须部署 [Saga 模式](saga-pattern.md) 以保持微服务之间的数据一致性。