支付永遠是一個公司的核心領域，因為這是一個有交易屬性公司的命脈。那么，支付系統到底長什么樣，又是怎么運行交互的呢?

拋開帶有支付牌照的金融公司的支付架構，下述鏈路和系統組成基本上符合絕大多數支付場景。

其實整體可以看成是交易核心+支付核心 兩個大系統。交易系統關聯了業務場景和底層支付，而支付系統完成了調用支付工具到對賬清算等一系列相關操作。下面我們就來一起看下 各個系統的核心組成和交互。

Part one 支付系統總覽

核心系統交互

業務圖譜

基于 Spring Boot + MyBatis Plus + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://github.com/YunaiV/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

Part two 核心系統解析

交易核心

交易核心把公司的業務系統和底層支付關聯起來，讓業務系統專注于業務，不比關心底層支付。

交易核心

基礎交易類型抽象

多表聚合 & 訂單關聯

支付核心

支付核心主要負責將多種支付類型進行抽象，變成 充值、提現、退款、轉賬四種支付形態。同時，還要負責集成多種支付工具，對支付指令進行編排等等。

支付核心總覽

支付行為編排

其目的，是實現 插件式開發、支付規則可配置的 靈活開發方式。

異常處理

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

渠道網關

資金核算

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://github.com/YunaiV/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

Part three 服務治理

平臺統一上下文

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

數據一致性治理

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

CAS校驗

冪等 & 異常補償

對賬

準實時對賬

DB拆分

異步化

支付是整個交易鏈路的核心環節，那么，怎么兼顧支付系統的穩定性和執行效率呢？是異步化。

消息異步化

外部支付調用異步化

在外部支付中，經常需要服務方與第三方支付交互，獲取預支付憑證，如上圖所示。

這種同步調用的情況下，由于需要跨外部網絡，響應的 RT 會非常長，可能會出現跨秒的情況。由于是同步調用，會阻塞整個支付鏈路。一旦 RT 很長且 QPS 比較大的情況下，服務會整體 hold 住，甚至會出現拒絕服務的情況。

因此，可以拆分獲取憑證的操作，通過獨立網關渠道前置服務，將獲取的方式異步化，從前置網關獲取內部憑證，然后由前置網關去異步調用第三方。

異步并行化

資金核算異步化

熱點賬戶賬務單獨處理

記賬事務切分

Part four 生產實踐

性能壓測

構建壓測模型，模擬現實真實場景；壓測數據進影子庫，正常業務無侵入；單機性能和集權鏈路都不能忽視；識別系統穩定性和容量配比。。。

穩定性治理

核心鏈路分離

服務依賴降級

審核編輯 ：李倩