一個細節翔實、可供參考的支付體系架構演進實例

作者｜陳宗

編輯｜小智

從單一功能到完整體系、從臃腫單體 Php 演變為高性能高可靠可伸縮的分散式服務架構，於 16 年快速融合美麗說和淘世界支付體系，並在歷年大促中保持無故障的出色表現，逐漸摸索出適應全集團複雜業務形態和變化的支付平台架構。具體是怎麼做的？

註：本文整理自美麗聯合集團資深工程師陳宗在 ArchSummit 深圳 2017 上的演講，原題為：《支付體系架構與實踐》。

上篇：支付體系架構演進

在過去 4 年的時間裡，作為面向億級用戶的大型時尚消費平台，美聯集團歷經著高速的業務增長和快速的業務演進。而其中最重要的基礎業務平台，美聯支付如何穩打穩紮、平滑演進，快速適應並高效支持著業務的複雜變化。我們從單一功能到完整體系、從臃腫單體 Php 演變為高性能高可靠可伸縮的分散式服務架構，於 16 年快速融合美麗說和淘世界支付體系，並在歷年大促中保持無故障的出色表現，逐漸摸索出適應全集團複雜業務形態和變化的支付平台架構。

支付系統 1.x

13 年下半年的時候，蘑菇街從導購平台轉為電商平台。為了支撐電商業務，我們快速實現了第一代的支付系統。當時蘑菇街的業務簡單、玩法單一。如圖 1.1 所示，第一代的支付系統只包含了支付最核心功能，從而儘快的支撐業務。在這期間，我們實現了面向業務的收銀台、支付模塊，面向資金端的賬務模塊，以及與三方支付對接的渠道網關。

1.x 支付系統架構

隨後的幾年，美聯的業務進入超高速的發展，電商交易、以及支付的業務複雜度劇增，玩法多變。同時，在經曆數次大促之後，我們發現，支付核心鏈路大促 QPS 峰值達到了日常的百倍以上。在這種情況下，我們其實遇到了蠻多的問題，以下分為三部分來說下我們當時碰到的問題：

業務問題

1.x 支付系統構建的時候，支付系統設定了比如擔保交易、提現等支付交易表。但是隨著業務越來越複雜，我們加了越來越多的支付交易表，整個系統的架構如同圖 1.2 所示的煙囪型架構。當時來一個業務，我們加 1-N 張表。

煙囪型系統機構

截止到 15 年底，整個支付系統存在這數十個支付交易表。這麼多的表，側面反映了我們對支付業務並沒有做模型的抽象，只是在業務的野蠻生長下，不斷的應對和接入。同時，在這種情況下，業務的邊界很模糊，經常有業務，一半的業務邏輯實現在業務方，一半的業務邏輯在支付方。

系統問題

當時我們整一個支付系統都在一個巨大無比的單體 php 應用里。雖然系統在演進，也分出了不少的模塊，但是大家知道。在一個巨大的單體應用里，比較容易出現各模塊的耦合，比如支付模塊調用了渠道網關模塊的一個內部的方法等等。而另外一個，支付團隊的幾十號同學每天都在一個應用裡面開發 & 發布。任何一個地方跪了，都有可能讓支付系統崩潰，穩定性非常低。

最後，電商平台的特性，決定了我們必須要不斷的提升支付系統的性能。在 15 年的時候，我們對支付系統的 DB 進行了基於模塊的垂直拆分，如下圖所示。以用於提升系統容量。但這種情況下，我們還是碰到到性能瓶頸。

舉個例子：15 年雙十一，當時定下來系統能夠支持 2kqps 的峰值支付性能。但在數輪鏈路壓測之後，即時我們對 DB 進行了垂直拆分，並用了最好硬體 fushion IO, 但是我們發現系統僅能支撐大概 1800qps 左右的支付。當時其實是比較絕望的，我清楚的記得在 15 年的 10 月底，11 月初的很多白天黑夜，緊急對支付系統的擔保交易下單進行了改造，添加了一系列的緩存，最終性能勉強能夠達標。

支付系統 DB 垂直拆分

資金問題

第一代的支付系統中，我們對各個業務方的支付接入，並未提供任何的授權和鑒權。也就是說任何系統、任何團隊都有可能調用支付系統介面進行資金操作，當時支付有一個萬能的轉賬介面，業務方接入確實很方便，但其實埋了蠻多坑。雖然當時我們支付的業務做了日誌記錄，但是在資料庫裡面，我們並未能區分來源的業務、哪種操作，導致了我們對各項業務的流水、收入、支出難以統計和核算。

