Saga 設計模式是管理分散式交易案例中微服務間數據一致性的方法。 Saga 是一連串的交易，會更新每項服務並發佈訊息或事件，觸發下一個交易步驟。 如果步驟失敗，Saga 會執行補償交易，抵消前述交易。
內容和問題
交易是邏輯或工作的單一單位，有時由多個作業組成。 在交易中， 事件 是實體發生的狀態變更，而 命令 會封裝執行動作或觸發後續事件所需的所有資訊。
交易必須是 不可部分完成、一致、隔離且持久的 （ACID） 。 單一服務內的交易是 ACID，但跨服務數據一致性需要跨服務事務管理策略。
在多重服務架構中：
- 不可部分完成性是一組不可分割且無法辨識的作業，必須全部發生或全部不發生。
- 一致性表示交易只會將數據從一個有效狀態帶入另一個有效狀態。
- 隔離 可確保並行交易會產生與循序執行之交易所產生的相同數據狀態。
- 持久性 可確保即使系統故障或電源中斷，認可的交易仍會持續認可。
每個 微服務 的資料庫模型可為微服務架構提供許多優點。 封裝網域數據可讓每個服務使用其最佳數據存放區類型和架構、視需要調整自己的數據存放區，以及與其他服務的失敗隔離。 不過，確保服務特定資料庫之間的數據一致性會帶來挑戰。
分散式交易，例如 兩階段認可 （2PC） 通訊協定，需要交易中的所有參與者認可或回復，才能繼續交易。 不過，某些參與者實作，例如 NoSQL 資料庫和訊息代理，不支援此模型。
另一個分散式交易限制是 進程間通訊 （IPC） 同步和可用性。 操作系統提供的 IPC 允許個別進程共享數據。 若要讓分散式交易認可，所有參與的服務都必須可供使用，可能會降低整體系統可用性。 具有 IPC 或交易限制的架構實作是 Saga 模式的候選專案。
解決方案
Saga 模式會使用一連串的 本機交易來提供交易管理。 本機交易是由傳奇參與者執行的不可部分完成工作。 每個本機交易都會更新資料庫，併發佈訊息或事件，以觸發傳奇中的下一個本機交易。 如果本機交易失敗，Saga 會執行一系列 補償交易 ，以復原先前本機交易所做的變更。
在 Saga 模式中：
- 可補償的交易 是可能透過處理另一個具有相反效果的交易來反轉的交易。
- 樞紐交易是傳奇中的 go/no-go 點。 如果樞紐交易認可，則 saga 會執行到完成為止。 樞紐交易可以是無法補償或可重試的交易，或者它可以是最後一個可補償交易或傳奇中的第一個可重試交易。
- 可重試的交易 是遵循樞紐交易的交易，並保證成功。
有兩種常見的傳奇實作方法： 編舞 和協調 流程。 每個方法都有自己的一組挑戰和技術來協調工作流程。
編排
編舞是協調傳奇的方式，參與者在沒有集中式控制點的情況下交換事件。 透過編舞，每個本機交易都會發佈網域事件，以在其他服務中觸發本機交易。
福利
- 適用於需要少數參與者且不需要協調邏輯的簡單工作流程。
- 不需要額外的服務實作和維護。
- 不會引入單一失敗點，因為責任會分散到傳奇參與者。
缺點
- 當新增步驟時，工作流程可能會變得混淆，因為很難追蹤哪些傳奇參與者會接聽哪些命令。
- 傳奇參與者之間有迴圈相依性的風險，因為它們必須取用彼此的命令。
- 整合測試很困難，因為所有服務都必須執行以模擬交易。
協調流程
協調流程是協調傳奇的方法，其中集中式控制器會告訴傳奇參與者要執行的本機交易。 Saga 協調器會處理所有交易，並告知參與者根據事件執行哪些作業。 協調器會執行傳奇要求、儲存及解譯每個工作的狀態，並使用補償交易處理失敗復原。
福利
- 適用於涉及許多參與者或隨著時間新增的新參與者的複雜工作流程。
- 適合在程式中控制每個參與者，以及控制活動的流程時。
- 不會引入週期相依性，因為協調器單方面相依於傳奇參與者。
- Saga 參與者不需要知道其他參與者的命令。 清楚區分考慮可簡化商業規則。
缺點
- 額外的設計複雜度需要協調邏輯的實作。
- 有額外的失敗點，因為協調器會管理完整的工作流程。
問題和考量
實作 Saga 模式時，請考慮下列幾點：
- Saga 模式一開始可能具有挑戰性，因為它需要一種新的方式來思考如何協調交易，並維護跨越多個微服務的商務程序的數據一致性。
- Saga 模式特別難以偵錯，隨著參與者的增加，複雜度也會增加。
- 無法回復數據，因為傳奇參與者會將變更認可到其本機資料庫。
- 實作必須能夠處理一組潛在的暫時性失敗，並提供 等冪 來減少副作用並確保數據一致性。 等冪表示相同的作業可以重複多次，而不會變更初始結果。 如需詳細資訊，請參閱 在一起處理訊息和更新狀態時確保等冪的指引。
- 最好實作監視和追蹤傳奇工作流程的可觀察性。
- 缺乏參與者數據隔離會帶來持久性挑戰。 傳奇實作必須包含可減少異常的對策。
- 補償交易不一定能夠運作。
如果沒有適當的量值，可能會發生下列異常狀況：
- 遺失的更新，當一個傳奇寫入而不讀取另一個傳奇所做的變更時。
- 擷取，當交易或傳奇讀取尚未完成這些更新的傳奇故事所做的更新時。
- 當不同的傳奇步驟讀取不同的數據時，模糊/不可重複的讀取，因為讀取之間會發生數據更新。
減少或防止異常的建議對策包括：
- 語意鎖定，應用層級鎖定，其中saga的可補償交易會使用旗號來指出更新正在進行中。
- 可依任何順序執行的通勤更新 ，併產生相同的結果。
- 悲觀檢視： 一個傳奇可以讀取臟數據，而另一個傳奇正在執行可補償的交易來復原作業。 悲觀檢視會重新排序傳奇，讓可重試的交易中基礎數據更新，從而消除讀取錯誤的可能性。
- 重新讀取值 會確認數據未變更，然後更新記錄。 如果記錄已變更，步驟會中止，而傳奇可能會重新啟動。
- 版本檔案會在記錄送達時記錄作業，然後依正確順序執行作業。
- 依值 會使用每個要求的商務風險來動態選取並行機制。 低風險要求偏愛傳奇，而高風險要求則偏向分散式交易。
使用此模式的時機
當您需要下列專案時，請使用 Saga 模式：
- 確保分散式系統中的數據一致性，而不需要緊密結合。
- 復原或補償序列中的其中一個作業失敗。
Saga 模式不適合：
- 緊密結合的交易。
- 補償先前參與者中發生的交易。
- 迴圈相依性。
範例
以協調流程為基礎的無 伺服器 Saga 是使用協調流程方法的傳奇實作參考，可模擬成功且失敗工作流程的資金轉移案例。
下一步
- 分散式資料
- 理查森，克裡斯 2018： 微服務模式。 曼寧出版物。
相關資源
實作此模式時，下列模式可能也很有用：
- 編舞 讓系統的每個元件都參與商務交易工作流程的決策程式，而不是依賴中央控制點。
- 補償一系列步驟所執行的交易 復原工作，並在一或多個步驟失敗時定義一致的作業。 實作複雜商務程式和工作流程的雲端裝載應用程式通常會遵循此 最終一致性模型。
- 重試 可讓應用程式在嘗試連線到服務或網路資源時處理暫時性失敗，方法是以透明方式重試失敗的作業。 重試可以改善應用程式的穩定性。
- 斷路器會處理在連線到遠端服務或資源時，需要一段時間才能復原的錯誤。 斷路器可以改善應用程式的穩定性和復原能力。
- 健康情況端點監視 會在應用程式中實作功能檢查，外部工具可以定期透過公開的端點存取。 健康情況端點監視可協助驗證應用程式和服務是否正常執行。