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