另外我們當時也碰到了數據一致性挑戰。當時支付系統僅有內外部渠道對賬，而對內部的業務數據，並沒有做好對賬事宜，經常出現用戶反饋異常問題，然後我們才能知曉。

支付體系 2.0 架構實踐

1.x 的支付系統中，其實我們碰到了很多的問題，痛定思痛，我們決心對支付體系做一次架構升級。那麼，怎麼去做支付體系的架構升級呢？，我們從兩個方面來進行架構升級梳理：

巨大的單體應用必須得拆分，在拆分之前，我們需要確定業務、系統邊界，對支付業務進行建模。

構建完整的資金核算體系，以達到能夠清晰的知曉各類業務的流水、收入、支出等。

拆分系統邊界

那麼單體應用拆分之前，那麼如何確定邊界? 從三個維度對邊界進行了拆分：

基於業務，拆分為面向支付業務，面向資金核算體系

基於場景，例如依據支付流程等

基於技術實現，比如出於對系統的性能考慮等

我們對支付體系裡面的核心系統拆分為：收銀台、交易核心、支付核心、網關、賬務、會計、清算、合規等。下圖是對核心支付鏈路流程示意：

核心支付鏈路流程

支付體系 2.0 整體架構

得益於蘑菇街強大的基礎平台 & 中間件系統，比如 RPC 服務框架 Tesla，資料庫中間件 Raptor，可靠的消息中間件 Corgi，資料庫事件變更中間件 Pigeon，數據配置推送平台 metabase，分散式緩存 kvstore 等等。我們在 15 年第四季度，對支付系統做了整體的服務化拆分。大家可以看下圖支付體系 2.0 的整體架構圖：

支付體系 2.0 整體架構圖

如圖所示，我們大致介紹下各系統的功能：

面向支付業務拆分為：收銀台、交易核心、支付核心、渠道網關

面向資金核算拆分為：賬務、會計、清算、合規

其他基礎服務，比如支付會員服務，支付風控和支付對賬等。

支付體系 2.0 系統拆分

上文中呈現了支付體系 2.0 的整體架構，我們接下來對各核心系統的拆分和實現進行介紹：

交易核心

從剛才的支付鏈路可以看出，交易核心作為支付系統入口，對接上層的業務系統。在 15 年底，支付系統有著數十張的支付交易表，如何抽取合適業務模型，是我們最重要的事情。另外，為了數據的統一性，我們對分散數十張的支付交易表進行了多表聚合，以及訂單關聯。同時，支付的接入管控也放在了交易核心實現，整體的架構如下圖所示：

交易核心架構圖

基礎交易類型抽象

交易核心裏面如何做基礎交易類型的模型抽象？主要還是基於對支付的理解，如圖 2.4 所示的例子中，電商交易的預售 和 廣告營銷的購買，都是從用戶購買直接到收款方。那麼我們可以抽象為即時交易，即直接從 a 用戶到 b 用戶的支付行為。

基礎交易類型抽象

基於對業務的分析理解，我們對交易核心的業務進行了抽象，抽象為 10 多種交易類型：

大家比較熟悉的：擔保交易、即時交易、充值、提現、擔保退款、即時退款、轉賬等。

以及不太常見的：提現退票、退款退單、異常退款、充值退款等。

多表聚合 & 訂單關聯

我們對數十張的支付交易表進行多表聚合，是基於一張主表來實現。而在這種情況下，業務訂單如何保持唯一是我們需要考慮的事情。考慮到需要對上層業務的極少侵入性，在新設計的支付交易表中，有專門的欄位用於做唯一鍵約束：

業務識別碼 + 業務訂單號 來進行訂單唯一約束。

另外，做了一個小功能，任何訂單都可以追溯到初始單，如下圖為例，擔保交易下的所有的單子都可以找到，同時也能追溯到初始的訂單。

擔保交易訂單關聯

支付管控

鑒於交易核心為支付平台的入口，針對 1.x 支付系統中支付接入無授權問題，我們也在交易核心裏面做了支付接入的管控，授權 & 鑒權。為任何一個接入支付的業務分配唯一的業務標識碼 & 授權的 token。從而使得業務在支付接入時，須帶上 token & 加鹽過的加密數據傳入。

