微服務中的Saga模式 - baeldung

每個服務對應一個資料庫
微服務架構的好處之一是，它使我們可以選擇每種服務的技術堆疊。例如，我們可以決定對服務A使用關聯式資料庫，對服務B選擇NoSQL資料庫。
該模型使服務可以在最適合其資料型別和架構的資料儲存上獨立管理域資料。此外，它還允許服務按需擴充套件其資料儲存，並將其與其他服務的故障隔離。
但是，有時事務可以跨多個服務，因此確保跨服務資料庫的資料一致性是一個挑戰（banq注：出現事務跨多個服務，極大可能是微服務本身沒有設計正確，這裡的事務是指那種涉及人工處理的跨時比較長的流程事務）。在下一節中，我們將透過一個示例來研究分散式事務管理的挑戰。
 

分散式事務
為了演示分散式事務的使用，我們將以微服務架構實現的鐵路座位預訂系統為例。有一個微服務可以阻止座位，一個微服務接受付款，另一個微服務分配預訂的座位。這些微服務中的每一個都執行本地事務以實現各個功能：

為了確保成功預訂機票，所有三個微服務都必須完成單獨的本地交易。如果任何微服務未能完成其本地事務，則所有已完成的先前事務都應回滾以確保資料完整性。這是分散式事務的示例，因為事務邊界跨越了多個服務和資料庫。
微服務架構中的分散式事務帶來了兩個關鍵挑戰。
第一個是維護ACID。 為了確保事務的正確性，它必須是原子的，一致的，隔離的和持久的（ACID）。原子性確保事務的所有步驟或不應該完成。一致性將資料從一個有效狀態轉移到另一有效狀態。隔離保證併發事務產生的結果應與順序事務產生的結果相同。最後，永續性意味著無論任何型別的系統故障，已提交的事務都將保持已提交狀態。在分散式事務場景中，由於事務跨多個服務，因此始終要確保ACID仍然是關鍵問題。
第二個是管理事務隔離級別。 它指定當其他服務同時訪問相同資料時在事務中可見的資料量。換句話說，如果一個微服務中的一個物件保留在資料庫中，而另一個請求讀取該資料，則該服務應返回舊資料還是新資料？
 

兩階段提交
兩階段提交協議（2PC）是一種廣泛使用的模式，用於實現分散式事務。我們可以在微服務架構中使用此模式來實現分散式事務。
在兩階段提交協議中，有一個協調器元件，負責控制事務幷包含管理事務的邏輯。另一個元件是執行其本地事務的參與節點（例如，微服務）：

顧名思義，兩階段提交協議分兩個階段執行分散式事務：

1. 準備階段：協調器詢問參與節點是否準備好提交事務。參與者返回的是或否
2. 提交階段：如果所有參與節點在階段1中都做出了肯定的響應，則協調器會要求所有它們都進行提交。如果至少一個節點返回負值，則協調器會要求所有參與者回滾其本地交易

• 事務的責任在協調器節點上，它可能成為單點失敗
• 所有其他服務都需要等待，直到最慢的服務完成其確認。因此，事務的整體效能受最慢的服務約束
• 兩階段提交協議在設計上由於反覆交流確認和依賴於協調器而變慢。因此，它可能會在涉及多個服務的基於微服務的體系結構中導致可伸縮性和效能問題。
• NoSQL資料庫不支援兩階段提交協議。因此，在一個或多個服務使用NoSQL資料庫的微服務體系結構中，不能應用兩階段提交

Saga架構模式
Saga架構模式使用一系列本地事務來提供事務管理。本地交易是由傳奇參與者執行的工作單元。Saga的每個操作都可以透過補償事務回滾。此外，Saga模式可確保所有操作都成功完成，或者執行相應的補償事務以撤消先前完成的工作。
在Saga模式中，補償交易必須是冪等且可重試的。這兩個原則確保了無需任何人工干預就可以管理交易。Saga執行協調員（SEC）確保保證以下原則：

在Saga執行協調器是實現一個Saga流的中心元件。它包含一個Saga日誌，可捕獲分散式事務的事件序列。對於任何失敗，SEC元件都會檢查Saga日誌，以識別受影響的元件以及補償事務應執行的順序。
對於SEC元件中的任何故障，一旦備份，它都可以讀取Saga日誌。然後，它可以識別成功回滾的事務，哪些事務尚未完成，並可以採取適當的操作：

有兩種實現Saga模式的方法：Choreography和Orchestration 。讓我們在下一部分中討論它們。
 

Saga Choreography模式
在Saga Choreography模式中，作為事務一部分的每個微服務都釋出一個事件，該事件由下一個微服務處理。要使用此模式，需要確定微服務是否將成為Saga的一部分。因此，微服務需要使用適當的框架來實現Saga。在這種模式下，Saga執行協調器要麼嵌入在微服務中，要麼可以作為獨立元件。
在Saga中，如果所有微服務都完成了本地事務，並且沒有任何微服務報告失敗，則編排流程將成功。下圖演示了預訂應用程式成功的Saga流程：

如果發生故障，微服務會向SEC報告故障，並且SEC的責任是呼叫相關的補償事務：

在此示例中，“支付”微服務報告失敗，並且SEC呼叫補償交易以解除對座位的限制。如果對補償事務的呼叫失敗，則SEC有責任重試它，直到成功完成為止。回想一下，在Saga中，補償事務必須是冪等且可重試的。
Choreography模式適用於新的微服務應用。同樣，當事務中的參與者較少時，此模式也適用。
以下是一些可用於實現編排模式的框架：

• Axon Saga：一個輕量級框架，廣泛用於基於Spring Boot的微服務
• Eclipse MicroProfile LRA：在Saga中為基於REST原理的HTTP傳輸實現分散式事務
• Eventuate Tram Saga:：基於Spring Boot和Micronaut的微服務的Saga編排框架
• Seata：具有高效能和易於使用的分散式事務服務的開源分散式事務框架

Saga Orchestration模式
在業務流程模式中，一個業務流程負責人管理總體交易狀態。如果任何微服務遇到故障，那麼協調器負責呼叫必要的補償事務：

Saga Orchestration 模式對於舊的微服務應用程式開發體系結構很有用。換句話說，如果我們已經擁有一組微服務並且想要在應用程式中實現Saga模式，則此模式是合適的。我們需要定義適當的補償交易以繼續這種模式。
以下是一些可用於實現編排器模式的框架：

• Camunda：這是一個基於Java的框架，支援用於工作流和流程自動化的業務流程模型和表示法（BPMN）標準。
• Apache Camel：提供Saga企業整合模式（EIP）的實現