參考資料

挑戰
在單體系統中，createOrder 操作只需要依賴帶有 transactional annotation 的關聯式資料庫。
在 microservice 系統中，createOrder 操作需要確保 Kitchen Service、Customer Service、Order Service、Accounting Service 中的操作全部成功。因為每個服務都有自己的資料庫。

傳統做法
簡單來說：兩階段提交。例如 Java EE 可以透過 JTA 完成多個服務的交易。

問題
  1. 現代技術如 No-SQL 資料庫或 Message broker（如 Kafka）不支援它。
  2. 傳統做法是同步操作且可用性較低（所有服務必須都可用）
    兩個 99.5% 可用性的服務，整體可用性變成 99%

使用 Saga Pattern 維護資料一致性
Saga：透過一連串用非同步 messaging 協調的本地交易來維護跨服務的資料一致性。參見 http://microservices.io/ patterns/data/saga.html。
每個本地交易在單一服務內使用我們熟悉的 ACID 交易框架和函式庫來更新資料

  1. 系統操作啟動 Saga 的第一步
  2. 本地交易完成後觸發下一個本地交易的執行
  3. Saga 必須使用補償交易來回滾

範例：Create Order Saga
  1. 由外部的 createOrder 請求啟動
  2. 其他五個交易在前一個完成後觸發

挑戰
  1. Saga 之間缺乏隔離性
  2. 發生錯誤時的回滾

SAGA 使用補償交易來回滾變更
當某一步失敗時，先前的 saga 需要復原變更（必須被復原）







You May Also Enjoy