和過去10年一樣，2019年天貓雙11又創造了一個全新的紀錄。

這個數字背後，是數代支付寶工程師們殫精竭慮、不斷突破技術難關。

今年雙11之前，小編邀請到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的單元化架構，既能利用單元化的優點，也能支援現有的架構。

• RZone（Region Zone）：最符合理論上單元定義的 zone，每個 RZone 都是自包含的，擁有自己的資料，能完成所有業務。
• GZone（Global Zone）：部署了不可拆分的資料和服務，這些資料或服務可能會被 RZone 依賴。GZone 在全域性只有一組，資料僅有一份。
• 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分割槽方案的這套架構可以輕鬆擴充套件到支援百萬級交易，關於應對流量洪峰的戰役暫時告一段落。

點選觀看影片 《使命必達——OceanBase登頂TPC-C測試》

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

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

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

大促中控示意圖

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

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

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

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

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

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

未來可期，我們一路同行

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

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

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