在網易雲輕舟微服務平台中，我們的微服務框架除了完成一些基本事項（比如熔斷、限流、降級、彈性伸縮等），也開發了很多符合行業特性的定製化產品。這是因為我們發現傳統行業與互聯網行業的經營模式有著很大的不同，不同客戶的關注點並不一樣，架構師想要用一個產品把以上項目全部覆蓋還是比較困難的。但是，我們可以根據客戶的需求點加以設計。

以下的實踐，來自輕舟微服務平台的某大型銀行客戶。這個銀行客戶需要微服務架構是因為他們在服務拆完後，分散式事務出現了問題。

分散式事務其實有幾種方式解決。其中的一種就是在分散式資料庫 DDB 中提交分布事務 XA。如果跨多個 DDB 中間件保證事務性，就需要使用 TCC 模型。我們的中間件 DTS 可以做這件事。同時，我們有個 TMC 中間件，含有非同步消息模型（可以用事務消息的方式來完成）。這裡我舉兩個場景來說明問題。

場景一：下單即減優惠券、減庫存

下單是事務的發起方，優惠券和庫存是事務的參與方，分支事務需要用事務 ID 做冪等，幾方調用都需要同時並行。一旦程序出現錯誤，就會有一些定時任務去重試和回滾。如果分支事務不在，這時候會有一個超時機制，在某一個時間之內，無論是判斷成功和判斷失敗都不做響應。但是在一個設定的時間之外，如果它還沒給出應答，最後就會判斷失敗。這就是一個 TCC 的場景，TCC 適用於立即應答的場景，就像下單是沒有「下單中」這個概念的，下單只有「成功」與「失敗」，並且立刻反饋給商家。

場景二：交易消息非同步

比如，在轉賬的時候，會有一個狀態叫「轉帳中」，一旦有中間狀態，就不是一個完全同步的事務，可能需要 5 分鐘的延遲。這種消息需要通過一定的機制，保證它能夠到達對方，如果不能到達就需要重試。這種方式被稱為事務消息隊列。

相關鏈接：

• 微服務化有3個階段，但大部分金融企業仍處在0.5
• 網易雲馮常健：節省超千萬成本，輕舟微服務是如何做到的？
• 成功的微服務，需要企業組織架構如何變革？
• 網易雲輕舟微服務之API網關實踐
• 網易雲輕舟微服務框架：核心組件解析
• 網易雲輕舟微服務框架：設計理念與技術選型全解析
• 網易雲輕舟微服務監控：基於Prometheus的實踐與踩過的坑
• 網易雲輕舟微服務框架：不僅僅是整合Spring Cloud
• 網易雲輕舟微服務框架：服務治理無侵入的設計
• 支撐德邦快遞日進億元的微服務平台是如何設計的

推薦閱讀：