支付永遠是一個公司的核心領域，因為這是一個有交易屬性公司的命脈。那麼，支付系統到底長什麼樣，又是怎麼運行交互的呢?拋開帶有支付牌照的金融公司的支付架構，下述鏈路和系統組成基本上符合絕大多數支付場景。其實整體可以看成是交易核心+支付核心 兩個大系統。交易系統關聯了業務場景和底層支付，而支付系統完成了調 ...
支付永遠是一個公司的核心領域，因為這是一個有交易屬性公司的命脈。那麼，支付系統到底長什麼樣，又是怎麼運行交互的呢?拋開帶有支付牌照的金融公司的支付架構，下述鏈路和系統組成基本上符合絕大多數支付場景。其實整體可以看成是交易核心+支付核心 兩個大系統。交易系統關聯了業務場景和底層支付，而支付系統完成了調用支付工具到對賬清算等一系列相關操作。下麵我們就來一起看下各個系統的核心組成和交互。
1. 支付系統總覽
核心系統交互
業務圖譜
2. 核心系統解析
交易核心
交易核心把公司的業務系統和底層支付關聯起來，讓業務系統專註於業務，不比關心底層支付。
交易核心
基礎交易類型抽象
多表聚合 & 訂單關聯
支付核心
支付核心主要負責將多種支付類型進行抽象，變成充值、提現、退款、轉賬四種支付形態。同時，還要負責集成多種支付工具，對支付指令進行編排等等。
支付核心總覽
支付行為編排
其目的，是實現插件式開發、支付規則可配置的 靈活開發方式。
異常處理
異常處理包括了 重覆支付、部分支付、金額不一致、其他異常等異常場景。
渠道網關
資金核算
3. 服務治理
平臺統一上下文
通過確定系統邊界、業務建模拆分之後，整個支付平臺被拆分幾十個服務，而如何保障在服務間流轉業務信息不被丟失，是我們需要考慮的問題。平臺統一上下文的要素信息（唯一業務標識碼），在整個支付平臺鏈路中全程傳遞，被用來解決這個問題。
數據一致性治理
大型的支付公司，內部都有非常嚴格和完備的數據一致性方案，比如採用業務侵入性非常大的分散式事務等，以犧牲開發效率來提升數據的穩定，是非常有必要的。而業務公司，如果不採用分散式事務又有哪些應對策略呢？
CAS校驗
冪等 & 異常補償
對賬
準實時對賬
DB拆分
非同步化
支付是整個交易鏈路的核心環節，那麼，怎麼兼顧支付系統的穩定性和執行效率呢？是非同步化。
消息非同步化
外部支付調用非同步化
在外部支付中，經常需要服務方與第三方支付交互，獲取預支付憑證，如上圖所示。
這種同步調用的情況下，由於需要跨外部網路，響應的 RT 會非常長，可能會出現跨秒的情況。由於是同步調用，會阻塞整個支付鏈路。一旦 RT 很長且 QPS 比較大的情況下，服務會整體 hold 住，甚至會出現拒絕服務的情況。
因此，可以拆分獲取憑證的操作，通過獨立網關渠道前置服務，將獲取的方式非同步化，從前置網關獲取內部憑證，然後由前置網關去非同步調用第三方。
非同步並行化
資金核算非同步化
熱點賬戶賬務單獨處理
記賬事務切分
4. 生產實踐
性能壓測
構建壓測模型，模擬現實真實場景；壓測數據進影子庫，正常業務無侵入；單機性能和集權鏈路都不能忽視；識別系統穩定性和容量配比。。。
穩定性治理
核心鏈路分離
服務依賴降級
作者：PetterLiu
本文來自博客園，作者：古道輕風，轉載請註明原文鏈接：https://www.cnblogs.com/88223100/p/How-to-design-a-payment-system.html
