你已經使用 database ber service 模式。每個service擁有自己的database。一些業務事務會跨越多個service，所以你需要來確保data consistency。例如，假設你正在構建乙個電子商務**，這個**的使用者的會有乙個最大欠款限制，應用程式必須確保乙個新訂單不能超過使用者的最大前款限制，但是orders表和customers表不在同乙個資料庫，所以應用程式不能簡單的使用本地的acid事務。
怎麼確保跨越多個service的資料一致性
2pc(兩階段提交)不是乙個好的選擇
把跨越多個service的每乙個單獨的事務實現成saga模式。乙個saga是由local transaction組成的序列。每個local transaction更新本地資料庫，然後發布乙個message 或者event來觸發下乙個事務。如果有乙個本地事務失敗了，saga就會執行一系列的補償事務來回滾之前的事務所做的修改。
saga模式有如下兩種協作方式。
choreography(編排)--每個本地事務發布domain event來觸發別的service的local transaction.
orchestration --有乙個orchestrator 物件來告訴參與者執行哪乙個事務。
乙個電子商務**使用choreography-based saga 來建立乙個order。
order service建立乙個處於pending 狀態的order,然後發布乙個 ordercreated event
customer service接受到ordercreated event ，然後為訂單凍結金額。然後customer service 發布乙個creait reserved event 或者creait limit exceeded event(如果賬戶的金額不夠的話)
這是乙個使用orchestration-based saga 模式來建立一張order的例子
order service 建立乙個order，設定order為pending 狀態，然後在建立乙個create order saga物件
create order saga物件傳送乙個reserve credit reserved命令到customer service
customer service嘗試來為這張order 預留金額，然後返回乙個應答
saga模式有如下好處
saga模式的缺點
需要解決的問題
使用saga管理微服務事務
使用saga管理事務 在微服務架構中，單個服務中的事務仍然可以使用acid事務。然而，在對更新多個服務所擁有的資料的操作實現事務時，我們面臨著新的挑戰。跨服務的操作必須使用所謂的saga 一種訊息驅動的本地事務序列 來維護資料一致性，而不是acid事務。saga的乙個挑戰在於只滿足acd 原子性，一...
微服務之如何建模微服務
1.什麼樣的服務是好的微服務？它應該具備這兩個特點 松耦合 高內聚 松耦合 如果做到了服務之間的松耦合，那麼修改乙個服務就不需要修改另外乙個服務了。使用微服務最重要的一點是，能夠獨立修改和部署單個服務而不需要修改系統的其他部分，這一點非常重要。那麼相對的什麼是緊耦合呢？使用緊耦合來做服務之間的整合，...
微服務 服務發現模式
服務發現有三個角色，服務提供者 服務消費者和服務中介。服務中介 聯絡服務提供者和服務消費者的橋梁。服務提供者 將自己提供的服務位址註冊到服務中介。服務消費者 從服務中介那裡查詢自己想要的服務的位址，然後享受這個服務。服務中介提供多個服務，每個服務對應多個服務提供者 服務1 4把當前自己的網路位置註冊...