首先,提現業務邊界分析可以拆分為兩大部分:業務用例邊界以及系統用例邊界。這裡著重講一下系統用例邊界,分為:
支付層作為提供基礎支付服務的核心系統,所承擔的職責圍繞著以下主要業務功能點:
以協議方式提供適用於各類產品使用的支付服務:
可供靈活編輯的各種核心處理規則配置機制,以及提供配套的規則管理服務:
本文重點描述非同步提現支付協議在申請過程中支付層的體系結構以及處理流程。
需要重點指出的是,支付層所提供的協議申請使用嵌套分散式事物,在此將申請過程分為兩個階段處理:
階段一:
1. 調用者開啟分散式事務,在事務塊內請求非同步提現支付協議申請:
2. 整合現有各類非實時處理類提現產品要素,設計專用的申請單據對象;非同步提現支付協議支持每次申請單筆或批量明細項;
3. 通過內部的業務接入層將專用單據轉換成統一的內部領域模型對象;
4. 對領域模型對象加工,包括補全、拆分、檢查等;
5. 啟動嵌套分散式任務,執行預授權處理,即凍結提現款;
6. 組裝處理結果並返回。
階段二:
調用者根據支付層協議申請的返回結果,決定提交或回滾分散式事務:
非同步提現支付協議推進處理
支付層自行調度的推進處理
產品層通知方式的推進處理
非同步提現支付協議取消/接受清算處理結果回執
非同步提現支付協議取消
l 這裡提到的協議取消不是對整個協議的取消,支付層只允許對單筆支付指令的取消行為;
接受清算處理結果回執
l 在經歷了上述兩個處理過程後,清算層根據自有的業務規則進行清算處理;最終的清算結果需要確保通知到支付層;此處繼續選用高可靠性的ESB確保到達。
統一協議處理結果回執/同步提現支付協議申請
統一協議處理結果回執
同步提現支付協議申請
對於需要同步支付並清算的提現產品,使用本協議;同非同步提現支付協議,本協議也可以使用嵌套分散式事務;
同步提現支付協議推進/恢復處理
l 支付層同步請求清算,清算層的返回結果中有三種清算狀態:
如果支付層在請求同步清算時出現了嚴重異常,如清算層異常宕機或清算返回丟失,則仍然返回產品處理中結果;支付層內部回復程序會繼續嘗試回復。
提現退票支付協議
提現退票支付協議作為本講引入的協議之一,通過申請支付層的協議,由支付層負責賬務與業務推進處理;在本協議下,退票流水將作為支付指令存在,與被退票的支付指令平級;不會去對已經處理成功的原支付流水做任何改動;
由於不需要進行清算,支付層內部只需要處理賬務充值部分即可;所以本協議也是同步的,即申請成功則全部處理完畢。
打款機構/支付能力/分散式任務
打款機構
任何一筆提現申請,最終目的都是從某一支付賬戶提現至指定的銀行卡上;這個銀行卡就是提現支付協議中指定的收款方信息;
由於銀行卡信息中的開戶行種類繁多,比如各類非直接打款銀行;對於這些開戶行的提現申請,實際會通過跨行的方式進行提現;具體說來就是根據開戶行、提現的額度範圍、賬戶的對公對私屬性等,來決定最優的提現方式;
產品層不知道本次提現的實際打款機構;而支付層對每筆支付指令進行賬務處理時需要知道具體的打款機構,這樣才能請求賬務進行扣款或者回充處理;所以打款機構的規則就需要支付層進行維護。
分散式任務
支付層的大量調度任務如非同步提現支付協議的推進、同步提現支付協議的掉單恢復等;將來會有更多的調度任務加入;
支付能力
作為支付協議最重要的處理規則,支付層對外提供可供快速定製的各種內部處理打包方案;
其他服務類
公共查詢類服務
a) 協議授權查詢服務
b) 機構信息查詢服務
提現查詢類服務
a) 銀行卡段檢查服務
b) 對公賬戶聯行號檢查服務
c) 清算通道支付限額查詢服務
d) 提現統計查詢服務
管理服務
a) 協議授權管理服務
b) 打款機構管理服務
c) 支付能力管理服務
d) 緩存刷新服務
本地緩存
a) 機構信息查詢結果;
b) 清算通道支付限額查詢結果;
c) 支行列表查詢結果;
除此之外,支付層自有的配置規則也可以考慮使用緩存的模式,減少資料庫讀取頻率:
a) 協議授權關係列表;打款機構規則列表;
b) 支付能力列表;
推薦閱讀: