分佈式架構 分佈式事物

傳統企業級應用是單體應用，一般是分層結構，如表現層/應用層/領域層/數據層，運用了水平切分思想，
隨着互聯網應用的發展，特別是大型電商系統，大型複雜銀行證券系統，它們都不是一個或某個單應用支持，是由多個應用或系統支持提供相應功能
，構成一個龐大應用體供用戶正常使用，此類系統難點有 需要根據業務劃分子系統，子系統定位承接具體業務，子系統之間如何協作調用運轉等
所以對於複雜系統，可以考慮使用微服務架構 垂直切分子系統，然後水平切換單子系統，提供服務化

現分佈式事物流行處理方式如（TCC事物補償、最大努力通知、消息一致性）
推薦使用 消息一致性方案處理分佈式事物

本文主要通過案例講解微服務架構中分佈式事物處理方式

如圖所示分析問題
1.service.doSave(model)操作數據庫如失敗，數據未處理成功，進入catch事物回滾，正常執行
2.同上如成功，此時正常發送消息到MQ服務器如果成功，提交事物正常執行
3.同上發送MQ服務器如失敗，會存在數據不一致情況

• 發送MQ服務器由於網絡原因，當時未成功，後續成功，此時會出現數據庫回滾，消息已消費
• 發送MQ服務器成功，由於負載量過大，消息阻塞，此時會出現數據庫事物提交，消息未消費

很多喜歡用這種方式處理，由於極少數情況下會發生問題 忽略了以上問題
針對以上問題，可以採取存儲本地事件加定時任務輪訓方式

如圖所示調整優化如下

• 業務操作數據庫成功後保存事件，把業務操作和操作事件保持在同個事物中
  要麼都成功，要麼都失敗。數據保持一致
• 業務操作成功後發送消息到MQ，MQ發送成功後，刪除本地事件記錄，可能有些人會問 如果同樣發送MQ網絡原因遲遲會返回結果，此時本地事件狀態處於‘未發送’狀態
• 通過定時輪訓本地處於‘未發送’狀態記錄，然後持續發送消息到MQ，保證MQ消息正常消費，MQ服務消費者針對消息要做冪等，如有些消息自帶重試功能如（rabbitMQ、rocketMQ）
• 正常情況消息由於當時網絡帶寬問題、MQ服務器問題等導致不可用，輪訓發送消息可加大消息被正常消費力度
• 極端情況下同條消息發送5-10次還未正常消費，此時需要人工干預處理

通過下單、支付流程實例講解消息一致性處理


如圖所示分析問題

傳統微服務方式處理下單流程如下

• 提交訂單成功後，需要校驗參數/使用優惠劵/扣庫存/減積分等等操作，其中如果處理100個場景，每個場景都同步使用微服務遠程調用方式，系統無法承受龐大調用開銷。隨着業務、場景增多，系統最終會處於緩慢、卡死、崩潰等
• 可能有些人會說 優惠劵、庫存、積分等都可以橫向擴展、部署多臺能夠提供更高效服務，但是下單這一刻從開始到結束，其中整個流程還是
  處於同步操作，每個節點還是存在耗時開銷，加起來整個鏈路還是緩慢，未達到最終效果

針對以上問題，接下來將通過rocketMQ處理難點，解耦應用。

如圖所示，處理流程如下

• 提交訂單成功後，校驗參數通過後，首先創建不可見訂單，此舉目的避免後續部分操作失敗，訂單丟失

• 通過線程池並行處理（優惠劵、減庫存、積分）等等業務場景，統一設置超時時間
  存在如下情況
  1.如優惠劵、減庫存、積分相應線程統一都處理成功後，更改訂單狀態爲可見，結束 流程
  2.如優惠劵線程執行成功處於等待狀態，減庫存、積分其中某個線程一直未執行成功，到達設置超時時間後，統一認定失敗
  因爲，有可能網絡、調用等其他原因減庫存、積分存在執行成功可能，此時通過發送消息到MQ，所有下單依拉操作系統
  統一訂閱此退單消息，做相應回滾操作。由於發送消息到MQ也存在 網絡、mq服務器異常等風控問題，所以推薦使用rocketmq作爲MQ消息中間件
  後續文章會詳細闡述rocketmq，本文簡單描述如下
  1.單臺rocketmq 可承受千萬級別消息處理能力，消息過多後會堆積不會丟失
  2.rocketmq 提供者、消費者同時可支持集羣部署、穩定健壯
  3.rocketmq處理能力快，效率高

• 極端情況下 處理（優惠劵、減庫存、積分）期間或者完後機房停電、應用服務器被攻擊宕機，此處本地庫中存有隱藏訂單記錄，
  待應用恢復後，通過單獨定時任務模塊Elastic-Job，定期分片查詢 隱藏訂單記錄，由於業務場景狀態複雜，此時發送MQ服務器進行退單操作

支付場景如下

同訂單處理思路一致，通過Rocketmq解耦，效果如下

微服務架構優缺點

優點
1.降低系統複雜度，細化顆粒度
2.子系統專人開發，細化專注點
3.解耦相關業務
4.可用不通語言腳本開發集成
5.子系統可橫向擴展，獨立部署
缺點
1.開發成本加大，開發應用難度也加大
2.測試方式調整，功能測試、性能測試難度加大（如全鏈路壓測）
3.服務治理難度加大
4.存在分佈式事物等問題
5.數據庫層面部署及使用複雜（主從/雙主/讀寫分離/分區/分庫/分表等）

總結

根據業務發展過程，不要盲目使用微服務架構，此架構雖解耦細化應用，但同時也會帶來很多問題。
正確使用分佈式/微服務架構，提供系統高可用方案，促進各系統之間協作交互，保障系統正常運轉
多系統耦合較強關係下，可採用MQ方式解耦

作者簡介：張程 技術研究

更多文章請關注微信公衆號：zachary分解獅 (frankly0423)