6.微服務-項目大體架構

一、支付平臺服務化流程

在這裏插入圖片描述

二、分佈式事務問題的代碼場景

當支付平臺收到扣款結果的處理僞代碼,我們可以看到如果是多個服務,位於不同主機,不同的網絡當中,我們沒有辦法用本地事務保證要麼一起成功要麼一起失敗

/**
 *支付平臺收到第三方支付平臺的扣款通知
**/
public  function completeOrder() { 
orderDao::update(); // 訂單服務本地更新訂單狀態 
accountService::update(); // 調用資金賬戶服務給資金帳戶加款 
pointService::update(); // 調用積分服務給積分帳戶增加積分 
accountingService::insert(); // 調用會計服務向會計系統寫入會計原始憑證 
merchantNotifyService::notify(); // 調用商戶通知服務向商戶發送支付結果通知 
} 

在這裏插入圖片描述
一個業務流程中要跨多個服務調用,就有可能會遇到分佈式事務問題。 訂單、支付、入賬等核心流程中,數據的準確性和可靠性尤爲重要!

三、不同的事務的解決方案

上圖當中就體現了分佈式事務的處理方式,接下來我們大致的瞭解下這些方式的適用場景及相關理論具體的我們在用代碼實現的時候可以回過頭來看。

在這裏插入圖片描述

BASE理論及CAP定理
BASE
BA: Basic Availability 基本業務可用性(支持分區失敗)
S: Soft state 柔性狀態(狀態允許有短時間不同步,異步)
E: Eventual consistency 最終一致性(最終數據是一致的,但不是實時一致)
原子性(A)與持久性(D)必鬚根本保障
爲了可用性、性能與降級服務的需要,只有降低一致性( C ) 與 隔離性( I ) 的要求
酸鹼平衡(ACID-BASE Balance)

CAP定理

定理: 對於共享數據系統,最多隻能同時擁有CAP其中的兩個,沒法三者兼顧。
任兩者的組合都有其適用場景
真實系統應當是ACID與BASE的混合體
不同類型的業務可以也應當區別對待
在這裏插入圖片描述

2.1可靠消息最終一致(異步確保型)

在這裏插入圖片描述

實現
業務處理服務在業務事務提交前,向實時消息服務請求發送消息,實時消息服務只記錄消息數據,而不真正發送。業務處理服務在業務事務提交後,向實時消息服務確認發送。只有在得到確認發送指令後,實時消息服務才真正發送

消息
業務處理服務在業務事務回滾後,向實時消息服務取消發送。消息狀態確認系統定期
找到未確認發送或回滾發送的消息,向業務處理服務詢問消息狀態,業務處理服務根
據消息ID或消息內容確定該消息是否有效

約束
被動方的處理結果不影響主動方的處理結果,被動方的消息處理操作是冪等操作
成本
可靠消息系統建設成本
一次消息發送需要兩次請求,業務處理服務需實現消息狀態回查接口
優點、適用範圍
消息數據獨立存儲、獨立伸縮,降低業務系統與消息系統間的耦合

需要實現的服務
可查詢操作、冪等操作

方案特點
兼容所有實現AMQP標準的MQ中間件
確保業務數據可靠的前提下,實現業務數據的最終一致(理想狀態下基本是準實時一致)
適用
1、對應支付系統會計異步記賬業務
2、普通的積分賬戶增加積分的服務

2.2柔性事務解決方案:TCC(兩階段型、補償型)

在這裏插入圖片描述
實現
一個完整的業務活動由一個主業務服務與若干從業務服務組成
主業務服務負責發起並完成整個業務活動
從業務服務提供TCC型業務操作
業務活動管理器控制業務活動的一致性,它登記業務活動中的操作, 並在
業務活動提交時確認所有的TCC型操作的confirm操作,在業務活動取消
時調用所有TCC型操作的cancel操作
成本
實現TCC操作的成本
業務活動結束時confirm或cancel操作的執行成本
業務活動日誌成本
適用範圍
強隔離性、嚴格一致性要求的業務活動
適用於執行時間較短的業務(比如處理賬戶、收費等業務)

用到的服務模式
TCC操作、冪等操作、可補償操作、可查詢操作
方案特點
不與具體的服務框架耦合(在RPC架構中通用)
位於業務服務層,而非資源層
可以靈活選擇業務資源的鎖定粒度

2.3柔性事務解決方案:最大努力通知(定期校對)

在這裏插入圖片描述

實現
業務活動的主動方,在完成業務處理之後,向業務活動的被動方發送消息,
允許消息丟失。
業務活動的被動方根據定時策略,向業務活動主動方查詢,恢復丟失的業
務消息。
約束
被動方的處理結果不影響主動方的處理結果
成本
業務查詢與校對系統的建設成本
適用範圍
對業務最終一致性的時間敏感度低
跨企業的業務活動

柔性事務解決方案:最大努力通知(定期校對)

方案特點
業務活動的主動方在完成業務處理後,向業務活動被動方發送通知消息(允許消息丟失)
主動方可以設置時間階梯型通知規則,在通知失敗後按規則重複通知,直到通知N次後不主動方提供校對查詢接口給被動方按需校對查詢,用於恢復丟失的業務消息

應用案例
銀行通知、商戶通知等(各大交易業務平臺間的商戶通知:多次通知、查詢校對、對賬文件)

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章