1. 雜談
由於目前公司專案是單體架構，服務之間耦合嚴重，釋出個活動都需要釋出主應用，對線上服務的穩定性造成了一定影響，最近公司就開始做微服務化的拆分，而且又不能停止現有功能的迭代開發，所以就一邊開發新功能，一邊拆分服務。
2. 問題
小公司果然在實現微服務的道路上步步維艱，雖然微服務現在如火如荼，但行業上對其實踐其實仍處於探索階段，基礎設施不夠完善。
主要問題包括：
- 單體應用拆分為分散式系統後，程式間的通訊機制和故障處理措施變的更加複雜（dubbo，spirng cloud能框架基本已經解決）。
- 系統微服務化後，一個看似簡單的功能，內部可能需要呼叫多個服務並操作多個資料庫實現，服務呼叫的分散式事務問題變的非常突出。
- 微服務數量眾多，其測試、部署、監控等都變的更加困難（docker，devops基本已經解決）。
3. 傳統方案
目前解決分散式事務比較常見的方案是XA，TCC和訊息。但它們都各有缺點。
- XA：兩階段提交方案鎖定資源時間長，對效能影響很大，基本不適合解決微服務事務問題。
- TCC:業務邏輯的每個分支都需要實現try、confirm、cancel三個操作，應用侵入性較強，改造成本高。需要按照網路狀態、系統故障等不同的失敗原因實現不同的回滾策略。為了滿足一致性的要求，confirm和cancel介面必須實現冪等。
- 訊息：訊息方案從本質上講是將分散式事務轉換為兩個本地事務，然後依靠下游業務的重試機制達到最終一致性。基於訊息的最終一致性方案對應用侵入性也很高，應用需要進行大量業務改造，成本較高（但相對XA和TCC改動最小）。
就傳統的分散式事務解決方案來分析，訊息的方案應該是最適合微服務的，鎖定時間最小，最終一致性的實現對於網際網路應用來說一般都是能接受的。但有沒有更優雅的方案呢，如果你的服務剛好是部署在阿里雲上的，那麼恭喜你了，可以在改動最小的情況下，接入GTS，那麼GTS是什麼呢？
4. GTS--分散式事務解決方案
GTS是一款分散式事務中介軟體，由阿里巴巴中介軟體部門研發，可以為微服務架構中的分散式事務提供一站式解決方案。相對於傳統分散式事務解決方案，GTS有如下優勢（微服務架構下分散式事務解決方案 —— 阿里GTS）（這些特性其實是每個設計中介軟體的開發人員都需要考慮和兼顧的方面）：
- 效能超強
GTS解決了事務ACID特性與高效能、高可用、低侵入不可兼得的問題。單事務分支的平均響應時間在2ms左右，3臺伺服器組成的叢集可以支撐3萬TPS以上的分散式事務請求。
- 應用侵入性極低
GTS對業務低侵入，業務程式碼最少只需要新增一行註解（@TxcTransaction）宣告事務即可。業務與事務分離，將微服務從事務中解放出來，微服務關注於業務本身，不再需要考慮反向介面、冪等、回滾策略等複雜問題，極大降低了微服務開發的難度與工作量。
- 完整解決方案
GTS支援多種主流的服務框架，包括EDAS，Dubbo，Spring Cloud等。
有些情況下，應用需要呼叫第三方系統的介面，而第三方系統沒有接入GTS。此時需要用到GTS的MT模式。GTS的MT模式可以等價於TCC模式，使用者可以根據自身業務需求自定義每個事務階段的具體行為。MT模式提供了更多的靈活性，可能性，以達到特殊場景下的自定義優化及特殊功能的實現。
- 容錯能力強
GTS解決了XA事務協調器單點問題，實現真正的高可用，可以保證各種異常情況下的嚴格資料一致。
對於GTS的介紹就到這裡，下一篇將講GTS的使用方式。