架構系列：蘑菇街的支付系統2.0架構演進

概述

在 1.0 的支付系統中，咱們遇到了諸多問題：

• 業務問題：隨着業務愈來愈複雜，咱們添加了愈來愈多的支付交易表，整個系統的架構是煙囪型架構，致使增長一個業務便增長 1~N 張表。並且業務的邊界很模糊，常常有業務出現這種狀況: 一半的業務邏輯實如今業務方，一半的業務邏輯實如今支付系統。
• 系統問題：整個支付系統都在一個巨大無比的單體 PHP 應用裏，模塊耦合性強，穩定性很是低，開發以及維護成本高。
• 資金問題：在第一代支付系統中，咱們對各個業務方的支付接入並未提供任何受權和鑑權，任何系統、任何團隊都有可能調用支付系統接口進行資金操做。支付有一個萬能的轉帳接口，對業務方接入來講確實很方便，但其實埋下了不少潛在的問題。雖然當 時對支付業務作了日誌記錄，可是在數據庫裏並未能區分業務來源和操做類型，致使咱們 對各項業務的流水、收入、支出難以統計和核算。

痛定思痛，咱們決心對支付系統作一次架構升級。那麼，怎麼去作支付系統的架構升級呢?咱們從兩個方面來進行架構升級梳理:

• 巨大的單體應用必需要拆分，在拆分以前，須要肯定業務、系統邊界，並對支付業務進行建模。
• 構建完整的資金覈算體系，以可以清晰地知曉各種業務的流水、收入、支出等。

支付系統 2.0 - 拆分系統邊界

拆分單體應用以前，從三個維度對邊界進行拆分:

• 基於業務，拆分爲面向支付業務和麪向資金覈算兩套體系。
• 基於場景，例如依據支付流程等進行拆分。
• 基於技術實現，例如出於對系統的性能等考慮拆分。

  將支付系統中的核心繫統拆分爲收銀臺、交易核心、支付核心、渠道網關、帳務系統、會計系統、清算系統、合規系統等。

如圖 14.4 所示的是核心支付鏈路流程示意圖。

得益於蘑菇街強大的基礎平臺及中間件系統，好比 RPC 服務框架 Tesla、數據庫中間 件 Raptor、可靠的消息中間件 Corgi、數據庫事件變動中間件 Pigeon、數據配置推送平臺Metabase 及分佈式緩存 KVStore 等，咱們在 2015 年第四個季度對支付系統作了總體的服務化拆分，拆分後的架構如圖 14.5 所示。

下面大體介紹一下各系統的功能:

• 面向支付業務，可拆分爲收銀臺、交易核心、支付核心、渠道網關。
• 面向資金覈算，可拆分爲會計系統、帳務系統、清算系統、合規系統。
• 其餘基礎服務的拆分，好比支付會員服務、支付風控和對帳系統等。 支付系統 2.0詳解

支付系統 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 所示。

• 會計系統: 對業務運轉信息進行管理、覈查、披露，展示資金的前因後果。
• 帳務系統: 由支付核心驅動，記錄管理帳戶信息，直接反映用戶的帳戶餘額和資金變動明細。
• 清算系統: 由支付核心驅動，實現機構間資金關係應收應付的主被動清算及資金劃撥。
• 合規系統: 基於支付數據，向資金監管方同步交易信息流和資金流，從而契合央行的合規監管要求。

截至目前，咱們對支付系統中面向業務的體系及資金覈算體系進行了介紹。

3.統一平臺業務上下文

  1.0 支付系統單體應用經過肯定系統邊界、業務建模拆分以後，整個支付平臺被拆分爲幾十個服務，那麼如何保障業務信息在服務間流轉而不丟失是咱們須要考慮的問題，就比如如何讓各個系統交互時都講普通話，而不是講方言。針對這個問題，咱們在平臺中作了統一上下文的要素信息(惟一業務標識碼)，使其在整個支付平臺鏈路中全程傳遞，具體要素以下。

• 商戶: 諸如蘑菇街電商交易、美麗說電商交易等。
  訂單類型: 基於交易核心的業務類型，諸如擔保交易、即時交易、轉帳、提現等。
  訂單場景: 諸如電商預售、營銷廣告購買等。
• 支付機構: 諸如支付寶、微信等。
  經過統一平臺業務上下文，咱們可以在任何一個系統中清晰地看出是哪一種業務，在哪一種場景下，使用哪一個渠道作了什麼事情。

最後可關注公衆號，一塊兒學習,天天會分享乾貨，還有學習視頻領取！

文章轉載：https://mp.weixin.qq.com/s/q_zgPvfmGNjG3MG4RsH_HA