社區裏缺的不是架構圖，而是可供參考的架構實踐。程序員缺的不是技術原理知識，而是抽象來的可供複用的方案思路。爲了切實幫助技術人成長，在信息爆炸時代獲取最精華的架構知識，騰訊雲開發者攜手騰訊雲架構師技術同盟推出架構師系列文集，每期會以《如何設計一個 XX 系統》爲主題，分享同盟架構師們多年經驗抽象來的經典方案設計思想。

本文是系列第一篇，我們聊聊支付系統的經典設計。除了作爲普適方案的本文，作者還準備了上中下三篇信息密度更豐富、細節更詳實的雄文，各位讀者朋友一定持續關注騰訊雲開發者公衆號，不錯過後續更新。

01

概述

支付系統在電商交易平臺中發揮着至關重要的作用，涵蓋了支付處理、安全性保障、支付方式管理、訂單管理與結算、交易記錄和報告、退款與售後支持等方面。一個高效、安全、可靠的支付系統對於電商企業的順利運營和用戶體驗至關重要。

02

支付系統 / 核心交易系統的架構特點

   2.1 支付系統的作用

從上圖中我們可以看出真實的資金流向。首先當用戶產生支付行爲時，資金從用戶端流向支付系統，退款時則相反，從支付系統迴流至用戶端。因此在整個交易過程中用戶端與支付系統是雙向資金的流動方式。對於支付系統而言，資金有進有出。從支付系統到商戶端就比較簡單了，在清算完成後支付系統負責將代收的資金結算給商戶，通常結算的操作可以在線上來完成（採用支付公司代付接口或者銀企直連接口來完成），也可以由公司財務通過線下手工轉賬的方式來完成，因此這種資金流動的方式是單向的。出於資金安全考慮，大多數公司通常這部分採用線下方式實現。

真實的資金流由支付公司按照約定期限（通常 T+1 ）結算到平臺公司對公賬戶中，然後再由平臺公司再按照交易明細進行二次清算後結算給對應的商戶。

   2.2 支付系統的架構

   2.2.1 架構概述

系統說明

1. 支付網關：支付網關是連接不同支付渠道和商戶系統的中間平臺，負責接收來自商戶的支付請求，然後將請求傳遞給相應的支付渠道或支付核心，以完成支付過程。

2. 收銀臺：用戶在進行線上購物或支付時，通過進入一個頁面來完成支付的過程。用戶可以在收銀臺上選擇支付方式、輸入支付信息，並進行支付操作。收銀臺通常是支付網關的一部分。

3. 交易系統：業務發起支付時，支付系統與業務方的前置模塊，主要用於對業務的校驗、接單、查詢請求等處理。

4. 支付核心：支付核心是支付系統的核心引擎，負責處理支付過程中的各種交易請求，包括接收支付請求、交易處理、資金結算等。

5. 商戶系統：商戶系統是爲商戶提供的管理支付交易、查詢交易數據、配置支付選項等功能的管理平臺。商戶可以通過商戶平臺來管理自己的支付業務。

6. 補償系統：補償系統通常用於處理支付過程中出現的異常情況，例如支付失敗、訂單取消等情況，需要對相關方進行補償或調整。

7. 清結算系統：清結算系統負責處理支付過程中的結算動作，確保資金結算到位，包括向商戶結算款項，同時也負責向渠道支付相應的手續費等。

8. 對賬系統：對賬系統用於進行不同支付系統之間的數據對賬，以確保交易數據的準確性。它會對支付核心、商戶平臺、清結算中心等各個組件的數據進行對比，防止數據出現異常。

9. 會計系統：會計系統用於處理支付過程中產生的會計覈算相關的數據，確保資金的正確流轉和賬務處理，保證支付過程中的財務準確性。

10. 財務系統：財務系統用於整體管理和監控支付過程中的資金流動和資金狀況，幫助企業進行財務決策和管理。

11. 運營系統：運營系統負責支付系統的日常運營管理，包括系統監控、問題處理、性能優化等，確保支付系統的穩定運行。

12. 渠道管理：渠道管理用於管理支付網關連接的不同支付渠道，包括銀行、第三方支付服務提供商等，以確保支付網關可以順利地將支付請求發送到適當的支付渠道。

   2.2.2 支付系統設計要點