支付核心

我們將 1.x 支付系統裡面的支付模塊，切分兩層，交易核心 & 支付核心。交易核心面向上游業務，支付核心面向支付系統內部。

支付核心整體架構如圖 2.6，我們對支付核心同樣進行了支付類型的抽象：充值、提現、退款、轉賬四類，任何一個交易核心訂單請求，都能被四種基礎支付類型組合進而完成支付行為。另外，支付核心需要基於系統、用戶指令等完成各種各樣的支付行為。按照簡單的做法，我們可以在不同的分支上實現各式的支付行為，但是這樣可能會導致支付行為的耦合，以及支付的複雜邏輯判斷。基於這種原因，我們對支付工具進行組件化拆分，封裝為數十種支付工具，通過支付編排來執行支付行為。

支付核心架構圖

支付行為編排

支付交易訂單通過支付規則生成具體的支付請求（即支付核心記錄），支付請求通過支付指令編排規則，獲取一組支付工具包。通過支付執行器完成對支付工具的調用執行。這樣的封裝，我們可以實現插件式開發，以及可支付規則可配置化，繼而讓支付核心內部的支付工具互不影響 & 系統簡化。整個編排過程如下圖所示：

支付行為編排

異常處理機制

支付核心有一個比較重要的功能，是如何對支付異常進行處理，支付過程比如重複支付、部分支付、金額不一致、其他異常全額退款等等異常，都需要做異常的退款。

如圖 2.8 以部分支付為例，我們做了一個異常管理組件來處理這種異常，在網關支付 + 紅包 + 優惠券組合支付中，對每次的支付都進行上報。紅包支付、優惠券支付，都成功上報，而對於網關支付異常時，也做異常上報機制。通過異常管理組件對部分支付成功的行為進行反向異常退款。

部分支付異常退款

渠道網關

我們對渠道網關係統進行拆分，渠道網關接受來自支付核心的支付請求，與三方支付進行交互。

網關係統同樣抽象了基礎服務類型：支付、退款、提現、簽約、查詢等。同時，為了性能考慮，網關係統切分為兩個子系統，網關核心 & 網關前置：

網關核心負責渠道路由、渠道訂單的管理、以及渠道的分組。

網關前置負責渠道適配、報文轉換、以及外部通訊。

整體架構如下圖所示

渠道網關整體架構圖

資金核算體系

資金核算體系主要由賬務系統、會計系統、清算系統 和合規系統組成，整體架構如下圖所示：

支付核算體系

賬務系統：由支付核心驅動，記錄管理賬戶信息，直接反應用戶的賬戶餘額和資金變更明細。

會計系統：對業務運轉信息進行管理、核查、披露。 展現資金的來龍去脈。

清算系統：由支付核心驅動，實現機構間資金關係應收應付的主被動清算以及資金劃撥。

合規系統：基於支付數據，向資金監管方同步交易信息流 & 資金流，從而契合央行合規監管要求。

截止目前，我們對支付體系的面向業務的系統 & 資金核算體系進行了介紹。

統一平台業務上下文

1.x 支付系統單體應用通過確定系統邊界、業務建模拆分之後，整個支付平台被拆分幾十個服務，而如何保障在服務間流轉業務信息不被丟失，是我們需要考慮的問題。就好比如何讓各個系統交互時都講普通話，而不是講方言。針對這個問題，我們做了平台統一上下文的要素信息（唯一業務標識碼），在整個支付平台鏈路中全程傳遞，具體要素如下：

商戶：諸如 mgj 交易 & mls 交易等。

訂單類型：基於交易核心的業務類型，諸如擔保交易、即時交易、轉賬、提現等

訂單場景：諸如電商預售、營銷廣告購買等

支付機構：諸如支付寶、微信等

通過統一平台業務上下文，我們能夠在任何一個系統裡面清晰看出是哪種業務，在哪種場景下，使用哪個渠道做了什麼事情。

直面數據一致性挑戰

在單體應用服務拆分之後，我們碰到了更加嚴峻的數據一致性挑戰，系統間交互異常、無分散式事務的情況下，數據不一致的情況出現的概率還是非常大。

那麼我們是如何解決數據一致性問題的？總結下來有三個方面：

CAS

在整個支付平台中，我們對可能有並發衝突的系統做了 CAS 樂觀鎖 ，以交易核心、支付核心為例，通過狀態的 CAS 樂觀鎖防止並發，如下所示：

