自從有了雙十一這個電商節(jié)日，很多技術(shù)人的生命軌跡都改變了，這種年度高并發(fā)大流量復(fù)雜業(yè)務(wù)場景的經(jīng)典案例給技術(shù)和產(chǎn)品人提出了各種挑戰(zhàn)，今天我們來看看支付寶雙11的發(fā)展歷程。

和過去10年一樣，2019年天貓雙11又創(chuàng)造了一個全新的紀錄。這個數(shù)字背后，是數(shù)代支付寶工程師們殫精竭慮、不斷突破技術(shù)難關(guān)。今天支付寶的同學(xué)給 MacTalk 提供了一個紀錄片《一心一役》，是11位經(jīng)歷雙11的技術(shù)同學(xué)口述實錄，講述這一路走來支付寶技術(shù)發(fā)展的隱秘往事，很多東西都是第一次披露，看得我大呼過癮，同時推薦給大家。

對于技術(shù)人員來說，維持雙11全天24小時穩(wěn)定流暢固然不易，但最為考驗的時刻當屬零點剛過，人們操起手機，刷新早已存好的購物車，點擊支付的那一刻。

11年，零點越來越平滑的雙11購物背后，支付寶有過哪些不為人知的技術(shù)探索，他們是如何做到支撐這么龐大的交易數(shù)據(jù)呢？看看首次披露的文字版吧。

一、從外部瓶頸說起

事情從一開始就顯得不是很順利。

2011年的雙十一，在高峰時期少數(shù)用戶無法付款，經(jīng)過調(diào)查發(fā)現(xiàn)，這是因為少數(shù)銀行的網(wǎng)銀系統(tǒng)在壓力下出現(xiàn)故障。早年的支付寶交易，用戶點擊支付后需要從支付寶和銀行的接口去付款，而早年這個接口的性能很差，每秒只能支持幾十到上百筆交易，穩(wěn)定性也比較差，一旦流量上來，容易發(fā)生故障。

如果不解決這個問題，今后的每次大促都會出現(xiàn)無法付款的情況，極大影響用戶體驗。但是，這個問題單靠技術(shù)是很難解決的，銀行對網(wǎng)銀系統(tǒng)的演進有自己的規(guī)劃，支付寶無法去干涉它們的系統(tǒng)。

不過，聰明的運營人員想出了一個變通的辦法。在2012年的雙十一，支付寶通過活動吸引用戶先充值后付款，讓用戶先將錢充值到支付寶余額上，到雙十一直接從余額里面扣款就行，這樣，外部的瓶頸就被轉(zhuǎn)換到內(nèi)部了。這樣做效果非常顯著，付款失敗的問題大為緩解。

然而，外部的瓶頸始終存在，面對每年翻倍提升的流量峰值，支付對外部的依賴始終是一個隱患，不知道什么時候就會爆發(fā)。

解決這個問題最好的辦法，就是不通過網(wǎng)銀，讓資金在內(nèi)部的系統(tǒng)中流轉(zhuǎn)，先充值后付款就是這個原理。那么，有沒有一個方法，吸引用戶把錢放到支付寶里呢？2013年6月，支付寶推出余額寶，歪打正著的解決了這個問題，到2014年底余額寶就吸引了1.85億用戶，在13年和14年的雙十一，交易峰值也分別實現(xiàn)了4倍和3倍的增長。

2018年5月，支付寶接入網(wǎng)聯(lián)清算平臺，同時在這些年里，銀行也在大力提升自己的系統(tǒng)能力，中大型銀行的網(wǎng)銀系統(tǒng)支持的交易筆數(shù)已經(jīng)達到2萬筆/秒以上，外部問題基本得以解決。

解決了外部瓶頸之后，支付峰值的數(shù)字能有多高，就看支付寶的系統(tǒng)如何化解一年比一年更兇猛的流量洪峰。

二、容量規(guī)劃：三軍未動糧草先行

事實上，支持交易筆數(shù)峰值面臨的首要問題，并不是設(shè)計一個完美支持橫向擴展的架構(gòu)，而是對可能的流量峰值進行準確估計，然后安排對應(yīng)的機器和資源。如果不做估計，可能發(fā)生兩種情況：預(yù)備資源過多，架構(gòu)過度設(shè)計，造成資源浪費；預(yù)備資源過少，無法完美支持大促，造成部分支付排隊或失敗。每年雙十一備戰(zhàn)，負責大促的決策團隊會根據(jù)歷史數(shù)據(jù)、大促目標來擬定一個交易數(shù)值，然后將這個數(shù)值拆解為各個系統(tǒng)所需要應(yīng)對的流量，從而進行系統(tǒng)容量規(guī)劃。

