一、 傳統的分佈式事務和微服務架構分佈式事務比較，分析
傳統應用使用本地事務和分佈式事務保證數據一致性，但是在微服務架構中數據都是服務私有的，需要通過服務提供的API來訪問，所以分佈式事務不再適用微服務架構。那麼微服務架構又該如何保證數據一致性呢？本文就來談談這個話題。
1. 傳統分佈式事務
傳統使用本地事務和分佈式事務保證一致性
傳統單機應用一般都會使用一個關係型數據庫， 好處是應用可以使用ACID。爲保證一致性我們只需要：開始一個事務，改變（插入，刪除，更新）很多行，然後提交事務（如果有異常時回滾事務）。更進一步，藉助開發平臺中的數據訪問技術和框架（如 Spring），我們需要做的事情更少， 只需要關注數據本身的改變。
隨着組織規模不斷擴大，業務量不斷增長，單機應用和數據庫已經不足以支持龐大的業務量和數據量，這個時候需要對應用和數據庫進行拆分，這就出現了一個應用需要同時訪問兩個或兩個以上的數據庫情況。開始我們用分佈式事務來保證一致性，也就是我們常說的兩階段提交協議（2PC）。
- 分佈式事務解決方案的利弊
優點：嚴格的ACID
缺點：效率非常低（微服務架構下已不太適用）
1.全局事務方式下，全局事務管理器（TM）通過XA接口使用二階段提交協議（ 2PC ）與資源層（如數據庫）進行交互。使用全局事務，數據被Lock的時間跨整個事務，直到全局事務結束。
2.2PC 是反可伸縮模式，在事務處理過程中，參與者需要一直持有資源直到整個分佈式事務結束。這樣，當業務規模越來越大的情況下，2PC 的侷限性就越來越明顯，系統可伸縮性會變得很差。
3. 與本地事務相比，XA 協議的系統開銷相當大，因而應當慎重考慮是否確實需要分佈式事務。而且只有支持 XA 協議的資源才能參與分佈式事務。
本地事務和分佈式事務現在已經非常成熟，相關介紹很豐富，此處不再討論。我們下面來談談爲什麼分佈式事務不適用於微服務架構。
2. 微服務架構事務
1. 首先，對於微服務架構來說，數據訪問變得更加複雜，這是因爲數據都是微服務私有的，唯一可訪問的方式就是通過 API。這種打包數據訪問方式使得微服務之間鬆耦合，並且彼此之間獨立，更容易進行性能擴展。
其次，不同的微服務經常使用不同的數據庫。應用會產生各種不同類型的數據，關係型數據庫並不一定是最佳選擇。
例如，某個產生和查詢字符串的應用採用 Elasticsearch 的字符搜索引擎；某個產生社交圖片數據的應用可以採用圖數據庫，例如Neo4j。
基於微服務的應用一般都使用 SQL 和 NoSQL 結合的模式。但是這些非關係型數據大多數並不支持 2PC。
可見在微服務架構中已經不能選擇分佈式事務了。那麼，微服務架構事務怎麼處理呢？ 衆所周知，事務處理方案基於CAP理論。
3. 最終一致性原則
依據 CAP 理論，必須在可用性（availability）和一致性（consistency）之間做出選擇。如果選擇提供一致性需要付出在滿足一致性之前阻塞其他併發訪問的代價。這可能持續一個不確定的時間，尤其是在系統已經表現出高延遲時或者網絡故障導致失去連接時。所以，在服務和數據庫之間維護數據一致性是非常根本的需求，微服務架構中應選擇滿足最終一致性。