我在研究事件驱动架构时了解到了两种架构,分别是事件溯源(Event Sourcing)和事件驱动架构(Event Driven Architecture)。
我的理解如下:
事件驱动:
- 用于分布式事务,例如Saga。
- 事件被推送到消息队列中,监听器监听并执行相应操作。
事件溯源:
- 用于模式,例如CQRS。
- 事件负责保存数据或同步数据库。
但是我没有理解的是,为什么在事件驱动中无法回放事件而事件溯源可以得到整个事务。
如果有人能用现实生活的例子来进行描述将会很有帮助。
我在研究事件驱动架构时了解到了两种架构,分别是事件溯源(Event Sourcing)和事件驱动架构(Event Driven Architecture)。
我的理解如下:
事件驱动:
事件溯源:
但是我没有理解的是,为什么在事件驱动中无法回放事件而事件溯源可以得到整个事务。
如果有人能用现实生活的例子来进行描述将会很有帮助。
事件驱动架构(Event Driven Architecture)是指组件之间通过发布事件来进行通信,而不是进行RPC调用或操作共享状态。这是一种通信策略(尽管这种策略通常依赖于消息在相当长的时间内持久化)。
事件溯源(Event Sourcing)是指组件本身将其持久化的事件历史作为真相的最终来源,至少对于它们实际关心的状态是如此。这是一种持久性策略,并不内在地涉及通信。事件溯源与CQRS并没有内在联系(尽管基于事件的系统经常发现CQRS作为一种允许查询的方式非常有用,因为查询需要重播一个非常重要的事件子集以使用更优化的数据模型;同样,在CQRS中使用事件溯源持久性模型处理命令也具有一些优点)。
持久化的事件是真相的最终来源意味着事件重播可以恢复状态(根据定义,如果事件重播无法恢复状态,则事件不是真相的最终来源)。
事件溯源是为了自己的使用而保留日志,以便不会遗忘。事件驱动架构则是关于向其他人通报发生了什么。通常,EDA中的组件无法从它们发布的事件中恢复其状态的完整性,因为并非所有改变其状态的事物都值得发布。仅接受由其他组件发布的事件作为输入的组件能够基于重放这些事件来恢复其状态(尽管在许多情况下,按照与其发布顺序相同的顺序重放它们非常困难...),但我认为这是命令来源,而不是事件溯源,因为由一个组件发布的事件在被另一个组件消耗时是一个命令(该命令是“尝试将此事件纳入您对世界的看法中”)。
事件溯源组件中的事件日志是推导要在事件驱动架构中发布事件的非常好的(甚至可以说是最优化的)来源,因此事件溯源组件可以成为事件驱动架构的一部分。
例如,考虑由关系型数据库支持的购物车服务。在数据库中,购物车由表中的一行和表表示,该表代表了具有“ABC购物车中有2个USB充电器,每个价格为$4.75”的行。要将项目添加到购物车中,我们向表插入(或更新,如果只是数量更改)行。当购物车结算时,我们发布购物车及其内容的JSON表示形式,以便运输服务拥有购物车中的物品,并将设置为。最后的事件(连同与事件相关联的元数据“ABC购物车”)可用于生成要发布的事件。需要注意的一点是,除了这些事件以外,没有其他内容被写入数据库。
就事件驱动架构而言,这两个购物车服务基本相同:它们发布相同的结账事件。使用事件源实现只是其中一个服务的实现细节。