架构模式: 事件驱动模式

架构模式: 事件驱动模式

问题

您已应用每服务数据库模式。每个服务都有自己的数据库。但是，某些业务事务跨越多个服务，因此您需要一种机制来确保服务之间的数据一致性。

例如，假设您正在建立一个客户有信用额度的电子商务商店。申请必须确保新订单不会超过客户的信用额度。由于订单和客户位于不同的数据库中，因此应用程序不能简单地使用本地ACID事务。从理论上讲，它可以使用跨越客户服务和订单服务的分布式事务。但是，由于各种原因，分布式事务对于大多数现代应用程序来说不是可行的选择。

解决方案

使用事件驱动的，最终一致的方法。每个服务在更新其数据时都会发布事件。其他服务订阅活动。收到事件后，服务会更新其数据。

结果上下文

这种模式具有以下好处：

• 它使应用程序能够跨多个服务维护数据一致性，而无需使用分布式事务

该解决方案具有以下缺点：

• 编程模型更复杂

还有以下问题需要解决：

• 为了可靠，应用程序必须以原子方式更新其数据库并发布事件。它不能使用跨越数据库和消息代理的分布式事务的传统机制。相反，它必须使用下面列出的模式之一。
•  

例子

使用此方法的电子商务应用程序将按如下方式工作：

1. 订单服务创建处于挂起状态的订单并发布OrderCreated事件。
2. 客户服务部门收到该活动并尝试为该订单保留信用。然后它发布Credit Reserved事件或CreditLimitExceeded事件。
3. 订单服务从客户服务部门接收事件，并将订单状态更改为已批准或已取消

相关模式

• 每个服务数据库模式创建了对此模式的需求
• 以下模式是以原子方式更新状态和发布事件的方法：
  • Event sourcing
  • Transactional Outbox
  • Database triggers
  • Transaction log tailing