事件溯源模式

事件溯源模式通常与 CQRS 模式 一起使用，以将读取与写入工作负载分离，并优化性能、可扩展性和安全性。数据以一系列事件的形式存储，而不是直接更新数据存储。微服务重播事件存储中的事件，以计算其数据存储的适当状态。此模式为应用程序的当前状态提供了可见性，并提供了有关应用程序如何实现该状态的附加上下文。事件溯源模式可与 CQRS 模式有效配合，因为即使命令和查询数据存储具有不同的架构，也可以为特定事件复制数据。

通过选择此模式，您可以识别并重建应用程序在任何时间点的状态。这会生成持久的审计跟踪记录，并使调试变得更加容易。但是，数据最终会变得一致，这可能不适合某些用例。

这种模式可以通过使用 Amazon Kinesis Data Streams 或亚马逊 EventBridge来实现。

Amazon Kinesis Data Streams 实施

在下图中，Kinesis Data Streams 是集中式事件存储的主要组件。事件存储以事件形式获取应用程序的变更，并保存在 Amazon Simple Storage Service (Amazon S3) 上。

工作流程包含以下步骤：

1. 当“/withdraw”或“/credit”微服务发生事件状态变更时，它们会通过将消息写入 Kinesis Data Streams 来发布事件。

2. 其他微服务（例如“/balance”或“/creditLimit”）会读取消息的副本，筛选其相关性，然后将其转发以供进一步处理。

亚马逊的 EventBridge 实施

下图中的架构使用 EventBridge了。 EventBridge 是一项使用事件连接应用程序组件的无服务器服务，这使您可以更轻松地构建可扩展的、事件驱动的应用程序。事件驱动架构是一种构建松散耦合的软件系统的风格，这些系统通过发射和响应事件来协同工作。 EventBridge 为AWS服务发布的事件提供默认事件总线，您还可以为特定域的总线创建自定义事件总线。

工作流程由以下步骤组成：

1. “OrderPlaced” 事件由 “Orders” 微服务发布到自定义事件总线。

2. 需要在下单后采取行动的微服务（例如“/route”微服务）由规则和目标启动。

3. 这些微服务会生成一条将订单运送给客户的路径并发出 “RouteCreated” 事件。

4. 需要采取进一步措施的微服务也是由 “RouteCreated” 事件启动的。

5. 事件被发送到事件存档（例如存 EventBridge 档），以便在需要时可以重播这些事件进行重新处理。

6. 如果需要，历史订单事件会发送到新的 Amazon SQS 队列（重播队列）进行重新处理。

7. 如果目标未启动，则会将受影响的事件放入死信队列 (DLQ) 中，以供进一步分析和重新处理。

若为以下情况，您应该考虑使用这种模式：

• 事件用于完全重建应用程序的状态。

• 您需要在系统中重播事件，并且可以随时确定应用程序的状态。

• 您希望能够撤消特定事件，而不必从空白的应用程序状态开始。

• 您的系统需要可以轻松序列化的事件流，以创建自动日志。

• 您的系统需要大量读取操作，但写入操作较少；可将大量读取操作导向内存数据库，并随事件流不断更新。

重要

如果您使用事件溯源模式，则必须部署 Saga 模式 以保持微服务之间的数据一致性。