雙11大促的場景指標一般包括交易創(chuàng)建數(shù)、收銀臺展現(xiàn)數(shù)、交易支付數(shù)?？偟闹Ц赌繕藬?shù)已經(jīng)有了，運維人員根據(jù)總tps/單機tps的算法計算出應(yīng)用在每個指標下的單機能力，然后，參考歷史活動數(shù)據(jù)，可以計算應(yīng)用在不同場景鏈路下的單機tps。

但是，這種做法人工干預(yù)較多，對于各個應(yīng)用的容量預(yù)估的粒度比較粗，后來，支付寶又建設(shè)了容量分析平臺，可以進行自動化的細粒度的容量分析。

它的原理是，如果我們把一個鏈路理解為一個業(yè)務(wù)，鏈路根節(jié)點可以理解為業(yè)務(wù)的源頭流量請求，每個鏈路上的節(jié)點（這里的節(jié)點包括應(yīng)用、DB、tair等）都能計算出該節(jié)點調(diào)用次數(shù)相對于根節(jié)點流量的系數(shù)。因此，當業(yè)務(wù)源頭的QPS確定時，就可以基于鏈路數(shù)據(jù)，計算出每個節(jié)點的QPS。

2018年的雙十一，支付寶還建設(shè)了智能容量模型，不但可以根據(jù)業(yè)務(wù)流量進行容量預(yù)估，還可以智能的產(chǎn)出應(yīng)用資源部署方案，使得在該方案下，部署單元在承載給定業(yè)務(wù)流量時的容量水平處于目標范圍。

智能容量模型是支付寶對AIOps探索的一部分，也是對數(shù)據(jù)技術(shù)和人工智能在系統(tǒng)中落地實踐的一部分，這方面也是當前支付寶技術(shù)探索的方向之一。

三、LDC與彈性架構(gòu)：大促最強武器

對流量進行預(yù)估并進行合理的容量規(guī)劃之后，接下來就看我們的架構(gòu)是否能支持流量峰值了。

首先需要說明的是，流量高峰涉及到一個系統(tǒng)的方方面面，支付寶的整個系統(tǒng)極其復(fù)雜，而且面向toC和toB都推出了很多業(yè)務(wù)，即使只關(guān)注核心支付系統(tǒng)，也包括支付清算、賬務(wù)、核算等子系統(tǒng)。

系統(tǒng)部分組件由通用型的中間件提供支撐，如負載均衡中間件LVS/Spanner、阿里巴巴的分布式緩存中間件Tair等，其它則由支付寶自研的SOFAStack金融級分布式中間件負責。

支付峰值的本質(zhì)是一個高并發(fā)問題，互聯(lián)網(wǎng)公司解決高并發(fā)的思路是橫向擴展水平拆分，用分布式的方式來應(yīng)對流量洪峰，支付寶也不例外。支付寶很早完成了服務(wù)化架構(gòu)和核心數(shù)據(jù)庫的水平拆分，成功應(yīng)對了前幾年的雙十一。

分布式系統(tǒng)示意圖

這個架構(gòu)的問題是，所有子應(yīng)用都需要訪問所有數(shù)據(jù)庫分庫，但是數(shù)據(jù)庫連接是有限的。當時主流的商業(yè)數(shù)據(jù)庫，連接都不是共享的，就是說一個事務(wù)必須獨占一個連接。而連接卻又是數(shù)據(jù)庫非常寶貴的資源，不能無限增加。當時的支付寶，面臨的問題是不能再對應(yīng)用集群擴容，因為每加一臺機器，就需要在每個數(shù)據(jù)分庫上新增若干連接，而此時幾個核心數(shù)據(jù)庫的連接數(shù)已經(jīng)到達上限。應(yīng)用不能擴容，意味著支付寶系統(tǒng)的容量定格了，不能再有任何業(yè)務(wù)量增長，別說大促，很可能再過一段時間連日常業(yè)務(wù)也支撐不了了。

這個問題迫在眉睫，從2013年開始，支付寶開始新一輪的架構(gòu)改造，實施單元化的LDC邏輯數(shù)據(jù)中心，雙十一的流量峰值，終于還是成功的扛下來了。

一個單元，是一個五臟俱全的縮小版整站，它是全能的，因為部署了所有應(yīng)用；但它不是全量的，因為只能操作一部分數(shù)據(jù)。這樣，只要將數(shù)據(jù)分區(qū)增加單元，就可以提升整個系統(tǒng)的處理性能上限。

