Saga 模式 | 如何使用微服務實現業務事務
最強大的事務類型之一稱為兩階段提交，當第一個事務的提交取決于第二個事務的完成時，它是摘要。特別是當您必須同時更新多個實體時，例如確認訂單和立即更新庫存時，它非常有用。
但是，例如，當您使用微服務時，事情變得更加復雜。每個服務都是一個獨立的系統，擁有自己的數據庫，您不再可以利用本地兩階段提交的簡單性來維護整個系統的一致性。
當你失去這種能力時，RDBMS成為一個非常糟糕的存儲選擇，因為你可以完成相同的“單實體原子事務”，但只需使用像Couchbase這樣的NoSQL數據庫就可以快幾十倍。這就是為什么大多數使用微服務的公司也在使用NoSQL。
要舉例說明此問題，請考慮以下電子商務系統的高級微服務架構：
圖片
在上面的示例中，人們不能只在一個ACID交易中下訂單，向客戶收費，更新庫存，并將其發送到交貨。要始終如一地執行此整個流程，您將需要創建分布式事務。
我們都知道實現分布式任務是多么困難，不幸的是，交易也不例外。處理瞬態狀態，服務，隔離和回滾之間的最終一致性是在設計階段應該考慮的場景。
幸運的是，我們已經為它提出了一些好的模式，因為我們已經實施分布式事務已有二十多年了。我今天要談的那個叫做Saga模式。
傳奇(Saga)模式
分布式事務最著名的模式之一稱為Saga。關于它的第一篇論文發表于1987年，從那時起它就成了一種流行的解決方案。
Saga是一系列本地事務，其中每個事務在單個服務中更新數據。第一個事務由對應于系統操作的外部請求啟動，然后每個后續步驟由前一個完成觸發。
使用我們之前的電子商務示例，在一個非常高級的設計中，Saga實現如下所示：
圖片
有幾種不同的方法來實現傳奇交易，但最受歡迎的兩種方式是：
- 事件/Choreography(編舞)：當沒有中央協調時，每個服務產生并監聽其他服務的事件，并決定是否應該采取行動。
- 命令 / Orchestration(編曲)：協調器服務負責集中saga的決策和排序業務邏輯。
讓我們更深入地了解每個實現，以了解它們的工作原理。
事件/編舞
在事件/Choreography(編舞)方法中，第一個服務執行事務然后發布事件。該事件由一個或多個服務監聽，這些服務執行本地事務并發布（或不發布）新事件。
當最后一個服務執行其本地事務并且不發布任何事件時，分布式事務結束，或者任何傳奇(Saga)參與者都不會聽到發布的事件。
讓我們看看它在我們的電子商務示例中的樣子：
圖片
- 訂單服務保存新訂單，將狀態設置為掛起并發布名為ORDER_CREATED_EVENT的事件。
- 付款服務偵聽ORDER_CREATED_EVENT，向客戶收費并發布事件BILLED_ORDER_EVENT。
- Stock Service監聽BILLED_ORDER_EVENT，更新庫存，準備訂單中購買的產品并發布ORDER_PREPARED_EVENT。
- Delivery Service偵聽ORDER_PREPARED_EVENT，然后選擇并交付產品。最后，它發布了ORDER_DELIVERED_EVENT
- 最后，Order Service偵聽ORDER_DELIVERED_EVENT并將訂單狀態設置為已結束。
在上面的情況中，如果需要跟蹤訂單的狀態，訂單服務可以簡單地監聽所有事件并更新其狀態。
分布式事務中的回滾
回滾分布式事務并非免費。通常，您必須實施另一個操作/事務來補償之前已完成的操作。
假設Stock Service在交易期間失敗了。讓我們看看回滾會是什么樣子：
圖片
- 庫存服務生產PRODUCT_OUT_OF_STOCK_EVENT;
- 訂單服務和付款服務都會收聽上一條消息：
- 付款服務退還客戶。
- 訂單服務將訂單狀態設置為失敗。
請注意，為每個事務定義一個公共共享ID至關重要，因此每當您拋出一個事件時，所有偵聽器都可以立即知道它所引用的事務。
Saga 事件/Choreography(編舞)設計的好處和缺點
事件/編排是實現Saga模式的自然方式;它簡單，易于理解，不需要太多的努力來構建，并且所有參與者都是松散耦合的，因為他們沒有彼此的直接知識。如果您的交易涉及2到4個步驟，那么它可能非常合適。
但是，如果您不斷在事務中添加額外的步驟，這種方法很快就會變得混亂，因為很難跟蹤哪些服務監聽哪些事件。此外，它還可能在服務之間添加循環依賴，因為它們必須訂閱彼此的事件。
最后，使用這種設計實現測試會很棘手。為了模擬事務行為，您應該運行所有服務。
