自從有了雙十一這個電商節日，很多技術人的生命軌跡都改變了，這種年度高并發大流量復雜業務場景的經典案例給技術和產品人提出了各種挑戰，今天我們來看看支付寶雙11的發展歷程。

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

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

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

一、從外部瓶頸說起

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

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

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

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

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

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

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

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

二、容量規劃：三軍未動糧草先行

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

雙11大促的場景指標一般包括交易創建數、收銀臺展現數、交易支付數。總的支付目標數已經有了，運維人員根據總tps/單機tps的算法計算出應用在每個指標下的單機能力，然后，參考歷史活動數據，可以計算應用在不同場景鏈路下的單機tps。

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

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

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

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

三、LDC與彈性架構：大促最強武器

對流量進行預估并進行合理的容量規劃之后，接下來就看我們的架構是否能支持流量峰值了。

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

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

支付峰值的本質是一個高并發問題，互聯網公司解決高并發的思路是橫向擴展水平拆分，用分布式的方式來應對流量洪峰，支付寶也不例外。支付寶很早完成了服務化架構和核心數據庫的水平拆分，成功應對了前幾年的雙十一。

分布式系統示意圖

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

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

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

單元化示意圖

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

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

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

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

CRG架構示意圖

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

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

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

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

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

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

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

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

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

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

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

四、百萬支付：解決數據庫擴展瓶頸

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

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

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

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

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

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

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

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

2018年的雙十一，支付寶在內部提出了百萬支付架構，意思是這套架構可以支持百萬筆/秒量級的系統壓力。而這套架構的核心，就是OceanBase 2.0分布式分區方案。

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

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

OceanBase分區架構

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

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

五、技術保障：大促技術標準化

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

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

大促中控示意圖

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

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

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

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

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

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

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

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

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

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

雙十一，不僅僅是購物節，還是推動互聯網技術發展的動力。期待 2020。