單元化示意圖

但是，并不是所有的數(shù)據(jù)都能拆分，比如部分底層數(shù)據(jù)是全局數(shù)據(jù)，所有單元的應(yīng)用都需要訪問。并且，支付寶經(jīng)過近十年建設(shè)，有些架構(gòu)也并不能很好的拆分成單元。在這個前提下，支付寶設(shè)計了CRG的單元化架構(gòu)，既能利用單元化的優(yōu)點，也能支持現(xiàn)有的架構(gòu)。

1、RZone（Region Zone）：最符合理論上單元定義的zone，每個RZone都是自包含的，擁有自己的數(shù)據(jù)，能完成所有業(yè)務(wù)。

2、GZone（Global Zone）：部署了不可拆分的數(shù)據(jù)和服務(wù)，這些數(shù)據(jù)或服務(wù)可能會被RZone依賴。GZone在全局只有一組，數(shù)據(jù)僅有一份。

3、CZone（City Zone）：同樣部署了不可拆分的數(shù)據(jù)和服務(wù)，也會被RZone依賴。跟GZone不同的是，CZone中的數(shù)據(jù)或服務(wù)會被RZone頻繁訪問，每一筆業(yè)務(wù)至少會訪問一次；而GZone被RZone訪問的頻率則低的多。CZone是為了解決異地延遲問題而特別設(shè)計的。

CRG架構(gòu)示意圖

關(guān)于支付寶單元化和LDC的更多信息可查看 這篇文章 。

實施了LDC之后，系統(tǒng)容量實現(xiàn)水平擴展，順利支持了2013年及之后的雙十一流量洪峰，并且系統(tǒng)不再受到單點故障限制，經(jīng)過完善之后還做到異地多活，最終形成了三地五中心的金融級架構(gòu)。

理論上，只要無限擴展LDC的計算資源，就可以應(yīng)對無限大的流量，但是，這樣做的話，大部分機器只有在大促時才能派上用場，平時就是閑置的，造成資源浪費。最好能做到平時用少量資源支持常規(guī)流量，大促時經(jīng)過容量規(guī)劃，提前啟用部分空閑或第三方資源應(yīng)對高峰流量，這就是彈性架構(gòu)的由來。

2016年，支付寶開始為大促進行彈性架構(gòu)的改造。彈性架構(gòu)基于業(yè)務(wù)鏈路，因為大促時只有部分鏈路的流量激增，因此只需要針對大促關(guān)鍵鏈路進行彈性擴容即可。

彈性架構(gòu)涉及到多個層面的改造，首先是彈性機房和彈性單元，需要在LDC邏輯機房架構(gòu)上按照業(yè)務(wù)緯度繼續(xù)切片，保證單片業(yè)務(wù)可以獨立邏輯單元部署，并保持與非彈性單元的聯(lián)通性，并且可隨時彈出和回收。

其次是彈性存儲，包括流水型數(shù)據(jù)和狀態(tài)型數(shù)據(jù)的彈性。流水型數(shù)據(jù)包括支付訂單，為了支持這些數(shù)據(jù)的彈性，創(chuàng)建了彈性位+彈性UID，然后路由根據(jù)彈性UID將訂單分配至彈性單元中進行處理。狀態(tài)型存儲比如用戶的賬戶余額，進行整體彈出，具體實現(xiàn)方式是通過DB層的主備切換，將主庫壓力分流至備庫。

然后是中間件層面的改造，包括路由、RPC、消息隊列、流量管理等等。應(yīng)用層面也需要進行相應(yīng)的改造，因為每個彈性單元需要做到獨立邏輯單元部署，因此需要從服務(wù)到數(shù)據(jù)進行梳理并剝離，同時添加彈性id等彈性邏輯處理。

除了這些之外，還需要對運維平臺、壓測工具進行相應(yīng)的改造。

2016年彈性架構(gòu)上線后，成功支撐了當年雙十一，滿足大促要求和預(yù)定目標，節(jié)省了機房物理資源，成為應(yīng)對大促類流量洪峰最有力的武器。

彈性架構(gòu)里的彈性單元都是新增的集群，但其實還可以進一步的提高資源利用率。方法就是離在線混部技術(shù)，因為有些集群是用作離線的大數(shù)據(jù)分析，但并不是全天24小時都滿負荷工作，當沒有任務(wù)時，集群資源利用率極低。如果將離線的應(yīng)用和在線的業(yè)務(wù)應(yīng)用部署在一起，讓大促高峰時段能夠利用這些資源，就可以減少大促期間采購的資源，進一步節(jié)省成本。混部技術(shù)需要運維的分時調(diào)度配合，在不同的時段將資源分配給不同的應(yīng)用。

