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

注：本文整理自美麗聯合集團資深工程師陳宗在 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 的支付系統中，其實咱們碰到了不少的問題，痛定思痛，咱們決心對支付體系作一次架構升級。那麼，怎麼去作支付體系的架構升級呢？，咱們從兩個方面來進行架構升級梳理：

1. 巨大的單體應用必須得拆分，在拆分以前，咱們須要肯定業務、系統邊界，對支付業務進行建模。

2. 構建完整的資金覈算體系，以達到可以清晰的知曉各種業務的流水、收入、支出等。

拆分系統邊界

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

1. 基於業務，拆分爲面向支付業務，面向資金覈算體系

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

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

咱們對支付體系裏面的核心繫統拆分爲：收銀臺、交易核心、支付核心、網關、帳務、會計、清算、合規等。下圖是對核心支付鏈路流程示意：

核心支付鏈路流程

支付體系 2.0 總體架構

得益於蘑菇街強大的基礎平臺 & 中間件系統，好比 RPC 服務框架 Tesla，數據庫中間件 Raptor，可靠的消息中間件 Corgi，數據庫事件變動中間件 Pigeon，數據配置推送平臺 metabase，分佈式緩存 kvstore 等等。咱們在 15 年第四季度，對支付系統作了總體的服務化拆分。你們能夠看下圖支付體系 2.0 的總體架構圖：

支付體系 2.0 總體架構圖

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

1. 面向支付業務拆分爲：收銀臺、交易核心、支付核心、渠道網關

2. 面向資金覈算拆分爲：帳務、會計、清算、合規

3. 其餘基礎服務，好比支付會員服務，支付風控和支付對帳等。

支付體系 2.0 系統拆分

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

 交易核心

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

交易核心架構圖

基礎交易類型抽象

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

基礎交易類型抽象

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

• 你們比較熟悉的：擔保交易、即時交易、充值、提現、擔保退款、即時退款、轉帳等。

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

多表聚合 & 訂單關聯

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

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

另外，作了一個小功能，任何訂單均可以追溯到初始單，以下圖爲例，擔保交易下的全部的單子均可以找到，同時也能追溯到初始的訂單。

擔保交易訂單關聯

支付管控

鑑於交易核心爲支付平臺的入口，針對 1.x 支付系統中支付接入無受權問題，咱們也在交易核內心面作了支付接入的管控，受權 & 鑑權。爲任何一個接入支付的業務分配惟一的業務標識碼 & 受權的 token。從而使得業務在支付接入時，須帶上 token & 加鹽過的加密數據傳入。

 支付核心

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

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

支付核心架構圖

支付行爲編排

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

支付行爲編排

異常處理機制

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

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

部分支付異常退款

 渠道網關

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

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

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

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

總體架構以下圖所示

渠道網關總體架構圖

 資金覈算體系

資金覈算體系主要由帳務系統、會計系統、清算系統 和合規系統組成，總體架構以下圖所示：

支付覈算體系

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

• 會計系統：對業務運轉信息進行管理、覈查、披露。 展示資金的前因後果。

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

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

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

統一平臺業務上下文

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

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

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

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

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

經過統一平臺業務上下文，咱們可以在任何一個系統裏面清晰看出是哪一種業務，在哪一種場景下，使用哪一個渠道作了什麼事情。

直面數據一致性挑戰

在單體應用服務拆分以後，咱們碰到了更加嚴峻的數據一致性挑戰，系統間交互異常、無分佈式事務的狀況下，數據不一致的狀況出現的機率仍是很是大。

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

 CAS

在整個支付平臺中，咱們對可能有併發衝突的系統作了 CAS 樂觀鎖 ，以交易核心、支付核心爲例，經過狀態的 CAS 樂觀鎖防止併發，以下所示：

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

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

 接口冪等 & 異常補償

咱們要求整個支付體系中的全部服務，涉及數據變動的接口都要求保持接口冪等。經過全鏈路的冪等，使得重試成爲了可能。

在諸如服務超時、網絡異常的狀況下，咱們作了兩種不一樣的異常補償：基於消息中間件 Corgi 的準實時補償 & 基於異常表的補償。

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

支付回調補償機制

 完整對帳體系

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

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

