dubbo泛化調用細節是如何實現的？

服務A與服務B屬于不同的應用，通過dubbo遠程調用，要做到二者寫庫操作一同提交/一同回滾，服務A和服務B必須參與同一個跨應用的全局事務，并保證二者對應的DB事務必須作為該全局事務的分支事務。這樣，事務管理模塊在明確了該全局事務的完成方向（commit/rollback）后，再將該全局事務下的所有分支事務逐個提交/回滾。

這是分布式事務管理的大致邏輯，其中，上述“將所有分支事務逐個提交/回滾”過程是分布式事務處理的關鍵，需要有相應故障恢復的機制，例如，當服務A的DB事務已經提交（服務B的DB事務尚未提交）時，若服務B所在節點宕機（或其使用的DB宕機）時，如何保證服務B的DB事務仍能正常提交。這個過程的實現機制有很多種，常見的有XA 2PC和TCC。

XA機制將提交過程分成prepare、commit兩個階段，事務管理模塊在prepare服務A的DB事務、服務B的DB事務都成功后，再逐個commit這些DB事務。DB在prepare返回OK后，如果沒有收到來自事務管理模塊的commit/rollback請求則會一直保留該分支事務的數據。因此，若上述宕機故障出現在prepare階段，則可以通過將prepare過的分支事務回滾，來達到全局事務回滾；若上述宕機故障出現在commit階段，后續仍然可以再次commit那些未成功commit的分支事務，最終達到全局事務提交。

TCC機制下，事務管理模塊是在服務A、服務B執行完畢后即刻提交其參與的DB事務。而后，如果全局事務決定提交，則逐個調用服務A和服務B的confirm邏輯；如果全局事務決定回滾，則逐個調用服務A和服務B的cancel邏輯（當然，confirm/cancel邏輯的執行中又會參與相應的DB事務）。若發生上述宕機故障，則只需要根據全局事務當前狀態，將服務A、服務B相應的confirm/cancel邏輯重新調用即可。因confirm/cancel邏輯可能會被多次調用，因此，需要保證其冪等性。

知名的分布式事務管理器主要有atomikos、bitronix、narayana。其中，僅atomikos支持XA和TCC兩種機制，bitronix、narayana僅支持XA機制。這三者都不提供對dubbo的開箱即用的支持，需要自行集成。

目前對dubbo提供開箱即用支持的分布式事務管理器有：ByteJTA（基于XA機制）、ByteTCC（基于TCC機制）。