從2017年起，支付寶開始嘗試離在線混部和分時調(diào)度技術(shù)，在大促時利用離線技術(shù)所使用的集群資源，大大提升了集群資源利用率。

四、百萬支付：解決數(shù)據(jù)庫擴展瓶頸

2016年的雙十一，交易筆數(shù)峰值達到12萬筆每秒，這場高并發(fā)之戰(zhàn)仍在繼續(xù)。前面提到了很多應(yīng)對大促的技術(shù)手段，但其實漏掉了一個最重要的部分，那就是數(shù)據(jù)庫。在流量洪峰時，受到壓力最大的就是數(shù)據(jù)庫。這是因為，在前臺我們看到是一個成功交易，但拆解之后，一個交易可能平均要產(chǎn)生數(shù)百甚至上千個請求，數(shù)據(jù)庫的壓力要遠遠大于我們所能看到的數(shù)字。

從最開始，數(shù)據(jù)庫就一直是支付寶系統(tǒng)的瓶頸之一，在之前，其實已經(jīng)配合架構(gòu)改造對數(shù)據(jù)庫做了諸多升級，除了上面提過的彈性化的改造，還包括：

1. 分庫分表，將原有的交易賬戶庫分離為交易庫和賬戶庫，并通過分布式事務(wù)解決數(shù)據(jù)一致性問題。

2. 數(shù)據(jù)庫水平拆分，將所有的用戶按照1%粒度分為100份，配合單元化的邏輯隔離。

3. 數(shù)據(jù)庫讀寫分離、多點寫入、數(shù)據(jù)復(fù)制，通過這些方式，可以大大提升性能。

早年支付寶采用的商業(yè)數(shù)據(jù)庫能進行的改進是有極限的，為了成本考慮，不可能為了一年僅僅幾天的大促活動去采購額外的數(shù)據(jù)庫系統(tǒng)和設(shè)備。

早在2014年的雙十一，支付寶自研數(shù)據(jù)庫OceanBase就開始承擔10%雙十一核心交易流量，隨后一步步承擔交易、支付、賬務(wù)等核心系統(tǒng)的100%流量，經(jīng)受住了極端條件下的嚴苛考驗。

OceanBase從第一天開始，就計劃成為一個分布式的關(guān)系數(shù)據(jù)庫，也就是天然支持大規(guī)模和高并發(fā)的場景。但是，支付寶本身的用戶體量太大，再加上雙十一所面臨的的系統(tǒng)壓力太大，到2017年雙十一的時候，即使采用了額外的彈性庫，數(shù)據(jù)庫CPU壓力也接近上限，成為繼續(xù)擴容的瓶頸所在。

2018年的雙十一，支付寶在內(nèi)部提出了百萬支付架構(gòu)，意思是這套架構(gòu)可以支持百萬筆/秒量級的系統(tǒng)壓力。而這套架構(gòu)的核心，就是OceanBase 2.0分布式分區(qū)方案。

過去架構(gòu)下的DB擴展，由于DB單機存在極限，且一個UID最多對應(yīng)一臺機器，所以這里的擴展能力是通過DB新增集群，應(yīng)用加數(shù)據(jù)源來實現(xiàn)的。這就會帶來一系列的問題，比如應(yīng)用的內(nèi)存增長、多數(shù)據(jù)源導(dǎo)致彈出彈回費時費力、多個DB集群的日常維護成本高等。為解決這個問題，考慮讓DB也能像應(yīng)用一樣可以動態(tài)擴容，且必須突破一個UID最多一臺機器的限制，從而能達到應(yīng)用和DB同步擴容，不用增加新DB集群就能達到新的容量支撐能力。

由此，基于DB的分區(qū)功能，將DB的擴展性大大增強，避免了必須增加集群來擴容的尷尬。同時對應(yīng)用進行了相關(guān)的升級改造，如全站流水號架構(gòu)的升級，系列中間件的改造，以及任務(wù)撈取場景的改造等。

OceanBase分區(qū)架構(gòu)

