分佈式架構 分佈式事物分析
闡述過程
傳統企業級應用是單體應用，通常是分層結構，如表現層/應用層/領域層/數據層，運用了水平切分思想，
隨着互聯網應用的發展，特別是大型電商系統，大型複雜銀行證券系統，它們都不是一個或某個單應用支持，是由多個應用或系統支持提供相應功能
，構成一個龐大應用體供用戶正常使用，此類系統難點有 須要根據業務劃分子系統，子系統定位承接具體業務，子系統之間如何協做調用運轉等
因此對於複雜系統，能夠考慮使用微服務架構 垂直切分子系統，而後水平切換單子系統，提供服務化數據庫
現分佈式事物流行處理方式如（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)