架构模式: 事件溯源

架构模式: 事件溯源

问题

您已应用事件驱动的体系结构模式。为了可靠，服务必须在状态发生变化时以原子方式发布事件。使用跨越数据库和消息代理的分布式事务是不可行的。如何在状态发生变化时可靠地/原子地发布事件？

解决方案

这个问题的一个很好的解决方案是使用事件源。事件采购将业务实体（例如订单或客户）的状态保持为一系列状态改变事件。每当业务实体的状态发生变化时，都会在事件列表中附加一个新事件。由于保存事件是单个操作，因此它本质上是原子的。应用程序通过重放事件来重建实体的当前状态。

应用程序将事件保留在事件存储中，事件存储是事件的数据库。商店有一个用于添加和检索实体事件的API。事件存储的行为也类似于消息代理。它提供了一个API，使服务可以订阅事件。当服务在事件存储中保存事件时，它将被传递给所有感兴趣的订户。

例子

下图显示了电子商务系统如何使用事件源来保持订单。
​

 

 

应用程序将每个Order作为一系列事件持久存储，而不是简单地将每个订单的当前状态存储为ORDERS表中的一行。CustomerService可以订阅订单事件并更新其自己的状态。

有关更多详细信息，请参阅Eventuate平台，它是基于事件源和CQRS的应用程序平台。有几个示例应用程序

结果上下文

事件溯源有几个好处：

• 它解决了实现事件驱动架构的关键问题之一，并且可以在状态发生变化时可靠地发布事件。
• 因为它持久存在事件而不是域对象，所以它主要避免了对象 - 关系阻抗不匹配问题。
• 它提供了对业务实体所做更改的100％可靠审计日志
• 它使得实现在任何时间点确定实体状态的时间查询成为可能。
• 基于事件采购的业务逻辑由交换事件的松散耦合的业务实体组成。这使得从单一应用程序迁移到微服务架构变得更加容易。

事件采购也有几个缺点：

• 这是一种不同的，不熟悉的编程风格，因此有一个学习曲线。
• 事件存储很难查询，因为它需要典型的查询来重建业务实体的状态。这可能是复杂而低效的。因此，应用程序必须使用命令查询责任隔离（CQRS）来实现查询。这反过来意味着应用程序必须处理最终一致的数据。

关联模式

• 事件驱动的体系结构模式创建了对此模式的需求。
• CQRS通常用于事件溯源。