update PayOrder set status= complete where id=1 and status= process

同時，也做了基於 KVstore 的分散式緩存鎖來防止多數據之間的並發問題，例如解決重複支付問題等。

介面冪等 & 異常補償

我們要求整個支付體系中的所有服務，涉及數據變更的介面都要求保持介面冪等。通過全鏈路的冪等，使得重試成為了可能。

在諸如服務超時、網路異常的情況下，我們做了兩種不同的異常補償：基於消息中間件 Corgi 的准實時補償 & 基於異常表的補償。

以支付回調鏈路為例，如下圖所示，渠道網關和支付核心之間的交互，使用的兩者補償的方式。交易核心 對電商交易的支付成功通知方式，我們使用異常表的補償，在 12 小時內遞衰的通知 10 次等等。

支付回調補償機制

完整對賬體系

在支付體系中，對賬是數據一致性的最後一道防護。對賬可分為兩部分：

內外對賬，是 1.x 支付系統上線之後已經實現該功能。確保美麗聯合集團支付數據與三方支付的數據保持一致。

內部業務對賬，在 2.0 支付體系構建過程中，我們做了一套內部業務准實時對賬系統，用於核對整個平台數據。

下面對內部准實時做簡單的介紹：

內部准實時對賬

如下圖所示，准實時對賬平台支持各種數據源的接入，目前基於系統解耦的考慮，我們更多的使用資料庫事件變更中間件 Pigeon 來接入對賬雙方的 binlog 數據，通過配置的規則 或者自定義的轉換邏輯來進行雙方的模型轉換，從而通過對賬核心進行數據的核對。目前通過該系統，我們可以在 5-25min 之內，發現異常數據。目前支付核心鏈路全部接入，支付全平台 95% 以上。同時由於對賬系統的普適性，目前已經推廣至公司所有業務。

准實時對賬平台架構圖

基於上述的這些手段，我們能夠保障支付系統數據的最終一致性。

療效？

那麼通過對支付體系的升級架構，我們取得了哪些成果？

快速支撐業務。之前在接入新的業務的時候，大概率需要新增交易表以及開發上線。目前在升級之後，我們基本上只需要進行接入配置即可。

16 年快速融合淘世界、美麗說支付系統。在融合的過程中，新版的支付系統能夠兼容當時的淘世界 & 美麗說支付系統，順利的完成了融合。

基於業務接入授權管控 以及平台統一上下文，我們能夠對業務進行細分，從而能夠對各業務的資金情況進行細分和準確的核實。

通過合規系統的實現，符合央行的資金監管要求，為用戶、商戶提供了強有力的資金安全保障。

總結展望

通過對業務的梳理、系統邊界的拆分、業務建模等手段，我們完成了對支付體系 2.0 架構升級，進而能夠對業務提供更加高效、穩定、專業的支撐。進一步的提升了資金的核算 & 管控能力。但是目前的支付平台里，每個子系統中，或多或少的都存在著自己的配置系統，雖然是基於公用的統一的平台業務上下文，但是配置還是繁瑣。如何做到統一化配置也是我們後續考慮的重點。同時，目前平台業務統一上下文的四要素是基於交易核心出發，從目前的系統演化來看，我們需要繼續改進為更優化的模型，以應對後續更加複雜的各類業務。

下篇：容量提升

在對美聯支付系統升級到支付體系 2.0 之後（支付體系架構演進）。那麼我們針對電商平台特性，比如大促時支付鏈路峰值為日常的百倍以上等等特性，又做了哪些性能和穩定的提升？

下面我們以支付核心鏈路為例，談談如何提升支付平台的性能和穩定性。

支付核心鏈路

性能提升

針對於電商特性，我們對支付平台的性能提升主要是從以下幾個方面優化：

核心鏈路分庫分表：全鏈路水平擴展

服務調用非同步化

熱點賬戶問題優化

事務切分

核心鏈路分庫分表：全鏈路水平擴展

目前所有的應用服務都是無狀態，理論上應用服務可以做到無限擴展，目前最大的瓶頸是在 DB。性能容量的提升，關鍵在於 DB 的容量。基於這個原因，我們對整個平台的 DB 做了水平的拆分。

在全平台水平擴展的過程中，我們以核心鏈路為例，從交易核心、支付核心、賬務核心、渠道網關等系統全部做了資料庫的水平拆分。基於交易核心、支付核心、渠道網關等系統，前面介紹過，我們抽象了各種基礎模型，數據都是基於一張主表存儲，因此水平拆分基於該主表即可。

