前言
設計一個分佈式事務框架前，首先要明確問題到定義。分析具體應用場景，包括以下三個：A、服務內跨數據庫的事務；B、跨內部服務的事務；C、跨外部服務的事務。其中劃分內部和外部的標準是：內部服務我們可以控制其實現，修改配置或代碼；外部服務指的是第三方的，只能約定通信的方式和具體協議，具體代碼實現在控制範圍之外。
一、應用場景A：服務內跨數據庫
如下圖所示，在同一個服務方法內，訪問兩個或兩個以上數據庫。我們知道，Java事務是通過Connection對象控制的。不同的數據庫，是不同的數據庫鏈接，通過不同的Connection對象實現。傳統數據庫事務無法實現事務控制，需要引入事務協調者的概念。這是場景A，這個場景中分佈式體現在數據庫的部署上。
二、應用場景B：跨內部服務
如下圖所示，一個服務通過微服務框架或者RPC調用調用其他的服務，多個子服務需要同時成功或失敗。每個子服務都有自己的持久化方式，不一定是數據庫，體現事務的持久性。每個子服務部署在不同的服務容器中，不同的服務容器部署在不同的服務器節點上。這是場景B，這個場景中分佈式體現在服務（或應用）的部署上。這時候，事務的概念已經超出“數據庫”的範疇了。
三、應用場景C：跨外部服務
這個場景是在應用場景B的基礎上，進一步，服務的具體實現在我們控制範圍之外。我們不能限制其實現語言，不能要求指定方法上加標註（註解）。甚至除了服務調用的網絡通道外，我們不能期望服務間訪問相同的Zookeeper作爲事務協調器。這是場景C，這個場景中，我們只能在通信協議層面做約定，是最徹底的分佈式場景。
