摘抄並學習
1. 微服務的發展
微服務倡導將復雜的單體應用拆分成若干個功能簡單、松耦合的服務，這樣可以降低開發難度、增強擴展性。便於敏捷開發。當前微服務的開發框架非常多，比較著名的有 Dubbo、SpringCloud、thrift、grpc 等。
2. 微服務落地存在的問題
雖然現在微服務如火如荼，但對其實踐仍處於探索階段。很多中小型互聯網公司鑒於經驗技術實力等問題，微服務落地比較困難。主要有以下幾個方面：
1）單體應用拆分為分布式系統后，進程間的通訊機制和故障處理措施變得更加復雜。
2）系統微服務化后，一個看似簡單的功能，內部可能需要調用多個服務並操作多個數據庫實現，服務調用的分布式事務問題非常突出。
3）微服務數量眾多，其測試、部署、監控等都變得更加困難
隨着 RPC（遠程過程調用 Remote Procedure Call） 框架的成熟，第一個問題已經逐漸得到解決。例如 dubbo 可以支持多種通訊協議，springcloud 可以非常好的支持 restful 調用。對於第二個問題，現在還沒有通用方案很好的解決微服務產生的事務問題。分布式事務已經成為微服務落地最大的阻礙，也是最具挑戰性的一個技術難題。
以下介紹分布式事務的各種解決方案，重點解讀阿里巴巴提出的分布式事務解決方案 —— GTS。
3. SOA分布式事務解決方案
3.1 基於 XA 協議的兩階段提交方案
交易中間件與數據庫通過 XA 接口規范，使用兩階段提交來完成一個全局事務，XA 規范的基礎是兩階段提交協議。
第一階段是表決階段，所有參與者都將本事務能否成功的信息返回給協調者；第二階段是執行階段，協調者根據所有參與者的反饋，通知所有參與者，步調一致地在所有分支上提價或者回滾。
兩階段提交方案應用非常廣泛，幾乎所有商業 OLTP 數據庫都支持 XA 協議。但是兩階段提交方案鎖定資源時間長，對性能影響很大，基本不適合解決微服務事務問題。
3.2 TCC 方案
TCC 方案在電商、金融領域落地較多，TCC 方案其實是兩階段提交的一種改進。其將整個業務邏輯的每個分支顯式的分成了 Try、Confirm、Cancel 三個操作。Try 部分完成業務的准備工作，cinfirm 部分完成業務的提交，cancel 部分完成事務的回滾。基本原理如下
事務開始時，業務應用會向事務協調器注冊啟動事務。之后業務應用會調用所有服務的 Try 接口，完成一階段准備，之后事務協調器會根據 Try 接口返回情況，決定調用 confirm 接口或者 cancel 接口。如果接口調用失敗會進行重試。
TCC 方案讓應用自己定義數據庫操作的粒度，使得降低鎖沖突、提高吞吐量稱為可能，當然 TCC 方案也有不足之處，集中表現在以下兩個方面：
- 對應用的侵入性強。業務邏輯的每個分支都需要實現 try、confirm、cancel 三個操作，應用侵入性較強，改造成本高。
- 實現難度大。需要按照網絡狀態、系統故障等不同的失敗原因實現不同的回滾策略。為了滿足一致性的要求，confirm 和 cancel 接口必須實現冪等（針對一個操作，不管做多少次，產生效果或返回的結果都是一樣的）。
上述原因導致 TCC 方案大多被研發實力較強，有迫切需求的大公司所采用。微服務倡導服務的輕量化、易部署，而 TCC 方案中很多事物的處理邏輯需要應用自己的編碼實現，復雜且開發了大。
3.3 基於消息的最終一致性方案
消息一致性方案是通過消息中間件保證上、下游應用數據操作的一致性。基本思路是將本地操作和發送消息放在一個事務中，保證本地操作和消息發送要么兩者都成功或者都失敗。下游應用向消息系統訂閱該消息，收到消息后執行相應操作。
消息方案從本質上是將分布式事務轉換成兩個本地事務，然后依靠下游業務的重試機制達到最終一致性。基於消息的最終一致性方案對應用侵入性也很高，應用需要進行大量業務改造，成本較高。
4 GTS -- 分布式事務解決方案
4.1 GTS的核心優勢
- 性能超強：GTS通過大量創新，解決了事務ACID 特性與高性能、高可用、低侵入 不可兼得的問題。單事務分支的平均響應時間在 2ms 左右，3台服務器組成的集群可以支撐3萬TPS以上的分布式事務請求。
- 應用侵入性低：GTS對業務低侵入，業務代碼最少只需添加一行注解（@TxcTransaction）聲明事務即可。業務與事務分離，將微服務從事務中解放出來，微服務關注於業務本身，不再需要考慮反向接口、冪等、回滾策略等復雜問題，極大降低了微服務開發的難度與工作量。
- 完整解決方案：GTS支持多種主流的服務框架，包括 EDAS、Dubbo、SpringCloud 等。有些情況下，應用需要調用第三方系統的接口，而第三方系統沒有接入 GTS。此時需要用到 GTS 的 MT 模式。GTS 的 MT 模式可以等價於 TCC 模式，用戶可以根據自身業務需求自定義每個事物階段的具體行為。MT 模式提供了更多的靈活性、可能性，以達到特殊場景下的自定義優化及特殊功能的實現。
- 容錯能力強：GTS 解決了 XA 事務協調器單點問題，實現真正的高可用，可用保證各種異常情況下的嚴格數據一致。
4.2 GTS 與微服務的集成
GTS 包括客戶端（GTS Client），資源管理器（GTS RM）和事務協調器（GTS Server）三個部分。GTS Client 主要用來界定事務邊界，完成事務的發起與結束。GTS RM 完成事務分支的創建、提交、回滾等操作。GTS Server 主要負責分布式事務的整體推進，事務生命周期的管理。GTS 和微服務集成的結構圖如下所示，GTS Client 需要和業務應用集成部署，RM 與微服務集成部署。
4.3 GTS的輸出
GTS 目前有三種輸出形式：公有雲輸出、公網輸出、專有雲輸出
4.3.1 公有雲輸出
這種輸出形式面向阿里雲用戶。如果用戶的業務系統已經部署到阿里雲上，可以申請開通公有雲 GTS。開通后業務應用即可以通過 GTS 保證服務調用的一致性。這種使用場景下，業務系統和 GTS 間的網絡環境比較理想，達到很好的性能。
4.3.2 公網輸出
這種輸出形式面向於非阿里雲用戶，使用更加方便、靈活，業務系統只要能連接互聯網即可享受 GTS 提供的雲服務（與公有雲輸出的差別在於客戶端部署在用戶本地，而不在雲上）
4.3.3 專有雲輸出
這種形式主要面向於已建設了自己專有雲平台的大用戶，GTS 可以直接部署到用戶的專有雲上，為專有雲提供分布式事務服務。目前已經有10多個特大型企業的專有雲使用 GTS 解決分布式事務難題，性能與穩定性經過了用戶的嚴格檢測。
摘抄自：https://www.cnblogs.com/jiangyu666/p/8522547.html