得益於美聯自研的資料庫中間件 Raptor，我們實現鏈路的分庫分表。同時，也基於全局統一的 sequence 生成器，保持了所有分片內的主鍵 id 唯一性。

支付核心鏈路分庫分表

服務調用非同步化

支付體系 2.0 升級之後，單體應用拆分為數十個服務。系統的拆分和服務化，其實帶來了更多的系統依賴。相對於之前的單體應用，從方法級的調用方式變更為 RPC 服務調用，網路耗時 & 同時網路的穩定性等因素也是需要考慮的問題。基於這些考慮，非強實時的服務調用，非同步化是最佳的解耦方式。同樣，在核心鏈路里，我們也做了各種各樣的非同步化優化，進而提升整體的鏈路性能，滿足電商平台獨有的性能特性要求。

我們從幾個點來看下如何對支付系統做非同步處理：

支付消息報

基於資料庫事件中間件 Pigeon & 消息隊列 Corgi，我們實現支付消息報。如圖 1.2 所示，支付消息報基於交易核心數據，聚合支付核心的支付數據，最終生成支付消息報。通過這種方式，將原本需要在交易核心或者支付核心調用下游業務方，或者下游業務方實時查詢的方式，轉變為下游業務方通過接受消息的推送來獲取數據，從而達到了業務的解耦。同時，也簡化了業務方的數據獲取複雜度。

支付消息報架構圖

目前支付消息報已經接入了 10 多個業務場景，例如滿返，支付成功簡訊通知，風控所需的支付數據等等，並在持續不斷的增加中。

外部支付非同步化

在外部支付中，經常會碰到這種情況，需要服務方與第三方支付交互，獲取預支付憑證，如圖 1.3 所示。這種同步調用的情況下，由於需要跨外部網路，響應的 RT 會非常長，可能會出現跨秒的情況。由於是同步調用，會阻塞整個支付鏈路。一旦 RT 很長且 QPS 比較大的情況下，服務會整體 hold 住，甚至會出現拒絕服務的情況。

同步調用三方支付

基於這個問題，我們對這種獲取預支付憑證的方式進行了改進，詳見下圖：

非同步調用三方支付

通過獨立網關渠道前置服務，將獲取的方式分為兩個步驟：

針對支付鏈路，只是請求到渠道前置拿到內部的支付憑證就結束了。

針對外部請求，由渠道前置非同步向三方支付發起請求。

那麼基於這種方式，與三方支付的同步交互僅僅會阻塞渠道前置。密集型的 io & 低 cpu 系統，渠道前置的並發值可以設置的非常大。

非同步並行

支付平台服務化之後，核心鏈路上的服務多為 IO 密集型，這裡我們以收銀台渲染為例，見下圖。

串列模式下的收銀台渲染

一次收銀台渲染，串列的調用各個服務來進行用戶信息查詢 (RT T1)、額度查詢 (RT T2)、優惠查詢 (RT T3)，最終執行渠道渲染 (RT T4)，這種實現方式下

收銀台的渲染 RT = sum(T1,T2,T3,T4)

但是收銀台的渲染 RT 必須要這麼久嗎？其實對於業務的分析，我們發現其實很多的服務調用無先後順序。用戶信息查詢、額度查詢、優惠查詢這三個服務的調用其實無先後順序，那麼我們基於 Tesla 服務框架的非同步化服務調用，見下圖。

非同步並行模式下的收銀台渲染

基於非同步並行的收銀台渲染方式，將並行過程中的各服務化的耗時之和變更為耗時最長的一個服務的 RT。

收銀台渲染 RT =sum(max(T1,T2,T3),T4)

資金核算體系非同步化

目前支付平台里，資金核算體系各個子系統：會計系統數據來源於賬務系統，賬務 、清算 、合規數據來源於支付核心。那麼，需要在支付核心鏈路執行的時候同步調用賬務 & 清算 & 合規，賬務實時調用會計嗎？其實基於對資金業務的分析，會計、清算、合規屬於非強實時業務，可以通過數據變更中間件 Pigeon 同步數據，對這三個系統進行了解耦，如圖：

資金核算體系非同步化架構

