在網易雲輕舟微服務平台中，我們的微服務框架除了完成一些基本事項（比如熔斷、限流、降級、彈性伸縮等），也開發了很多符合行業特性的定製化產品。這是因為我們發現傳統行業與網際網路行業的經營模式有著很大的不同，不同客戶的關注點並不一樣，架構師想要用乙個產品把以上專案全部覆蓋還是比較困難的。但是，我們可以根據客戶的需求點加以設計。
以下的實踐，來自輕舟微服務平台的某大型銀行客戶。這個銀行客戶需要微服務架構是因為他們在服務拆完後，分布式事務出現了問題。
分布式事務其實有幾種方式解決。其中的一種就是在分布式資料庫 ddb 中提交分布事務
xa。如果跨多個
ddb
中介軟體保證事務性，就需要使用
tcc
模型。我們的中介軟體
dts
可以做這件事。同時，我們有個
tmc
中介軟體，含有非同步訊息模型（可以用事務訊息的方式來完成）。這裡我舉兩個場景來說明問題。
場景一：下單即減優惠券、減庫存
下單是事務的發起方，優惠券和庫存是事務的參與方，分支事務需要用事務 id 做冪等，幾方呼叫都需要同時並行。一旦程式出現錯誤，就會有一些定時任務去重試和回滾。如果分支事務不在，這時候會有乙個超時機制，在某乙個時間之內，無論是判斷成功和判斷失敗都不做響應。但是在乙個設定的時間之外，如果它還沒給出應答，最後就會判斷失敗。這就是乙個
tcc
的場景，
tcc
適用於立即應答的場景，就像下單是沒有「下單中」這個概念的，下單只有「成功」與「失敗」，並且立刻反饋給商家。
場景二：交易訊息非同步
比如，在轉賬的時候，會有乙個狀態叫「轉帳中」，一旦有中間狀態，就不是乙個完全同步的事務，可能需要 5
分鐘的延遲。這種訊息需要通過一定的機制，保證它能夠到達對方，如果不能到達就需要重試。這種方式被稱為事務訊息佇列。
微服務實踐之分布式定時任務
日常任務開放中，我們會有很多非同步 批量 定時 延遲任務要處理，go zero中有go queue，推薦使用go queue去處理，go queue本身也是基於go zero開發的，其本身是有兩種模式 我們主要說一下dq，kq使用也一樣的，只是依賴底層不同，如果沒使用過beanstalkd，沒接觸過...
MQ 分布式事務 微服務應用
以支付 電商下單為例子。乙個電商系統包含了好幾大類模組，就比如有使用者模組 商品模組 庫存模組 訂單模組 支付模組 物流模組，活動模組等，以下就先列舉幾個最基礎常見的模組 使用者模組 商品模組 庫存模組 訂單模組 支付模組 使用者流程如下 如果系統規模較小，資料表都在乙個資料庫例項上，專案服務端也都...
微服務修煉之分布式事務 seata
做過網際網路業務開發的人都知道，在高qps的業務場景中使用分布式事務是乙個大坑，系統吞吐量影響非常大，而且單點故障情況也是不得不考慮的問題。但是在微服務發展越來越猛的今天，我們不得不面臨服務組裝的問題，尤其是對於中臺建設來說，分布式事務是乙個避不開的問題。下面我們來討論一下分布式事務seata官網 ...