參考資料

Saga 流程
  1. Saga 由系統命令啟動
  2. 協調邏輯選擇並告訴第一個 Saga 參與者執行本地交易
  3. 完成後，Saga 的排序協調選擇並呼叫下一個 Saga 參與者
  4. 持續到所有步驟都執行完畢
  5. 如果任何本地交易失敗，Saga 必須以相反順序執行補償交易。

建構 Saga 協調邏輯的方式
  • Choreography — 將決策和排序分散在 Saga 參與者之間。主要透過交換 event 來溝通。
  • Orchestration — 將協調邏輯集中在一個 Saga Orchestration class 中。Saga orchestrator 發送 command 給 Saga 參與者，告訴他們要執行哪個操作。

基於 Choreography 的 Saga
  • Saga 參與者訂閱彼此的 event 並相應地回應

用 CHOREOGRAPHY 實作 CREATE ORDER SAGA
每個參與者更新自己的資料庫並發佈 event 來觸發下一個參與者



可靠的基於 EVENT 的通訊
實作基於 choreography 的 saga 時需要考慮以下事項：
  1. 確保 saga 參與者更新資料庫和發佈 event 是作為資料庫交易的一部分 => 原子性。
    為了可靠地通訊，saga 參與者必須使用交易式 messaging。
  2. Saga 參與者必須能夠將收到的每個 event 對應到自己的資料。
    => 當 Order Service 收到一個 event 時，必須能找到對應的 Order。
    => 解決方案：發佈包含 correlation id 的 event，讓其他參與者能做對應。
    => 例如 Order Id

基於 CHOREOGRAPHY 的 SAGA 優缺點
  • 優點
    • 簡單：服務只需發佈自己的 event
    • 鬆耦合：每個服務透過 event 溝通，不需要直接知道彼此
  • 缺點
    • 難以理解：不像 orchestration，沒有一個集中的地方定義 Saga。開發者很難理解 Saga 是怎麼運作的。
    • 服務之間的循環依賴
    • 有緊耦合的風險
  • 因為這些缺點，比較複雜的 Saga 會使用 orchestration。


基於 Orchestration 的 Saga
  1. orchestrator class 的唯一職責是告訴 saga 參與者該做什麼
  2. orchestrator 使用 command/async reply 風格的互動與參與者溝通
  3. 它發送 command message 給參與者，告訴它要執行什麼操作。
  4. saga 參與者執行完操作後，發送 reply message 給 orchestrator
  5. orchestrator 接著處理訊息並決定下一步要執行哪個 saga 步驟

將 SAGA ORCHESTRATOR 建模為 STATE MACHINE
  • 把 saga orchestrator 建模成 state machine 是個好方法

基於 ORCHESTRATION 的 SAGA 優缺點

  • 更簡單的依賴關係
  • 更少的耦合
  • 改善關注點分離並簡化商業邏輯

缺點
有把太多商業邏輯集中在 orchestrator 的風險



You May Also Enjoy