超燃！支付寶技術雙11紀錄片《一心一役》全球獨家首發

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

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

今年雙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分區方案的這套架構能夠輕鬆擴展到支持百萬級交易，關於應對流量洪峯的戰役暫時告一段落。

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

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

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

大促中控示意圖

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

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

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

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

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

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

將來可期，咱們一路同行

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

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

點擊觀看視頻【使命必達——OceanBase登頂TPC-C測試】

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