研究了事件採購/事件溯源，Saga和CQRS模式如何影響微服務的發展。

微服務架構風格現在在業界獲得了極大的普及。越來越多的組織希望轉向微服務架構。

但是，構建微服務並不容易。 在這篇文章中，我們將看看三個可以幫助您建立微服務的重要模式。

事件溯源/事件採購

EventSourcing事件溯源試圖解決圍繞原子更新資料庫以及釋出事件的問題。

這意味著當您在領域實體上執行某些操作時，可以將其視為領域事件。並且領域實體的狀態儲存為這些領域事件的序列集合。換句話說，只要插入新記錄或在現有記錄上更新某些內容，就會建立一個新事件。事件儲存庫會跟蹤實體上發生的所有事件。

現在，讓我們假設特定帳戶發生以下交易：

• 建立賬戶，初始餘額為100美元。
• 帳戶設定為ACTIVE狀態。
• 一位朋友支付了一些錢用於分享一頓飯。賬戶中存入55美元。
• 你為重要的其他人買了冰淇淋。提款20美元。
• 你的重要人物不喜歡冰淇淋，所以你不得不買另一個。提款50美元。
• 你忘了支付房租。你的房東判處了罰款。提款100美元。
• 由於餘額為負，帳戶設定為HOLD狀態。
• 存入100美元的賬戶。嘆了一口氣。
• 帳戶設定為ACTIVE狀態。

以下是如何以事件溯源方式儲存：

每當存在對領域物件的當前狀態的請求時，重放事件並構造狀態。

事件源實現可以使用標準Java框架（如Spring Boot和Axon）的組合來完成。

CQRS 

CQRS代表Command-Query Responsibility Segregation。通常，CQRS與事件採購一起實施。

CQRS的主要用途是解決API組合產生的問題。

在典型的事件採購和CQRS設定中，CQRS應用程式偵聽來自多個應用程式的域事件。使用這些事件更新和維護專門用於查詢的資料庫。根據業務案例，查詢資料庫可以聚合複雜查詢。

Saga模式

Saga Pattern是在微服務架構中實現分散式事務的直接解決方案。 

通常，在基於微服務的應用程式中，每個微服務都將擁有自己的資料庫。但是，某些業務流程需要多個微服務之間的通訊。這就是Saga Pattern的用武之地。典型的Saga實現可以看作是一系列本地事務交易，其中每筆交易只佔Saga整體工作的一小部分。換句話說，Saga模式在微服務架構中幾乎是必需的。

讓我們看一個典型的食品配送應用程式流程中的一個簡單示例。

當使用者下訂單時，可能發生的一系列操作是：

• 食品訂購服務建立訂單。 此時，訂單處於PENDING狀態。Saga管理著一系列事件。
• Saga通過餐廳服務與餐廳聯絡。
• 餐廳服務嘗試與所選餐廳下訂單。收到確認後，會發回回復。
• Saga收到回覆。並且，根據回覆，它可以批准訂單或拒絕訂單。
• 然後食品訂單服務改變訂單的狀態。如果訂單獲得批准，它將通知客戶並提供任何必要的詳細資訊。如果被拒絕，它還會通過道歉資訊通知客戶。

Sagas也可以是不同型別的，例如基於有中心的編排或基於無中心的編排。可以使用Spring Boot和Axon框架實現基於編排的Saga。

（banq注：Saga模式是一種流程編排的回退事務，還需要專門的流程框架輔助，如Camunda）