在支付系統中，支付網關和支付渠道的對接確實是非常重要且繁瑣的功能之一。支付網關作爲對外提供服務的接口，扮演着將資金操作請求分發到對應支付渠道模塊的角色。支付渠道模塊則負責接收網關的請求，並調用相應支付渠道的接口執行真正的資金操作。

支付網關在這個過程中類似於設計模式中的 “wrapper”，它封裝了各個支付渠道之間的差異，爲網關提供了統一的接口。這樣一來，無論是哪個支付渠道，網關都能夠以統一的方式與其進行交互。

支付系統對其他系統，尤其是交易系統，提供了多種支付服務，包括簽約、支付、退款、充值、轉賬、解約等。有些地方還可能提供簽約並支付的接口，以支持在支付過程中綁定銀行卡的操作。這些支付服務的實現流程基本上是相似的，包括下單、取消訂單、退單、查詢訂單等操作。

每個操作的實現通常包括以下七個步驟：

1. 參數校驗：對傳入的參數進行驗證，確保其符合要求和規範。

2. 支付路由：根據業務規則和策略，確定使用哪個支付渠道來處理該操作。

3. 生成訂單：根據業務需求，生成相應的訂單信息。

4. 風險評估：對支付操作進行風險評估，以確保交易的安全性。

5. 調用渠道服務：通過支付網關調用支付渠道模塊的接口，執行實際的資金操作。

6. 更新訂單：根據支付結果，更新訂單的狀態和相關信息。

7. 發送消息：向相關係統或用戶發送支付結果通知。

對於一些比較複雜的支付渠道服務，還可能涉及到異步通知和處理的步驟，以確保支付結果的及時性和準確性。

在實現支付系統時，軟件工程師需要具備紮實的編程技能和對支付領域的深入理解。同時，注重細節、進行充分的測試和質量保證也是非常重要的，以確保支付系統的穩定性和安全性。此外，與團隊成員和其他相關方進行良好的溝通和協作，也是成功實現支付系統的關鍵因素之一。

03

交易系統的鏈路優化

交易系統在整個支付系統中充當了連接業務前置和支付網關的橋樑，確保支付過程的可靠性、一致性和安全性。其設計和實現需要考慮各種業務場景、併發情況和異常情況，以構建一個穩定、高效的支付交易處理系統。同時交易系統還需要與其他系統進行集成，如清結算系統、風控系統等，以實現全面的支付功能和業務支持。

交易系統具備如下功能：

1. 業務校驗：交易核心首先會對業務方發起的支付請求進行校驗，確保請求的合法性和有效性。這可能包括驗證支付金額、商戶信息、訂單號、支付方式等，以防止惡意或錯誤的請求。

2. 接單：交易核心在通過校驗後，會接受業務方的支付請求，即發起支付的指令。這可能涉及生成新的支付訂單，將訂單信息進行存儲，併爲後續的支付流程做好準備。

3. 查詢請求處理： 除了發起支付，業務方可能還會發起查詢請求，用於獲取訂單的支付狀態、交易詳情等信息。交易核心會處理這些查詢請求，從數據庫或緩存中檢索相應的訂單信息，並將查詢結果返回給業務方。

4. 交互與通信：交易核心與業務方的前置模塊進行通信，可能通過接口、消息隊列等方式。這樣的通信可以包括支付請求的傳遞、交易狀態的更新通知等。

5. 併發和事務處理：交易核心需要處理併發的支付請求，確保數據的一致性和完整性。使用事務管理技術可以保證支付過程中的數據操作是安全的，避免數據不一致或意外的情況。

6. 異常處理：在支付過程中，可能會出現各種異常情況，如支付超時、支付失敗等。交易核心需要捕獲並處理這些異常，向業務前置或支付網關返回適當的錯誤信息，以便業務方進行相應的處理。

04

對賬系統的設計

   4.1 對賬系統概述

