架构模式: 事件驱动模式
问题
您已应用每服务数据库模式。每个服务都有自己的数据库。但是，某些业务事务跨越多个服务，因此您需要一种机制来确保服务之间的数据一致性。
例如，假设您正在建立一个客户有信用额度的电子商务商店。申请必须确保新订单不会超过客户的信用额度。由于订单和客户位于不同的数据库中，因此应用程序不能简单地使用本地ACID事务。从理论上讲，它可以使用跨越客户服务和订单服务的分布式事务。但是，由于各种原因，分布式事务对于大多数现代应用程序来说不是可行的选择。
解决方案
使用事件驱动的，最终一致的方法。每个服务在更新其数据时都会发布事件。其他服务订阅活动。收到事件后，服务会更新其数据。
结果上下文
这种模式具有以下好处：
- 它使应用程序能够跨多个服务维护数据一致性，而无需使用分布式事务
该解决方案具有以下缺点：
- 编程模型更复杂
还有以下问题需要解决：
- 为了可靠，应用程序必须以原子方式更新其数据库并发布事件。它不能使用跨越数据库和消息代理的分布式事务的传统机制。相反，它必须使用下面列出的模式之一。
例子
使用此方法的电子商务应用程序将按如下方式工作：
- 订单服务创建处于挂起状态的订单并发布OrderCreated事件。
- 客户服务部门收到该活动并尝试为该订单保留信用。然后它发布Credit Reserved事件或CreditLimitExceeded事件。
- 订单服务从客户服务部门接收事件，并将订单状态更改为已批准或已取消
相关模式
- 每个服务数据库模式创建了对此模式的需求
- 以下模式是以原子方式更新状态和发布事件的方法：
- Event sourcing
- Transactional Outbox
- Database triggers
- Transaction log tailing