問題：公司做的項目轉成微服務架構很久了，但是一直沒有實現分佈式事物控制。
在出解決方案的時候想到業界成熟的使用消息隊列實現數據的最終一致性。
但是仔細想想，分佈式事物的介紹
在分佈式系統中一次操作由多個系統協同完成，這種一次事務操作涉及多個系統通過網絡協同完成的過程稱爲分佈式事務。這裏強調的是多個系統通過網絡協同完成一個事務的過程，並不強調多個系統訪問了不同的數據庫，即使 多個系統訪問的是同一個數據庫也是分佈式事務。
這樣想想，以前做的訂單支付算是這種定義下的分佈式事物麼？
之前做的訂單支付功能，調用第三方支付接口。需要做到調用支付成功，我們系統支付成功；調用第三方支付系統失敗，我們系統支付失敗。似乎也可以算作廣義上的分佈式事物。
看看流程圖
1.發起請求同步回調
首先第一步，本地服務訪問第三發接口，並且接收，返回值。
這裏可能出錯情況：
1.發送請求出錯。
2.請求發送後，第三方服務器掛掉沒有返回。
3.接受返回值之後，執行業務流程報錯。
這裏1、3報錯都在一個事物內，可以進行回滾操作。2異常可以將訂單狀態設置成異常狀態、或者超時狀態。
2.超時狀態處理
定時將超時狀態訂單重新調用第三方支付接口，查詢付款狀態，完成訂單狀態更新。
3.異步回調完成訂單付款
這裏可能出先的問題：
1.接受到異步回調之後，服務器出現異常。在事物範圍內可以回滾。並且無法發送返回報文。
2.發送返回報文時提交時異常。
這裏1情況方法出現異常事物回滾之後，訂單還是處於未支付狀態。但是第三方系統因爲未收到完成回調，則會在一段時間後重新回調，完成訂單支付。2情況會導致訂單未支付，並且第三方支付服務器不會再有回調，這時需要定時任務去將長時間未付款訂單查詢付款狀態，或者關閉。
以上便是系統中一個比較完善的付款流程。
那麼在多服務中可以使用簡化操作
思考：
在自己需要兩個服務協同工作時，我們可以新建一個協同任務表。
定時將協同任務像需要調用服務發送請求，以達到數據最終一致。
文中不足還請多多指教。