和過去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%粒度分為100份，配合單元化的邏輯隔離。
- 資料庫讀寫分離、多點寫入、資料複制，通過這些方式，可以大大提升性能。
早年支付寶采用的商業資料庫能進行的改進是有極限的，為了成本考慮，不可能為了一年僅僅幾天的大促活動去采購額外的資料庫系統和裝置。
早在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 叢集。
使命必達——OceanBase登頂TPC-C測試随着普惠金融的落地，以及萬物互聯的發展，支付平台面臨的流量壓力會進一步提升。現在我們看到的峰值，未來也許稀松平常；未來的峰值，也許比今天還要高幾個量級。支付峰值這場戰役仍會繼續下去，其中的技術也将不斷的更新進化，未來雙十一的技術之戰将更加精彩。