2. 內部業務對帳，在 2.0 支付體系構建過程當中，咱們作了一套內部業務準實時對帳系統，用於覈對整個平臺數據。

下面對內部準實時作簡單的介紹：

內部準實時對帳

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

準實時對帳平臺架構圖

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

療效？

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

1. 快速支撐業務。以前在接入新的業務的時候，大機率須要新增交易表以及開發上線。目前在升級以後，咱們基本上只須要進行接入配置便可。

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

3. 基於業務接入受權管控 以及平臺統一上下文，咱們可以對業務進行細分，從而可以對各業務的資金狀況進行細分和準確的核實。

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

總結展望

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

下篇：容量提高

在對美聯支付系統升級到支付體系 2.0 以後（支付體系架構演進）。那麼咱們針對電商平臺特性，好比大促時支付鏈路峯值爲平常的百倍以上等等特性，又作了哪些性能和穩定的提高？

下面咱們以支付核心鏈路爲例，談談如何提高支付平臺的性能和穩定性。

支付核心鏈路

性能提高

針對於電商特性，咱們對支付平臺的性能提高主要是從如下幾個方面優化：

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

• 服務調用異步化

• 熱點帳戶問題優化

• 事務切分

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

目前全部的應用服務都是無狀態，理論上應用服務能夠作到無限擴展，目前最大的瓶頸是在 DB。性能容量的提高，關鍵在於 DB 的容量。基於這個緣由，咱們對整個平臺的 DB 作了水平的拆分。

在全平臺水平擴展的過程當中，咱們以核心鏈路爲例，從交易核心、支付核心、帳務核心、渠道網關等系統所有作了數據庫的水平拆分。基於交易核心、支付核心、渠道網關等系統，前面介紹過，咱們抽象了各類基礎模型，數據都是基於一張主表存儲，所以水平拆分基於該主表便可。

得益於美聯自研的數據庫中間件 Raptor，咱們實現鏈路的分庫分表。同時，也基於全局統一的 sequence 生成器，保持了全部分片內的主鍵 id 惟一性。

支付核心鏈路分庫分表

服務調用異步化

支付體系 2.0 升級以後，單體應用拆分爲數十個服務。系統的拆分和服務化，其實帶來了更多的系統依賴。相對於以前的單體應用，從方法級的調用方式變動爲 RPC 服務調用，網絡耗時 & 同時網絡的穩定性等因素也是須要考慮的問題。基於這些考慮，非強實時的服務調用，異步化是最佳的解耦方式。一樣，在覈心鏈路裏，咱們也作了各類各樣的異步化優化，進而提高總體的鏈路性能，知足電商平臺獨有的性能特性要求。

咱們從幾個點來看下如何對支付系統作異步處理：

 支付消息報

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

支付消息報架構圖

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

 外部支付異步化

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

同步調用三方支付

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

異步調用三方支付

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

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

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

那麼基於這種方式，與三方支付的同步交互僅僅會阻塞渠道前置。密集型的 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 數據變動來獲取數據，會計經過監聽帳務的流水庫的數據變動來獲取數據，從而對實時鏈路非強實時業務進行解耦。

熱點帳戶問題優化

熱點帳戶應該是每個作支付的童鞋都會碰到的問題。美聯的支付系統裏，存在這各類各樣的熱點帳戶，咱們將之分爲三類：

1. 內部戶：好比渠道的待清分帳號等

2. 平臺戶：好比各類平臺的營銷的墊支戶等

3. 大商家的熱點帳戶等。

每種熱點帳戶的業務屬性都不同，好比商家帳戶，咱們不能延遲記帳等等。基於這些狀況，咱們對熱點帳戶問題優化也基於類型：

內部戶

針對於內部戶，咱們在帳務中不作內部戶這邊的記帳，而是由會計經過另一邊的帳務流水去補分錄。

平臺戶

針對於平臺戶，在帳務中作了異步記帳，經過定時彙總記帳便可。

大商家

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

1. 將商家擔保帳戶切換到平臺擔保戶，基於流水去統計商家擔保中的金額。這種狀況下，擔保入帳和出帳的商家熱點問題能夠解決。

2. 第一點的優化可以解決擔保出入帳的帳務操做，可是扣費依舊會形成大量的熱點帳戶問題，對此咱們作了一個排序的任務，將扣費作到作到單商家串行 & 多商家並行。

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

