架構模式: 事件驅動模式

問題

您已應用每服務數據庫模式。每個服務都有自己的數據庫。但是，某些業務事務跨越多個服務，因此您需要一種機制來確保服務之間的數據一致性。

例如，假設您正在建立一個客戶有信用額度的電子商務商店。申請必須確保新訂單不會超過客戶的信用額度。由於訂單和客戶位於不同的數據庫中，因此應用程序不能簡單地使用本地ACID事務。從理論上講，它可以使用跨越客戶服務和訂單服務的分布式事務。但是，由於各種原因，分布式事務對於大多數現代應用程序來說不是可行的選擇。

解決方案

使用事件驅動的，最終一致的方法。每個服務在更新其數據時都會發布事件。其他服務訂閱活動。收到事件后，服務會更新其數據。

結果上下文

這種模式具有以下好處：

• 它使應用程序能夠跨多個服務維護數據一致性，而無需使用分布式事務

該解決方案具有以下缺點：

• 編程模型更復雜

還有以下問題需要解決：

• 為了可靠，應用程序必須以原子方式更新其數據庫並發布事件。它不能使用跨越數據庫和消息代理的分布式事務的傳統機制。相反，它必須使用下面列出的模式之一。
•  

例子

使用此方法的電子商務應用程序將按如下方式工作：

1. 訂單服務創建處於掛起狀態的訂單並發布OrderCreated事件。
2. 客戶服務部門收到該活動並嘗試為該訂單保留信用。然后它發布Credit Reserved事件或CreditLimitExceeded事件。
3. 訂單服務從客戶服務部門接收事件，並將訂單狀態更改為已批准或已取消

相關模式

• 每個服務數據庫模式創建了對此模式的需求
• 以下模式是以原子方式更新狀態和發布事件的方法：
  • Event sourcing
  • Transactional Outbox
  • Database triggers
  • Transaction log tailing