對賬系統或對賬平臺通常用於比對財務數據上的金額或訂單數據的差異等，主要體現在交易的金額上。然而，這裏所指的對賬平臺旨在成爲一個更廣泛的工具，一個平臺化的解決方案。儘管對賬的需求起源於財務對賬，但目前該平臺已經擴展支持多種業務領域之間不同形式的對賬工作。此外，這個工具化的產品還能夠支持不同業務形態下的大數據量比對。通過統一的平臺建設，該對賬平臺使得不同業務線之間相同或相似的對賬訴求能夠得到統一解決，從而減少人力資源消耗和獨立開發所帶來的資源浪費。總體而言，這個對賬平臺成爲一個全面且高效的工具，使得企業能夠更加便捷地進行對賬工作，並且滿足多樣化的對賬需求。同時，平臺化的特性也使得它更靈活適應不同業務場景，提升了數據對比的精度和效率。

對賬其實就是在兩個數據源當中，找出指定範圍內的相同及差異的數據。對賬系統都會包含三個環節：數據的採集加工，對賬，以及調賬。

1. 數據採集：通過將不同源的數據採集加工成標準化或易於對賬的數據，爲對賬做準備。

2. 對賬：找出兩個數據源中的相同及差異化的數據輸出。

3. 調賬：針對對賬差異化的金額結果，找出背後出現差異的原因，並進行財務上的調賬操作。

   4.2 對賬需求分析

   4.2.1 對賬數據間的關係

我將需要比對的兩個數據源稱爲主數據源與目標數據源，那麼通常比對的兩個大數據源的數據關係會有如下的三種情況：

1. 一對一：主數據源與目標數據源表之間的數據是一對一的關係，即通過一個或多個字段的組合最多在另一張表中找到一條相應的記錄。

2. 一對多：數據表中的記錄是一對多的關係，即主表的記錄可以在目標表中找到相應的多條記錄，場景如訂單表與訂單明細之間的關係。

3. 多對多：主數據源表中的多條記錄與目標表中的多條記錄進行比對，如業務系統中的訂單明細與財務系統中的結算明細數據進行比對。

當然，在不影響業務含義的情況下，針對不同的對賬數據間的關係，其實都可以轉化成一對一的關係進行比對。如一對多以及多對多的關係，我們都可以將數據分組彙總後，通過一對一關係進行匹配比對。

   4.2.2 對賬的維度

在業務的對賬需求上，數據會存在下面兩種情況的對賬：

1. 明細對賬：要求最細粒度的對賬，具體到表中的每一條記錄進行比對。

2. 彙總對賬：只要求按照需要的維度彙總後比對總金額，總數量等彙總後的數據。

彙總對賬的維度可能不只一個。例如，業務上可以按照商家和月度進行彙總後對賬。也可以按照，商家及產品維度彙總後進行對賬，總之彙總對賬的維度其實是靈活多變的，應當完全按照不同的業務線進行配置。

   4.2.3 對賬結果的輸出

對賬結果包含了兩部分，第一是交集，也就是相同的數據，第二部分是差集，也就是不同的部分，即有差異的部分。在很多的對賬訴求當中，有的業務線需要輸出全量的數據，即包含交集和所有差集，而有的業務線則只需要保留有差異的部分即可。因此根據不同的對賬訴求，我們將對賬結果輸出模式設置成如下四種：

1. 全量存儲：存儲主數據源全量以及主 / 目標源之間全部差異數據。

2. 全量差異存儲：僅存儲兩個源之間所有差異數據。

3. 主數據源差異存儲：僅存儲主與目標源不一致以及不存在於目標源的數據。

4. 目標數據源差異存儲：僅存儲不存在於主數據源以及與主不一致的目標源數據。

05

總結

支付系統的健壯性和穩定性至關重要。對於一個複雜的系統來說，監控是必不可少的。監控可以分爲多個層面，包括業務監控（核心交易流程）、渠道監控（支付渠道的可用性和性能）、商戶監控（商戶交易狀況）和賬戶監控（用戶賬戶變動等）。這些監控措施可以及早發現問題，減少潛在的風險，架構設計是一個動態的過程。

   作者介紹

江湖人稱 “山哥”，騰訊雲架構師技術同盟名人堂專家、“技術方舟” 主理人，專注於人工智能、互聯網金融和大型電商領域，擁有豐富的架構設計和開發經驗，擅長大模型調優及智能體搭建，精通 TensorFlow 和 PyTorch 等深度學習框架，具備全面的技術選型與實施能力，爲企業提供高效、穩定的技術解決方案。

原創作者｜李偉山

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/sshFzyWwDhAcOb7ZXBstzw