內(nèi)容導(dǎo)讀：支付永遠(yuǎn)是一個公司的核心領(lǐng)域，因為這是一個有交易屬性公司的命脈。那么，支付系統(tǒng)到底長什么樣，又是怎么運行交互的呢？

拋開帶有支付牌照的金融公司的支付架構(gòu)，下述鏈路和系統(tǒng)組成基本上符合絕大多數(shù)支付場景。

其實整體可以看成是交易核心+支付核心 兩個大系統(tǒng)。

交易系統(tǒng)關(guān)聯(lián)了業(yè)務(wù)場景和底層支付，而支付系統(tǒng)完成了調(diào)用支付工具到對賬清算等一系列相關(guān)操作。下面我們就來一起看下各個系統(tǒng)的核心組成和交互。

Part one 支付系統(tǒng)總覽

核心系統(tǒng)交互

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

Part two 核心系統(tǒng)解析

交易核心

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

交易核心

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

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

支付核心

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

支付核心總覽

支付行為編排

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

異常處理

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

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

資金核算

Part three 服務(wù)治理

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

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

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

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

CAS校驗

冪等 & 異常補償

對賬

準(zhǔn)實時對賬

DB拆分

異步化

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

消息異步化

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

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

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

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

異步并行化

資金核算異步化

熱點賬戶賬務(wù)單獨處理

記賬事務(wù)切分

Part four 生產(chǎn)實踐

性能壓測

構(gòu)建壓測模型，模擬現(xiàn)實真實場景；壓測數(shù)據(jù)進影子庫，正常業(yè)務(wù)無侵入；單機性能和集權(quán)鏈路都不能忽視；識別系統(tǒng)穩(wěn)定性和容量配比。。。

穩(wěn)定性治理

核心鏈路分離

服務(wù)依賴降級