微服務架構的分佈式事務解決方案

分佈式系統架構中，分佈式事務問題是一個繞不過去的挑戰。而微服務架構的流行，讓分佈式事問題日益突出！

下面咱們以電商購物支付流程中，在各大參與者系統中可能會遇到分佈式事務問題的場景進行詳細的分析！

如上圖所示，假設三大參與平臺（電商平臺、支付平臺、銀行）的系統都作了分佈式系統架構拆分，按上數中的流程步驟進行分析：

一、電商平臺中建立訂單：預留庫存、預扣減積分、鎖定優惠券，此時電商平臺內各服務間會有分佈式事務問題，由於此時已經要跨多個內部服務修改數據；

二、支付平臺中建立支付訂單（選銀行卡支付）：查詢帳戶、查詢限制規則，符合條件的就建立支付訂單並跳轉銀行，此時不會有分佈式事務問題，由於還不會跨服務改數據；

三、銀行平臺中建立交易訂單：查找帳戶、建立交易記錄、判斷帳戶餘額並扣款、增長積分、通知支付平臺，此時也會有分佈式事務問題（若是是服務化架構的話）；

四、支付平臺收到銀行扣款結果：更改訂單狀態、給帳戶加款、給積分賬戶增長積分、生成會計分錄、通知電商平臺等，此時也會有分佈式事務問題；

五、電商平臺收到支付平臺的支付結果：更改訂單狀態、扣減庫存、扣減積分、使用優惠券、增長消費積分等，系統內部各服務間調用也會遇到分佈式事問題；

 

如上圖，支付平臺收到銀行扣款結果後的內部處理流程：

一、支付平臺的支付網關對銀行通知結果進行校驗，而後調用支付訂單服務執行支付訂單處理；

二、支付訂單服務根據銀行扣款結果更改支付訂單狀態；

三、調用資金帳戶服務給電商平臺的商戶帳戶加款（實際過程當中可能還會有各類的成本計費；若是是餘額支付，還多是同時從用戶帳戶扣款，給商戶帳戶加款）；

四、調用積分服務給用戶積分帳戶增長積分；

五、調用會計服務向會計（財務）系統寫進交易原始憑證生成會計分錄；

六、調用通知服務將支付處理結果通知電商平臺；

 

如上圖，把支付系統中的銀行扣款成功回調處理流程提取出來，對應的分佈式事務問題的代碼場景：

/** 支付訂單處理 **/

@Transactional(rollbackFor = Exception.class)

public void completeOrder() {

  orderDao.update();  // 訂單服務本地更新訂單狀態

  accountService.update();  // 調用資金帳戶服務給資金賬戶加款

  pointService.update();  // 調用積分服務給積分賬戶增長積分

  accountingService.insert();  // 調用會計服務向會計系統寫入會計原始憑證

  merchantNotifyService.notify();  // 調用商戶通知服務向商戶發送支付結果通知

}

 

本地事務控制還可行嗎？

 

以上分佈式事務問題，須要多種分佈式事務解決方案來進行處理。

 

訂單處理：本地事務

 

資金帳戶加款、積分帳戶增長積分：TCC型事務（或兩階段提交型事務），實時性要求比較高，數據必須可靠。

 

會計記帳：異步確保型事務（基於可靠消息的最終一致性，能夠異步，但數據絕對不能丟，並且必定要記帳成功）

 

商戶通知：最大努力通知型事務（按規律進行通知，不保證數據必定能通知成功，但會提供可查詢操做接口進行覈對）

 

針對上以分佈式事務問題，龍果學院（http://www.roncoo.com）的《微服務架構的分佈式事務解決方案》視頻教程中將提供詳細完整的方案供你們學習和應用。

http://www.roncoo.com/details?cid=7ae3d7eddc4742f78b0548aa8bd9ccdb