清算、合規通過監聽支付核心 DB 數據變更來獲取數據，會計通過監聽賬務的流水庫的數據變更來獲取數據，從而對實時鏈路非強實時業務進行解耦。

熱點賬戶問題優化

熱點賬戶應該是每一個做支付的童鞋都會碰到的問題。美聯的支付系統里，存在這各種各樣的熱點賬戶，我們將之分為三類：

內部戶：比如渠道的待清分賬號等

平台戶：比如各種平台的營銷的墊支戶等

大商家的熱點賬戶等。

每種熱點賬戶的業務屬性都不一樣，比如商家賬戶，我們不能延遲記賬等等。基於這些情況，我們對熱點賬戶問題優化也基於類型：

內部戶

針對於內部戶，我們在賬務中不做內部戶這邊的記賬，而是由會計通過另外一邊的賬務流水去補分錄。

平台戶

針對於平台戶，在賬務中做了非同步記賬，通過定時匯總記賬即可。

大商家

比較難的是大商家的熱點問題，特別是在美聯這種沒有商家結算周期的情況下，每一筆的訂單狀態變更，都有可能涉及商家的賬戶資金變更。但是也有解決辦法。分析其業務場景，擔保入賬、擔保出賬 、傭金扣費等佔用了絕大多數的商家賬戶操作。針對這塊我們分為兩個點來做優化：

將商家擔保賬戶切換到平台擔保戶，基於流水去統計商家擔保中的金額。這種情況下，擔保入賬和出賬的商家熱點問題可以解決。

第一點的優化能夠解決擔保出入賬的賬務操作，但是扣費依舊會造成大量的熱點賬戶問題，對此我們做了一個排序的任務，將扣費做到做到單商家串列 & 多商家並行。

基於上述的兩個優化方案，我們解決了大商家熱點賬戶問題。

通過對三種類型的熱點賬戶優化進行，能夠解決目前系統碰到的熱點賬戶問題。但是各種平台戶的賬務流水會非常多，以擔保戶為例，每日的所有的出入擔保戶的流水，都會在這個賬戶之上，那麼在分庫分表情況下，會出現平台戶所在的單表巨大無比。在這裡我們引入二級子賬戶概念，將內部戶 & 平台戶在賬務虛化成 N 個二級子賬戶，從而均勻的分散在各個分表裡，進而解決了該問題。

賬務記賬事務切分

在支付核心鏈路里，我們對非強實時依賴的服務做了非同步化的解耦，對熱點賬戶進行了優化的處理。在賬務記賬的時候，我們從下面兩個問題考慮優化點：

在賬務分庫分表的情況下，如何保證記賬是在事務里？

每次記賬的出賬 & 入賬是否可拆分？

基於這兩個問題，我們對記賬流程進行了事務的拆分，如圖所示：

賬務記賬事務拆分

出賬、入賬分離。出賬成功，則整體成功，入賬失敗可以非同步補賬。

出賬 & 入賬 ，每個裡面都做單邊賬、非同步記賬等處理，整個支付核心鏈路唯一的一個事務就在於更新賬務餘額 & 新增流水。

目前系統中，經過這一系列的優化，單次的記賬性能，基本上穩定在 15ms 左右。

穩定性提升

在上文中，我們主要針對於支付鏈路的性能做了各種各樣的性能提升。資金無小事，如何保證支付平台的穩定性，也是我們需要考慮的重點。我們從下面幾個維度來提升穩定性。

監控先行

做穩定性之前，我們需要知道我們的系統運行情況，那麼必須要做線上系統的監控，對關鍵指標進行管控，以支付核心鏈路為例，如圖：

核心鏈路監控

如圖所示，我們監控了核心鏈路的 qps、rt、並發量等，同時也基於支付核心，我們對依賴的服務 qps、rt 進行監控。另外，也對依賴的 DB & Cache 進行監控。

通過在監控大盤中配置關鍵指標，能夠比較清晰明了的看出目前核心鏈路線上運行情況。

分離核心鏈路

基於電商特性，我們對整個核心鏈路進行了剝離，如圖所示：

分離核心鏈路

對核心鏈路分離的過程中，我們對鏈路中的各個服務中切分為核心 & 通用服務。分離的做法其實有很多，比如基於 Tesla 服務框架提供的服務分組功能；比如將一個服務切分為兩個服務：核心鏈路服務和通用查詢服務。

在核心鏈路分離之後，能夠確保在任何時候，核心鏈路不會受到其他通用業務的影響而導致出現穩定性問題。

