saga 在 1987 年由 Hector Garcaa-Molrna Kenneth Salem 兩個人提出，是一種分散式交易架構，可在 micro-services 之間，提供跨service 的交易操作，以保障資料一致性。saga 是用一連串的交易方法，更新每一個服務並發布訊息觸發下一個交易，如果有某一個交易失敗，則進行補償。
saga 主要有 Choreography 及 Orchestration 兩種運作機制。
Choreography
沒有中央協調的角色，由每個服務執行完後主動發出狀態或是呼叫下一個服務。
Saga 模式會使用一連串的本機交易 (local transaction) 實作交易管理。 本機交易是 Saga 參與者所執行的不可部分完成工作工作。每個本機交易都會更新自己的資料庫，同時發布訊息或事件，觸發 saga 中的下一個本機交易。如果本機交易失敗，saga 會執行一系列 補償交易 ，以復原先前本機交易所做的變更。
這個方法的優點是個服務之間的資訊交換方法簡單容易理解，但如果某一個流程中間牽涉的微服務數量太多，就會讓架構變得複雜混亂。因為服務提供者的角色數量增加，導致每個服務都需要一個訊息通道，利用 publish-subscribe 機制，處理訊息交換的問題，但 subcriber 也可能發生意外，導致訊息沒有被處理的例外狀況發生。
Orchestration
有一個交易管理中心，掌管整個商業邏輯，知道如何呼叫微服務，處理整個流程，呼叫下一個服務，並在服務發生問題時，處理補償機制。所有服務都會跟這個中央集權式的交易管理中心溝通。
優點是 Choreography 服務之間的依賴度低，降低複雜度，比較容易處理 rollback，缺點是 Orchestration 實作本身會很複雜。
References
https://medium.com/skyler-record/微服務架的資料一致性-1-saga-pattern-cf05aed1307b
微服務瞎談(7) Saga Pattern - iT 邦幫忙::一起幫忙解決難題，拯救 IT 人的一天
Saga 模式 - Azure Design Patterns | Microsoft Docs
沒有留言:
張貼留言