傳統(tǒng)數(shù)據(jù)庫彈性架構(gòu)，將數(shù)據(jù)進行物理拆分到不同機器，業(yè)務(wù)在數(shù)據(jù)訪問/研發(fā)/后期維護及數(shù)據(jù)配套設(shè)施上非常繁瑣；同時拆分后資源很難快速回收，且數(shù)據(jù)拆分及聚合無法實現(xiàn)業(yè)務(wù)無損。相比于傳統(tǒng)數(shù)據(jù)庫的彈性架構(gòu)，OceanBase 2.0架構(gòu)完全不侵入業(yè)務(wù)，內(nèi)部通過分區(qū)實現(xiàn)數(shù)據(jù)分片的自組織及負載均衡，通過生成列及分區(qū)規(guī)則實現(xiàn)自動路由，通過分區(qū)聚合（partition_group）消除分布式事務(wù)性能開銷以提升性能，從而實現(xiàn)無損線性伸縮。另數(shù)據(jù)分片間share_nothing的架構(gòu)，實現(xiàn)分片故障隔離及單點故障消除的高可用架構(gòu)。

2018年雙十一，OceanBase 2.0成功上線，并支持了交易和支付的全部流量。并且，基于OceanBase2.0分區(qū)方案的這套架構(gòu)可以輕松擴展到支持百萬級交易，關(guān)于應(yīng)對流量洪峰的戰(zhàn)役暫時告一段落。

五、技術(shù)保障：大促技術(shù)標準化

雙十一是新技術(shù)的演練場，那么怎么確定這些技術(shù)能有效支撐流量高峰呢？特別在支付寶，涉及到人們的資金安全，一旦發(fā)生問題后果極其嚴重，更是要慎之又慎。

2014年，支付寶上線了全鏈路壓測，成為系統(tǒng)化技術(shù)驗證的神器；從2017年起，支付寶開始打造自動化和智能化的技術(shù)風險防控體系；2018年的雙十一，大促中控上線，大促相關(guān)的技術(shù)開始走向標準化。

大促中控示意圖

大促中控也就是一站式的大促保障解決方案，它的目的，就是將之前大促的經(jīng)驗沉淀下來，形成套路和規(guī)范，最終向無人值守方向發(fā)展，搞大促不需要技術(shù)人再熬夜了。

有了大促中控，可以進行自動化的無損壓測，線上壓測能得到想要的結(jié)果的同時，不影響正在進行的業(yè)務(wù)。它的核心技術(shù)能力是對環(huán)境、機器、線程的隔離，以及在壓測異常時的智能熔斷。

壓測并不是萬能的，有些問題可能在壓測中難以暴露，從2018年起，支付寶還展開了紅藍攻防演練，為了在大促峰值出現(xiàn)異常時，檢查應(yīng)急策略、組織保障、響應(yīng)速度是否到位，以及驗證新技術(shù)的穩(wěn)定性是否達標。

對于大促中的資金安全，支付寶自研了實時的資金核對系統(tǒng)，實現(xiàn)峰值的資金安全實時驗證，驗證每一筆資金準確無誤。

當所有技術(shù)準備就緒并不是就可以了，每次大促之前還有很多配置需要切換，一旦出錯就會造成嚴重影響，因此支付寶打造了面向終態(tài)的技術(shù)風險巡檢能力，在大促前一天進行成百上千的配置自動化檢查，確認所有系統(tǒng)進入大促狀態(tài)，確保萬無一失。

隨著時鐘漸漸指向零點，大促一觸即發(fā)。

六、未來可期，我們一路同行

總結(jié)起來，雙十一流量峰值考驗的是架構(gòu)的可伸縮性、數(shù)據(jù)庫的承載能力、運維的強大調(diào)度能力，以及完善的技術(shù)保障能力。為了確保大促順利完成，需要做的技術(shù)準備也遠遠不只文中提到的，諸如全鏈路壓測這樣的幕后功臣還有很多，由于篇幅所限，這里就不再一一介紹了。

支付寶也在持續(xù)更新著自己的技術(shù)裝備庫。今年的雙十一，支付寶也有幾項新能力得到實戰(zhàn)檢驗：OceanBase 2.2上線，該版本在TPC-C基準測試中取得第一名，平穩(wěn)支撐了新大促；自研的Service Mesh 首次登上大促舞臺，目前已經(jīng) 100% 覆蓋支付寶核心支付鏈路，是業(yè)界最大的 Service Mesh 集群。

隨著普惠金融的落地，以及萬物互聯(lián)的發(fā)展，支付平臺面臨的流量壓力會進一步提升。現(xiàn)在我們看到的峰值，未來也許稀松平常；未來的峰值，也許比今天還要高幾個量級。支付峰值這場戰(zhàn)役仍會繼續(xù)下去，其中的技術(shù)也將不斷的更新進化，未來雙十一的技術(shù)之戰(zhàn)將更加精彩。

雙十一，不僅僅是購物節(jié)，還是推動互聯(lián)網(wǎng)技術(shù)發(fā)展的動力。期待 2020。