手哥架构宝典系列：支付系统2.0架构演进
本文節選自手哥架構寶典 - 支付系統演進2.0版本
手哥架構寶典之支付系統1.0發布后，很多架構師朋友表示收益匪淺，詢問支付系統2.0版本什么時候放出來，今天刊發出《架構寶典》支付系統2.0版本，以饗讀者
概述
在 1.0 的支付系統中，我們遇到了諸多問題。痛定思痛，我們決心對支付系統做一次架構升級。那么，怎么去做支付系統的架構升級呢?我們從兩個方面來進行架構升級梳理:
巨大的單體應用必須要拆分，在拆分之前，需要確定業務、系統邊界，并對支付業務進行建模。
構建完整的資金核算體系，以能夠清晰地知曉各類業務的流水、收入、支出等。
支付系統 2.0 - 拆分系統邊界
拆分單體應用之前，從三個維度對邊界進行拆分:
基于業務，拆分為面向支付業務和面向資金核算兩套體系。
基于場景，例如依據支付流程等進行拆分。
基于技術實現，例如出于對系統的性能等考慮拆分。?
我們將支付系統中的核心系統拆分為收銀臺、交易核心、支付核心、渠道網關、賬務系統、會計系統、清算系統、合規系統等。
如圖 14.4 所示的是核心支付鏈路流程示意圖。?
得益于蘑菇街強大的基礎平臺及中間件系統，比如 RPC 服務框架 Tesla、數據庫中間 件 Raptor、可靠的消息中間件 Corgi、數據庫事件變更中間件 Pigeon、數據配置推送平臺Metabase 及分布式緩存 KVStore 等，我們在 2015 年第四個季度對支付系統做了整體的服務化拆分，拆分后的架構如圖 14.5 所示。
下面大致介紹一下各系統的功能:
面向支付業務，可拆分為收銀臺、交易核心、支付核心、渠道網關。
面向資金核算，可拆分為會計系統、賬務系統、清算系統、合規系統。
其他基礎服務的拆分，比如支付會員服務、支付風控和對賬系統等。
支付系統 2.0詳解
以上講述了支付系統 2.0 的整體架構，接下來對各個核心系統的拆分和實現進行具體介紹。
2.1
交易核心
從剛才的支付鏈路中可以看出，交易核心作為支付系統入口，對接上層的業務系統。在 2015 年年底，支付系統有著數十張支付交易表，如何抽取合適的業務模型是最重要的事 情。另外，為了數據的統一性，我們對分散的數十張支付交易表進行了多表聚合，以及訂 單關聯。同時，支付的接入管控也放在了交易核心中實現，整體架構如圖 14.6 所示。
2.1.1
基礎交易類型抽象
在交易核心中做基礎交易類型的模型抽象，主要基于對支付的理解。如圖 14.7 所示， 電商交易的預售和廣告營銷的 CPC（Cost Per Click?的縮寫，每次點擊付費廣告）購買都是用戶直接購買并支付給收款方，那么我們可以將該行為抽象為即時交易，即從 a 用戶到 b 用戶的直接支付行為。
基于對業務的分析和理解，我們對交易核心的業務進行了抽象，抽象為 10 多種交易類型:
比較熟悉的交易類型:擔保交易、即時交易、充值、提現、擔保退款、即時退款、轉賬等。
不太常見的交易類型:提現退票、退款退單、異常退款、充值退款等。
2.1.2
多表聚合及訂單關聯
對數十張支付交易表進行多表聚合是基于一張主表來實現的。而在這種情況下，業務訂單如何保持唯一是我們需要考慮的事情。考慮到需要對上層業務保持極少的侵入性，在新設計的支付交易表中有專門的字段用于做唯一鍵約束:業務識別碼+業務訂單號。
另外，做一個小功能，使任何訂單都可以追溯到初始訂單，如圖 14.8 所示，擔保交易下的所有單子都可以找到，同時也能追溯到初始訂單。
2.1.3
支付管控
鑒于交易核心為支付平臺的入口，針對 1.x 支付系統中支付接入無授權問題，我們也在交易核心里面做了支付接入的管控 —— 授權和鑒權。
為任何一個接入支付的業務分配唯一的業務標識碼及授權的 Token。從而使得業務在支付接入時，需要帶上 Token 和加鹽過的加密數據。
2.2
支付核心
我們將 1.0 支付系統中的支付模塊切分為兩層——交易核心和支付核心。交易核心面向 上游業務，支付核心面向支付系統內部。
支付核心整體架構如圖14.9所示，
我們對支付核心同樣進行了支付類型的抽象:充值、提現、退款、轉賬，任何一個交易核心訂單請求都能由這 4 種基礎支付類型組合進而完成支付行為。
另外，支付核心需要基于系統、用戶指令等完成各種各樣的支付行為。按照簡單的做法，我們可以在不同的分支上實現各種支付行為，但是這樣可能會導致支付行為耦合，并使支付邏輯判斷變得復雜。基于這種原因，我們對支付工具進行組件化拆分，封裝為數十種支付工具，通過支付編排來執行支付行為。
2.2.1
支付編排
支付交易訂單通過支付規則生成具體的支付請求(即支付核心記錄)，支付請求通過支 付指令編排規則獲取一組支付工具包，通過支付執行器完成對支付工具的調用執行。
這樣的封裝使我們可以實現插件式開發，以及支付規則可配置化，繼而讓支付核心內 部的支付工具互不影響并系統地簡化。整個編排過程如圖 14.10 所示。
2.2.2
異常處理機制
支付核心有一個比較重要的功能，即如何對支付異常進行處理——支付過程中的重復支付、部分支付、金額不一致、全額退款等異常都需要做異常退款處理。
如圖 14.11 所示，以部分支付為例，我們做了一個異常管理組件來處理這種異常，在 “紅包支付+優惠券支付+網關支付”組合支付中對每次的支付都進行上報，通過異常管理組件對部分支付成功的行為進行反向異常退款。
2.3
渠道網關
我們對渠道網關系統進行拆分，渠道網關接受來自支付核心的支付請求，并與第三方支付進行交互。渠道網關同樣抽象了基礎服務類型:支付、退款、提現、簽約、查詢等。同時，出于性能方面的考慮，將網關系統切分為兩個子系統——網關核心和網關前置:
網關核心負責渠道路由、渠道訂單的管理及渠道分組。
網關前置負責渠道適配、報文轉換及外部通信。?
渠道網關系統的整體架構如圖 14.12 所示。
2.4
資金核算體系
資金核算體系主要由會計系統、賬務系統、清算系統和合規系統組成，整體架構如圖14.13 所示。
會計系統: 對業務運轉信息進行管理、核查、披露，展現資金的來龍去脈。
賬務系統: 由支付核心驅動，記錄管理賬戶信息，直接反映用戶的賬戶余額和資金變更明細。
清算系統: 由支付核心驅動，實現機構間資金關系應收應付的主被動清算及資金劃撥。
合規系統: 基于支付數據，向資金監管方同步交易信息流和資金流，從而契合央行的合規監管要求。
截至目前，我們對支付系統中面向業務的體系及資金核算體系進行了介紹。
統一平臺業務上下文
1.0 支付系統單體應用通過確定系統邊界、業務建模拆分之后，整個支付平臺被拆分為幾十個服務，那么如何保障業務信息在服務間流轉而不丟失是我們需要考慮的問題，就好比如何讓各個系統交互時都講普通話，而不是講方言。針對這個問題，我們在平臺中做了統一上下文的要素信息(唯一業務標識碼)，使其在整個支付平臺鏈路中全程傳遞，具體要素如下。
商戶: 諸如蘑菇街電商交易、美麗說電商交易等。
訂單類型: 基于交易核心的業務類型，諸如擔保交易、即時交易、轉賬、提現等。訂單場景: 諸如電商預售、營銷廣告購買等。
支付機構: 諸如支付寶、微信等。
通過統一平臺業務上下文，我們能夠在任何一個系統中清晰地看出是哪種業務，在哪種場景下，使用哪個渠道做了什么事情。
-?預知后事如何，且聽下回分解?-
精彩回顧
??手哥架構寶典系列：支付系統1.0架構演進
??牛逼的架構師是怎么煉成的？
??真.架構實踐寶典 - 一文囊括中國各大互聯網技術架構演進（收藏版）
??構建千億市值公司的架構師們新書《架構寶典》，你值得擁有
? ? ? ??
#專注技術人的成長#
《架構寶典》
出品：中生代技術社區
? ? ?
? ? ? 掃碼京東購? ? ? ? ? ? ? ? ? ? ? ? ? 掃碼其他平臺購
感謝為本書付出大力支持的李曉時、右軍、孔慶龍、李偉山、楊波、張逸、劉地生、田向陽、劉凡、王東、朱攀、朱永光、黃哲鏗、王輝、陳宗、陳顯銘、高磊、石濤生和曹洪偉；
點擊閱讀原文購買《架構寶典》，和本文作者陳宗 - 手哥老師一起學習架構
你每一個在看，我都超喜歡?
總結
以上是生活随笔為你收集整理的手哥架构宝典系列：支付系统2.0架构演进的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： UVA 10519 !! Really
- 下一篇： UVA 10910 Marks Dist