商城體系之支付系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

繼續(xù)接前文手撕商城系統(tǒng)架構(gòu)設(shè)計(jì)與實(shí)現(xiàn)

支付系統(tǒng)是商城體系里面另一個(gè)關(guān)鍵核心系統(tǒng)，所有商城線上交易行為最終轉(zhuǎn)化收入業(yè)績重要支撐。支付最主要目標(biāo)是保證系統(tǒng)穩(wěn)定、高可靠，承載高并發(fā)支付結(jié)算場景。廣大企業(yè)是沒有支付牌照的，全國有支付牌照的公司就那么20幾家，所以眾多公司都是接入第三方公司（如：支付寶、微信、銀聯(lián)）。廣大企業(yè)的支付業(yè)務(wù)更多時(shí)候做一個(gè)聚合的中轉(zhuǎn)支付。

拋開帶有支付牌照的金融公司的支付架構(gòu)，下述鏈路和系統(tǒng)組成基本上符合絕大多數(shù)支付場景。其實(shí)整體可以看成是交易核心+支付核心兩個(gè)大系統(tǒng)。

交易系統(tǒng)關(guān)聯(lián)了業(yè)務(wù)場景和底層支付，而支付系統(tǒng)完成了調(diào)用支付工具到對賬清算等一系列相關(guān)操作。

下面我們就來一起看下各個(gè)系統(tǒng)的核心組成和交互。

1、支付系統(tǒng)總覽

1.1、核心系統(tǒng)交互

1.2 業(yè)務(wù)圖譜

2、核心系統(tǒng)解析

2.1、交易核心

交易核心把公司的業(yè)務(wù)系統(tǒng)和底層支付關(guān)聯(lián)起來，讓業(yè)務(wù)系統(tǒng)專注于業(yè)務(wù)，不比關(guān)心底層支付。

2.2、基礎(chǔ)交易類型抽象

2.3、多表聚合 & 訂單關(guān)聯(lián)

2.4、支付核心

支付核心主要負(fù)責(zé)將多種支付類型進(jìn)行抽象，變成充值、提現(xiàn)、退款、轉(zhuǎn)賬四種支付形態(tài)。同時(shí)，還要負(fù)責(zé)集成多種支付工具，對支付指令進(jìn)行編排等等。

支付流程說明

用戶在商城選購商品并發(fā)起支付請求；
商城將支付訂單通過B2C網(wǎng)關(guān)收款接口傳送至支付網(wǎng)關(guān)；
用戶選擇網(wǎng)銀支付及銀行，支付平臺將訂單轉(zhuǎn)送至指定銀行網(wǎng)關(guān)界面；
用戶支付完成，銀行處理結(jié)果并向平臺返回處理結(jié)果；
支付平臺接收處理結(jié)果，落地處理并向商戶返回結(jié)果；
商城接收到支付公司返回結(jié)果，落地處理（更改訂單狀態(tài)）并通知用戶。

一般而言支付系統(tǒng)會給商戶設(shè)置有“可用余額”賬戶、“待結(jié)算”賬戶；系統(tǒng)在接收到銀行返回支付成功信息會進(jìn)行落地處理，一方面更改對應(yīng)訂單狀態(tài)，另一方面在商戶待結(jié)算賬戶記入一筆金額；該筆金額，系統(tǒng)會根據(jù)結(jié)算周期從待結(jié)算賬戶--->“可用余額”賬戶。

退款流程說明

用戶在商戶平臺發(fā)起退款申請，商戶核實(shí)退款信息及申請；
商戶登錄支付平臺賬戶/或者通過支付公司提供的退款接口向支付平臺發(fā)起退款；
支付系統(tǒng)會對退款信息校驗(yàn)（退款訂單對應(yīng)的原訂單是否支付成功？退款金額是否少于等于原訂單金額？），校驗(yàn)商戶賬戶余額是否充足等；校驗(yàn)不通過，則無法退款；
支付系統(tǒng)在商戶可用余額賬戶扣除金額，并將退款訂單發(fā)送至銀行，銀行完成退款操作。注意：對于網(wǎng)關(guān)收款的訂單退款，各銀行要求不一，有些銀行提供的退款接口要求原訂單有效期在90或180天，有些銀行不提供退款接口；針對超期或者不支持接口退款的訂單，支付公司通過代付通道完成退款操作。

2.5、支付核心總覽

2.6、支付行為編排

其目的，是實(shí)現(xiàn) 插件式開發(fā)、支付規(guī)則可配置的靈活開發(fā)方式。

2.7、異常處理

異常處理包括了重復(fù)支付、部分支付、金額不一致、其他異常等異常場景。

2.8、渠道網(wǎng)關(guān)

2.9、資金核算

3、服務(wù)治理

3.1、平臺統(tǒng)一上下文

通過確定系統(tǒng)邊界、業(yè)務(wù)建模拆分之后，整個(gè)支付平臺被拆分幾十個(gè)服務(wù)，而如何保障在服務(wù)間流轉(zhuǎn)業(yè)務(wù)信息不被丟失，是我們需要考慮的問題。平臺統(tǒng)一上下文的要素信息（唯一業(yè)務(wù)標(biāo)識碼），在整個(gè)支付平臺鏈路中全程傳遞，被用來解決這個(gè)問題。

3.2、數(shù)據(jù)一致性治理

大型的支付公司，內(nèi)部都有非常嚴(yán)格和完備的數(shù)據(jù)一致性方案，比如采用業(yè)務(wù)侵入性非常大的分布式事務(wù)等，以犧牲開發(fā)效率來提升數(shù)據(jù)的穩(wěn)定，是非常有必要的。而業(yè)務(wù)公司，如果不采用分布式事務(wù)又有哪些應(yīng)對策略呢？

3.3、CAS校驗(yàn)

3.4、冪等 & 異常補(bǔ)償

3.5、對賬

3.6、準(zhǔn)實(shí)時(shí)對賬

3.7、DB拆分

3.8、異步化

支付是整個(gè)交易鏈路的核心環(huán)節(jié)，那么，怎么兼顧支付系統(tǒng)的穩(wěn)定性和執(zhí)行效率呢？是異步化。

3.9、消息異步化

3.9、外部支付調(diào)用異步化

在外部支付中，經(jīng)常需要服務(wù)方與第三方支付交互，獲取預(yù)支付憑證，如上圖所示。

這種同步調(diào)用的情況下，由于需要跨外部網(wǎng)絡(luò)，響應(yīng)的 RT 會非常長，可能會出現(xiàn)跨秒的情況。由于是同步調(diào)用，會阻塞整個(gè)支付鏈路。一旦 RT 很長且 QPS 比較大的情況下，服務(wù)會整體 hold 住，甚至?xí)霈F(xiàn)拒絕服務(wù)的情況。

因此，可以拆分獲取憑證的操作，通過獨(dú)立網(wǎng)關(guān)渠道前置服務(wù)，將獲取的方式異步化，從前置網(wǎng)關(guān)獲取內(nèi)部憑證，然后由前置網(wǎng)關(guān)去異步調(diào)用第三方。