服務依賴梳理

目前在支付系統里，有著數十個服務，如果不對服務依賴進行梳理，系統穩定性會得不到保障。我們從下面幾點來梳理服務依賴：

梳理平台中的強弱依賴，判定哪些是強依賴，哪些是弱依賴。

弱依賴做好降級和超時保護，比如收銀台渲染是的白付美額度查詢，這種可以埋降級開關 & 設置較短的超時時間。因為查不到額度，最多不能使用白付美支付，並不會有特別大的影響。

如果是強依賴，這個不能降級，怎麼辦？需要對強依賴的服務提出服務的 SLA 治理，比如賬務記賬功能，我們會要求系統不能掛、rt 不能超過 20ms，qps 需要支撐 8k qps 等等，基於這個約定，做子服務的優化。

降級、限流

限流是保護系統不掛的最後一道防線。

目前支付平台裡面，存在基於 RPC 服務框架 tesla 的粗粒度限流，可控制在服務級別和方法級別；基於 spirit 的細粒度限流降級系統，我們可以在單個方法裡面做限流降級功能個，如下圖所示，我們在擔保交易下單過程中，區分平台來源，做到蘑菇街擔保交易流量 & 美麗說擔保交易流量。

spirit 限流模式

但是不得不說，單單的 qps 或者並發限流都不能完全的做好限流保護，需要兩者的相結合才能達到所需的效果。

另外一點，通過對服務的依賴梳理，我們在各種弱依賴的服務中埋了一些降級開關。通過自研的降級推送平台，一旦依賴服務出現問題或者不可用，可以快速的對該服務進行降級操作。

壓測怎麼做？

在對系統擴容，鏈路性能優化之後，怎麼檢測成果呢？

我們引入線上壓測系統，通過分析業務場景，構建與線上真實場景幾乎一致的測試模型。以支付鏈路為例，模型中以日常 & 大促的流量模型為基準，設計壓測模型。需要注意的是，壓測模型越與真實一致，壓測的效果越好，對系統把控越準確。。

通過構建線上數據影子庫，壓測產生的測試數據，會全量寫入到影子庫中。通過影子庫，在復用線上正式業務一致的環境、部署、機器資源下，我們能夠做到壓測對正常業務無侵入，對系統做準確的把脈。

線上業務也分為兩塊，一塊是單機性能壓測，主要是分析單機的性能水位和各項指標。另外是鏈路壓測，主要驗證系統的穩定性和服務短板。

通過壓測的結果，我們能夠對支付平台的性能 & 穩定性短板的分析和加以改進，能夠不斷的提升系統的穩定性，提升系統的容量。

療效？

那麼，通過一系列的性能容量的提升，我們達到了什麼效果？

平台容量方面：在 16 年雙十一的大促壓測中，我們在鏈路 DB 都擴圍兩組的物理的機器情況下，支付穩定在 3000QPS。由於目前沒有需求，我們未對 DB 的物理機器擴到極限，因此系統的極限性能不能完全確定，但是按照預估，理論上可支持 1w QPS 以上。

機器利用率上：相同的容量情況下，我們的應用減少為原有的 1/3。

鏈路的性能上：如圖 4.1 所示，以擔保交易為例，交易核心的收單 rt 幾乎在 10ms，而收銀台渲染在 50ms，支付請求在 50ms，支付回調在 80ms 左右。

核心鏈路服務性能

同時，基於性能和穩定性的提升，我們做到了支付在歷次的大促中，保持無故障的記錄。

總結展望

在美聯支付系統中，上層支付業務面向電商平台，針對電商特色做更多的業務支持。我們對平台的性能容量尋找可改進的地方，比如 DB、Cache、IO、以及非同步化，持續不斷去優化。另外，資金無小事，如何提升支付系統的穩定性也是重點考慮的方向。

作者介紹

陳宗，花名鐵手，14 年加入蘑菇街。參與美聯支付技術歷次重大優化與演進，主導支付體系中交易和支付系統的平台化架構，並持續鑽研和改進具有電商特色的支付平台。目前在支付團隊負責支付基礎平台架構和研發工作。

互聯網講求唯快不破，飛速的業務發展對服務架構提出更高的要求，業務需要強大的服務架構來支持更加複雜、量級更大的業務。QCon 上海 2017全新開啟，更多企業架構實踐案例，敬請關注。

今日薦文

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！