經過對三種類型的熱點帳戶優化進行，可以解決目前系統碰到的熱點帳戶問題。可是各類平臺戶的帳務流水會很是多，以擔保戶爲例，每日的全部的出入擔保戶的流水，都會在這個帳戶之上，那麼在分庫分表狀況下，會出現平臺戶所在的單表巨大無比。在這裏咱們引入二級子帳戶概念，將內部戶 & 平臺戶在帳務虛化成 N 個二級子帳戶，從而均勻的分散在各個分表裏，進而解決了該問題。

帳務記帳事務切分

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

1. 在帳務分庫分表的狀況下，如何保證記帳是在事務裏？

2. 每次記帳的出帳 & 入帳是否可拆分？

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

帳務記帳事務拆分

1. 出帳、入帳分離。出帳成功，則總體成功，入帳失敗能夠異步補帳。

2. 出帳 & 入帳 ，每一個裏面都作單邊帳、異步記帳等處理，整個支付核心鏈路惟一的一個事務就在於更新帳務餘額  & 新增流水。

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

穩定性提高

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

監控先行

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

核心鏈路監控

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

經過在監控大盤中配置關鍵指標，可以比較清晰明瞭的看出目前核心鏈路線上運行狀況。

分離核心鏈路

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

分離核心鏈路

對核心鏈路分離的過程當中，咱們對鏈路中的各個服務中切分爲核心 & 通用服務。分離的作法其實有不少，好比基於 Tesla 服務框架提供的服務分組功能；好比將一個服務切分爲兩個服務：核心鏈路服務和通用查詢服務。

在覈心鏈路分離以後，可以確保在任什麼時候候，核心鏈路不會受到其餘通用業務的影響而致使出現穩定性問題。

服務依賴梳理

目前在支付系統裏，有着數十個服務，若是不對服務依賴進行梳理，系統穩定性會得不到保障。咱們從下面幾點來梳理服務依賴：

1. 梳理平臺中的強弱依賴，斷定哪些是強依賴，哪些是弱依賴。

2. 弱依賴作好降級和超時保護，好比收銀臺渲染是的白付美額度查詢，這種能夠埋降級開關 & 設置較短的超時時間。由於查不到額度，最多不能使用白付美支付，並不會有特別大的影響。

3. 若是是強依賴，這個不能降級，怎麼辦？須要對強依賴的服務提出服務的 SLA 治理，好比帳務記帳功能，咱們會要求系統不能掛、rt 不能超過 20ms，qps 須要支撐 8k qps 等等，基於這個約定，作子服務的優化。

降級、限流

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

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

spirit 限流模式

可是不得不說，單單的 qps 或者併發限流都不能徹底的作好限流保護，須要二者的相結合才能達到所需的效果。

另一點，經過對服務的依賴梳理，咱們在各類弱依賴的服務中埋了一些降級開關。經過自研的降級推送平臺，一旦依賴服務出現問題或者不可用，能夠快速的對該服務進行降級操做。

壓測怎麼作？

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

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

2. 經過構建線上數據影子庫，壓測產生的測試數據，會全量寫入到影子庫中。經過影子庫，在複用線上正式業務一致的環境、部署、機器資源下，咱們可以作到壓測對正常業務無侵入，對系統作準確的把脈。

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

經過壓測的結果，咱們可以對支付平臺的性能 & 穩定性短板的分析和加以改進，可以不斷的提高系統的穩定性，提高系統的容量。

療效？

那麼，經過一系列的性能容量的提高，咱們達到了什麼效果？

1. 平臺容量方面：在 16 年雙十一的大促壓測中，咱們在鏈路 DB 都擴圍兩組的物理的機器狀況下，支付穩定在 3000QPS。因爲目前沒有需求，咱們未對 DB 的物理機器擴到極限，所以系統的極限性能不能徹底肯定，可是按照預估，理論上可支持 1w QPS 以上。

2. 機器利用率上：相同的容量狀況下，咱們的應用減小爲原有的 1/3。

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

核心鏈路服務性能

同時，基於性能和穩定性的提高，咱們作到了支付在歷次的大促中，保持無端障的記錄。

總結展望

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