深刻理解Spring Cloud與微服務構建【一】 - 1.3 微服務的不足

主要體如今以下方面。

1. 微服務的複雜度（框架知識、服務於服務通訊、服務與服務之間相互依賴）。
2. 分佈式事務（重點）。
3. 服務的劃分（業務場景劃分邊界，最好無耦合，都能單獨運行和替換）。
4. 服務的部署（可選用Docker、DevOps）。

單獨說下分佈式事務，其他就很少作解釋

1.3.1 分佈式事物

• 微服務架構所設計的系統是分佈式系統。分佈式系統有一個著名的 CAP 理論，即同時知足「一致性」「可用性」和「分區容錯」是一件不可能的事。
• Consistency：指數據的強一致性。若是寫入某個數據成功，以後讀取，讀到的都是新寫入的數據：若是寫入失敗，以後讀取的都不是寫入失敗的數據。
• Availability：指服務的可用性。
• Partition-tolerance：指分區容錯。

• 在分佈式系統中，P 是基本要求，而單體服務是 CA 系統。 微服務系統一般是一個 AP系統，即同時知足了可用性和分區容錯。這就有了一個難題：在分佈式系統中如何保證數據的一致性？這就是大 家常常討論的分佈式事務。
• 在微服務系統中，每一個服務都是獨立的進程單元， 每一個服務都有本身的數據庫。 一般狀況下，只有關係型數據庫在特定的數據引擎下才支持事務，而大多數非關 系型數據庫是不支持事務的，例如 MongDB 是不支持事 務的，而 Redis是支持事務的。 在微服務架構中，分佈 式事務一直都是一個難以解決的問題，業界給出的解決 辦法一般是兩階段提交。

網上購物在平常生活中是一個很是普通的場最，假設我在淘寶上購買了一部手機，須要從個人帳戶中扣除 1000 元錢，同時手機的庫存數量須要減 1。固然須要在賣方的帳戶中加 1000 元錢，爲了使案例簡單化，暫時不用考慮。
若是這是一個單體應用，而且使用支持事務的 MySQL 數據庫 ClnnoDB 數據庫引擎才支 持事務），咱們可能這樣寫代碼：

@Transactional  
public void update () throws RuntimeException( 
    updateAccountTable (); 11更新帳戶表 
    updateGoodsTable (); 11更新商品表 
}

若是是微服務架構，帳戶是一個服務，而商品是一個服務，這時不能用數據庫自帶的事務，由於這兩個數據表不在一個數據庫中。所以經常用到兩階段提交，兩階段提交的過程

• 第一階段， service-account 發起一個分佈式事務，交給事務協調器 TC 處理，事務協調器 TC 向全部參與的事務的節點發送處理事務操做的準備操做。 全部的參與節點執行準備操做， 將 Undo 和 Redo 信息寫進日誌，並向事務管理器返回準備操做是否成功。
• 第二階段，事務管理器收集全部節點的準備操做是否成功，若是都成功，則通知全部的節 點執行提交操做；若是有一個失敗，則執行回滾操做。

兩階段提交，將事務分紅兩部分可以大大提升分佈式事務成功的機率。若是在第一階段都 成功了，而執行第二階段的某一個節點失敗，仍然致使數據的不許確，這時通常須要人工去處 理，這就是當初在第一步記錄日誌的緣由。另外，若是分佈式事務涉及的節點不少，某一個節 點的網絡出現異常會致使整個事務處於阻塞狀態，大大下降數據庫的性能。因此通常狀況下， 儘可能少用分佈式事務。