美聯支付體系架構演進（下）-容量提升

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

下面我們以支付核心鏈路(圖1)為例，談談如何提升支付平台的容量和穩定性。

圖1 支付核心鏈路

一、容量提升

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

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

服務調用非同步化

熱點賬戶問題優化

事務切分

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

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

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

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

圖1.1 支付核心鏈路分庫分表

1.2 服務調用非同步化

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

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

1.2.1 支付消息報

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

圖1.2 支付消息報架構圖

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

1.2.2 外部支付非同步化

在外部支付中，經常會碰到這種情況，需要服務方與第三方支付交互，獲取預支付憑證，如圖1.3所示。這種同步調用的情況下，由於需要跨外部網路，響應的RT會非常長，可能會出現跨秒的情況。

由於是同步調用，會阻塞整個支付鏈路。一旦RT很長且QPS比較大的情況下，服務會整體hold住，甚至會出現拒絕服務的情況。

圖1.3 同步調用三方支付

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

圖1.4 非同步調用三方支付

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

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

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

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

1.2.3 非同步並行

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

圖1.5 串列模式下的收銀台渲染

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

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

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

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

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

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

1.2.4 資金核算體系非同步化

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

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

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

1.3 熱點賬戶問題優化

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

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

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

3）大商家的熱點賬戶等。

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

1）內部戶

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

2）平台戶

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

3）大商家

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

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

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

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

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

1.4 賬務記賬事務切分

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

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

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

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

圖1.8 賬務記賬事務拆分

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

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

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

二、穩定性提升

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

2.1 監控先行

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

圖2.1 核心鏈路監控

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

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

2.2 分離核心鏈路

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

圖2.2 分離核心鏈路

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

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

2.3 服務依賴梳理

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

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

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

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

2.4 降級、限流

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

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

圖2.3 spirit限流模式

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

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

三、壓測

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

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

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

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

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

四、療效

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

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

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

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

圖4.1 核心鏈路服務性能

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

五、總結展望

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

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