超燃！支付宝技术双11纪录片《一心一役》全球独家首发
?和過(guò)去10年一樣，2019年天貓雙11又創(chuàng)造了一個(gè)全新的紀(jì)錄。
這個(gè)數(shù)字背后，是數(shù)代支付寶工程師們殫精竭慮、不斷突破技術(shù)難關(guān)。
今年雙11之前，小編邀請(qǐng)到11位經(jīng)歷雙11的技術(shù)同學(xué)口述實(shí)錄，特別籌備了紀(jì)錄片《一心一役》，講述這一路走來(lái)的那些隱秘往事。
對(duì)于技術(shù)人員來(lái)說(shuō)，維持雙11全天24小時(shí)穩(wěn)定流暢固然不易，但最為考驗(yàn)的時(shí)刻當(dāng)屬零點(diǎn)剛過(guò)，人們操起手機(jī)，刷新早已存好的購(gòu)物車(chē)，點(diǎn)擊支付的那一刻！
11年，零點(diǎn)越來(lái)越平滑的雙11購(gòu)物背后，支付寶有過(guò)哪些不為人知的技術(shù)探索，今天也特別放送。
從外部瓶頸說(shuō)起
事情從一開(kāi)始就顯得不是很順利。
2011年的雙十一，在高峰時(shí)期少數(shù)用戶(hù)無(wú)法付款，經(jīng)過(guò)調(diào)查發(fā)現(xiàn)，這是因?yàn)樯贁?shù)銀行的網(wǎng)銀系統(tǒng)在壓力下出現(xiàn)故障。早年的支付寶交易，用戶(hù)點(diǎn)擊支付后需要從支付寶和銀行的接口去付款，而早年這個(gè)接口的性能很差，每秒只能支持幾十到上百筆交易，穩(wěn)定性也比較差，一旦流量上來(lái)，容易發(fā)生故障。
如果不解決這個(gè)問(wèn)題，今后的每次大促都會(huì)出現(xiàn)無(wú)法付款的情況，極大影響用戶(hù)體驗(yàn)。但是，這個(gè)問(wèn)題單靠技術(shù)是很難解決的，銀行對(duì)網(wǎng)銀系統(tǒng)的演進(jìn)有自己的規(guī)劃，支付寶無(wú)法去干涉它們的系統(tǒng)。
不過(guò)，聰明的運(yùn)營(yíng)人員想出了一個(gè)變通的辦法。在2012年的雙十一，支付寶通過(guò)活動(dòng)吸引用戶(hù)先充值后付款，讓用戶(hù)先將錢(qián)充值到支付寶余額上，到雙十一直接從余額里面扣款就行，這樣，外部的瓶頸就被轉(zhuǎn)換到內(nèi)部了。這樣做效果非常顯著，付款失敗的問(wèn)題大為緩解。
然而，外部的瓶頸始終存在，面對(duì)每年翻倍提升的流量峰值，支付對(duì)外部的依賴(lài)始終是一個(gè)隱患，不知道什么時(shí)候就會(huì)爆發(fā)。
解決這個(gè)問(wèn)題最好的辦法，就是不通過(guò)網(wǎng)銀，讓資金在內(nèi)部的系統(tǒng)中流轉(zhuǎn)，先充值后付款就是這個(gè)原理。那么，有沒(méi)有一個(gè)方法，吸引用戶(hù)把錢(qián)放到支付寶里呢？2013年6月，支付寶推出余額寶，歪打正著的解決了這個(gè)問(wèn)題，到2014年底余額寶就吸引了1.85億用戶(hù)，在13年和14年的雙十一，交易峰值也分別實(shí)現(xiàn)了4倍和3倍的增長(zhǎng)。
2018年5月，支付寶接入網(wǎng)聯(lián)清算平臺(tái)，同時(shí)在這些年里，銀行也在大力提升自己的系統(tǒng)能力，中大型銀行的網(wǎng)銀系統(tǒng)支持的交易筆數(shù)已經(jīng)達(dá)到2萬(wàn)筆/秒以上，外部問(wèn)題基本得以解決。
解決了外部瓶頸之后，支付峰值的數(shù)字能有多高，就看支付寶的系統(tǒng)如何化解一年比一年更兇猛的流量洪峰。
容量規(guī)劃：三軍未動(dòng)糧草先行
事實(shí)上，支持交易筆數(shù)峰值面臨的首要問(wèn)題，并不是設(shè)計(jì)一個(gè)完美支持橫向擴(kuò)展的架構(gòu)，而是對(duì)可能的流量峰值進(jìn)行準(zhǔn)確估計(jì)，然后安排對(duì)應(yīng)的機(jī)器和資源。如果不做估計(jì)，可能發(fā)生兩種情況：預(yù)備資源過(guò)多，架構(gòu)過(guò)度設(shè)計(jì)，造成資源浪費(fèi)；預(yù)備資源過(guò)少，無(wú)法完美支持大促，造成部分支付排隊(duì)或失敗。 每年雙十一備戰(zhàn)，負(fù)責(zé)大促的決策團(tuán)隊(duì)會(huì)根據(jù)歷史數(shù)據(jù)、大促目標(biāo)來(lái)擬定一個(gè)交易數(shù)值，然后將這個(gè)數(shù)值拆解為各個(gè)系統(tǒng)所需要應(yīng)對(duì)的流量，從而進(jìn)行系統(tǒng)容量規(guī)劃。
雙11大促的場(chǎng)景指標(biāo)一般包括交易創(chuàng)建數(shù)、收銀臺(tái)展現(xiàn)數(shù)、交易支付數(shù)。總的支付目標(biāo)數(shù)已經(jīng)有了，運(yùn)維人員根據(jù)總tps/單機(jī)tps的算法計(jì)算出應(yīng)用在每個(gè)指標(biāo)下的單機(jī)能力，然后，參考?xì)v史活動(dòng)數(shù)據(jù)，可以計(jì)算應(yīng)用在不同場(chǎng)景鏈路下的單機(jī)tps。
但是，這種做法人工干預(yù)較多，對(duì)于各個(gè)應(yīng)用的容量預(yù)估的粒度比較粗，后來(lái)，支付寶又建設(shè)了容量分析平臺(tái)，可以進(jìn)行自動(dòng)化的細(xì)粒度的容量分析。
它的原理是，如果我們把一個(gè)鏈路理解為一個(gè)業(yè)務(wù)，鏈路根節(jié)點(diǎn)可以理解為業(yè)務(wù)的源頭流量請(qǐng)求，每個(gè)鏈路上的節(jié)點(diǎn)（這里的節(jié)點(diǎn)包括應(yīng)用、DB、tair等）都能計(jì)算出該節(jié)點(diǎn)調(diào)用次數(shù)相對(duì)于根節(jié)點(diǎn)流量的系數(shù)。因此，當(dāng)業(yè)務(wù)源頭的QPS確定時(shí)，就可以基于鏈路數(shù)據(jù)，計(jì)算出每個(gè)節(jié)點(diǎn)的QPS。
2018年的雙十一，支付寶還建設(shè)了智能容量模型，不但可以根據(jù)業(yè)務(wù)流量進(jìn)行容量預(yù)估，還可以智能的產(chǎn)出應(yīng)用資源部署方案，使得在該方案下，部署單元在承載給定業(yè)務(wù)流量時(shí)的容量水平處于目標(biāo)范圍。
智能容量模型是支付寶對(duì) AIOps 探索的一部分，也是對(duì)數(shù)據(jù)技術(shù)和人工智能在系統(tǒng)中落地實(shí)踐的一部分，這方面也是當(dāng)前支付寶技術(shù)探索的方向之一。
LDC與彈性架構(gòu)：大促最強(qiáng)武器
對(duì)流量進(jìn)行預(yù)估并進(jìn)行合理的容量規(guī)劃之后，接下來(lái)就看我們的架構(gòu)是否能支持流量峰值了。
首先需要說(shuō)明的是，流量高峰涉及到一個(gè)系統(tǒng)的方方面面，支付寶的整個(gè)系統(tǒng)極其復(fù)雜，而且面向toC和toB都推出了很多業(yè)務(wù)，即使只關(guān)注核心支付系統(tǒng)，也包括支付清算、賬務(wù)、核算等子系統(tǒng)。
系統(tǒng)部分組件由通用型的中間件提供支撐，如負(fù)載均衡中間件LVS/Spanner、阿里巴巴的分布式緩存中間件Tair等，其它則由支付寶自研的SOFAStack金融級(jí)分布式中間件負(fù)責(zé)。
支付峰值的本質(zhì)是一個(gè)高并發(fā)問(wèn)題，互聯(lián)網(wǎng)公司解決高并發(fā)的思路是橫向擴(kuò)展水平拆分，用分布式的方式來(lái)應(yīng)對(duì)流量洪峰，支付寶也不例外。支付寶很早完成了服務(wù)化架構(gòu)和核心數(shù)據(jù)庫(kù)的水平拆分，成功應(yīng)對(duì)了前幾年的雙十一。
分布式系統(tǒng)示意圖
這個(gè)架構(gòu)的問(wèn)題是，所有子應(yīng)用都需要訪問(wèn)所有數(shù)據(jù)庫(kù)分庫(kù)，但是數(shù)據(jù)庫(kù)連接是有限的。當(dāng)時(shí)主流的商業(yè)數(shù)據(jù)庫(kù)，連接都不是共享的，就是說(shuō)一個(gè)事務(wù)必須獨(dú)占一個(gè)連接。而連接卻又是數(shù)據(jù)庫(kù)非常寶貴的資源，不能無(wú)限增加。當(dāng)時(shí)的支付寶，面臨的問(wèn)題是不能再對(duì)應(yīng)用集群擴(kuò)容，因?yàn)槊考右慌_(tái)機(jī)器，就需要在每個(gè)數(shù)據(jù)分庫(kù)上新增若干連接，而此時(shí)幾個(gè)核心數(shù)據(jù)庫(kù)的連接數(shù)已經(jīng)到達(dá)上限。應(yīng)用不能擴(kuò)容，意味著支付寶系統(tǒng)的容量定格了，不能再有任何業(yè)務(wù)量增長(zhǎng)，別說(shuō)大促，很可能再過(guò)一段時(shí)間連日常業(yè)務(wù)也支撐不了了。
這個(gè)問(wèn)題迫在眉睫，從2013年開(kāi)始，支付寶開(kāi)始新一輪的架構(gòu)改造，實(shí)施單元化的LDC邏輯數(shù)據(jù)中心，雙十一的流量峰值，終于還是成功的扛下來(lái)了。
一個(gè)單元，是一個(gè)五臟俱全的縮小版整站，它是全能的，因?yàn)椴渴鹆怂袘?yīng)用；但它不是全量的，因?yàn)橹荒懿僮饕徊糠謹(jǐn)?shù)據(jù)。這樣，只要將數(shù)據(jù)分區(qū)增加單元，就可以提升整個(gè)系統(tǒng)的處理性能上限。
單元化示意圖
但是，并不是所有的數(shù)據(jù)都能拆分，比如部分底層數(shù)據(jù)是全局?jǐn)?shù)據(jù)，所有單元的應(yīng)用都需要訪問(wèn)。并且，支付寶經(jīng)過(guò)近十年建設(shè)，有些架構(gòu)也并不能很好的拆分成單元。在這個(gè)前提下，支付寶設(shè)計(jì)了CRG的單元化架構(gòu)，既能利用單元化的優(yōu)點(diǎn)，也能支持現(xiàn)有的架構(gòu)。
- RZone（Region Zone）：最符合理論上單元定義的 zone，每個(gè) RZone 都是自包含的，擁有自己的數(shù)據(jù)，能完成所有業(yè)務(wù)。
- GZone（Global Zone）：部署了不可拆分的數(shù)據(jù)和服務(wù)，這些數(shù)據(jù)或服務(wù)可能會(huì)被 RZone 依賴(lài)。GZone 在全局只有一組，數(shù)據(jù)僅有一份。
- CZone（City Zone）：同樣部署了不可拆分的數(shù)據(jù)和服務(wù)，也會(huì)被 RZone 依賴(lài)。跟 GZone 不同的是，CZone 中的數(shù)據(jù)或服務(wù)會(huì)被 RZone 頻繁訪問(wèn)，每一筆業(yè)務(wù)至少會(huì)訪問(wèn)一次；而 GZone 被 RZone 訪問(wèn)的頻率則低的多。CZone 是為了解決異地延遲問(wèn)題而特別設(shè)計(jì)的。
CRG架構(gòu)示意圖
關(guān)于支付寶單元化和LDC的更多信息可查看這篇文章。
實(shí)施了LDC之后，系統(tǒng)容量實(shí)現(xiàn)水平擴(kuò)展，順利支持了2013年及之后的雙十一流量洪峰，并且系統(tǒng)不再受到單點(diǎn)故障限制，經(jīng)過(guò)完善之后還做到異地多活，最終形成了三地五中心的金融級(jí)架構(gòu)。
理論上，只要無(wú)限擴(kuò)展LDC的計(jì)算資源，就可以應(yīng)對(duì)無(wú)限大的流量，但是，這樣做的話(huà)，大部分機(jī)器只有在大促時(shí)才能派上用場(chǎng)，平時(shí)就是閑置的，造成資源浪費(fèi)。最好能做到平時(shí)用少量資源支持常規(guī)流量，大促時(shí)經(jīng)過(guò)容量規(guī)劃，提前啟用部分空閑或第三方資源應(yīng)對(duì)高峰流量，這就是彈性架構(gòu)的由來(lái)。
2016年，支付寶開(kāi)始為大促進(jìn)行彈性架構(gòu)的改造。彈性架構(gòu)基于業(yè)務(wù)鏈路，因?yàn)榇蟠贂r(shí)只有部分鏈路的流量激增，因此只需要針對(duì)大促關(guān)鍵鏈路進(jìn)行彈性擴(kuò)容即可。
彈性架構(gòu)涉及到多個(gè)層面的改造，首先是彈性機(jī)房和彈性單元，需要在LDC邏輯機(jī)房架構(gòu)上按照業(yè)務(wù)緯度繼續(xù)切片，保證單片業(yè)務(wù)可以獨(dú)立邏輯單元部署，并保持與非彈性單元的聯(lián)通性，并且可隨時(shí)彈出和回收。
其次是彈性存儲(chǔ)，包括流水型數(shù)據(jù)和狀態(tài)型數(shù)據(jù)的彈性。流水型數(shù)據(jù)包括支付訂單，為了支持這些數(shù)據(jù)的彈性，創(chuàng)建了彈性位+彈性UID，然后路由根據(jù)彈性UID將訂單分配至彈性單元中進(jìn)行處理。狀態(tài)型存儲(chǔ)比如用戶(hù)的賬戶(hù)余額，進(jìn)行整體彈出，具體實(shí)現(xiàn)方式是通過(guò)DB層的主備切換，將主庫(kù)壓力分流至備庫(kù)。
然后是中間件層面的改造，包括路由、RPC、消息隊(duì)列、流量管理等等。應(yīng)用層面也需要進(jìn)行相應(yīng)的改造，因?yàn)槊總€(gè)彈性單元需要做到獨(dú)立邏輯單元部署，因此需要從服務(wù)到數(shù)據(jù)進(jìn)行梳理并剝離，同時(shí)添加彈性id等彈性邏輯處理。
除了這些之外，還需要對(duì)運(yùn)維平臺(tái)、壓測(cè)工具進(jìn)行相應(yīng)的改造。
2016年彈性架構(gòu)上線后，成功支撐了當(dāng)年雙十一，滿(mǎn)足大促要求和預(yù)定目標(biāo)，節(jié)省了機(jī)房物理資源，成為應(yīng)對(duì)大促類(lèi)流量洪峰最有力的武器。
彈性架構(gòu)里的彈性單元都是新增的集群，但其實(shí)還可以進(jìn)一步的提高資源利用率。方法就是離在線混部技術(shù)，因?yàn)橛行┘菏怯米麟x線的大數(shù)據(jù)分析，但并不是全天24小時(shí)都滿(mǎn)負(fù)荷工作，當(dāng)沒(méi)有任務(wù)時(shí)，集群資源利用率極低。如果將離線的應(yīng)用和在線的業(yè)務(wù)應(yīng)用部署在一起，讓大促高峰時(shí)段能夠利用這些資源，就可以減少大促期間采購(gòu)的資源，進(jìn)一步節(jié)省成本。混部技術(shù)需要運(yùn)維的分時(shí)調(diào)度配合，在不同的時(shí)段將資源分配給不同的應(yīng)用。
從2017年起，支付寶開(kāi)始嘗試離在線混部和分時(shí)調(diào)度技術(shù)，在大促時(shí)利用離線技術(shù)所使用的集群資源，大大提升了集群資源利用率。
百萬(wàn)支付：解決數(shù)據(jù)庫(kù)擴(kuò)展瓶頸
2016年的雙十一，交易筆數(shù)峰值達(dá)到12萬(wàn)筆每秒，這場(chǎng)高并發(fā)之戰(zhàn)仍在繼續(xù)。 前面提到了很多應(yīng)對(duì)大促的技術(shù)手段，但其實(shí)漏掉了一個(gè)最重要的部分，那就是數(shù)據(jù)庫(kù)。在流量洪峰時(shí)，受到壓力最大的就是數(shù)據(jù)庫(kù)。這是因?yàn)?#xff0c;在前臺(tái)我們看到是一個(gè)成功交易，但拆解之后，一個(gè)交易可能平均要產(chǎn)生數(shù)百甚至上千個(gè)請(qǐng)求，數(shù)據(jù)庫(kù)的壓力要遠(yuǎn)遠(yuǎn)大于我們所能看到的數(shù)字。
從最開(kāi)始，數(shù)據(jù)庫(kù)就一直是支付寶系統(tǒng)的瓶頸之一，在之前，其實(shí)已經(jīng)配合架構(gòu)改造對(duì)數(shù)據(jù)庫(kù)做了諸多升級(jí)，除了上面提過(guò)的彈性化的改造，還包括：
早年支付寶采用的商業(yè)數(shù)據(jù)庫(kù)能進(jìn)行的改進(jìn)是有極限的，為了成本考慮，不可能為了一年僅僅幾天的大促活動(dòng)去采購(gòu)額外的數(shù)據(jù)庫(kù)系統(tǒng)和設(shè)備。
早在2014年的雙十一，支付寶自研數(shù)據(jù)庫(kù)OceanBase就開(kāi)始承擔(dān)10%雙十一核心交易流量，隨后一步步承擔(dān)交易、支付、賬務(wù)等核心系統(tǒng)的100%流量，經(jīng)受住了極端條件下的嚴(yán)苛考驗(yàn)。
OceanBase從第一天開(kāi)始，就計(jì)劃成為一個(gè)分布式的關(guān)系數(shù)據(jù)庫(kù)，也就是天然支持大規(guī)模和高并發(fā)的場(chǎng)景。但是，支付寶本身的用戶(hù)體量太大，再加上雙十一所面臨的的系統(tǒng)壓力太大，到2017年雙十一的時(shí)候，即使采用了額外的彈性庫(kù)，數(shù)據(jù)庫(kù)CPU壓力也接近上限，成為繼續(xù)擴(kuò)容的瓶頸所在。
2018年的雙十一，支付寶在內(nèi)部提出了百萬(wàn)支付架構(gòu)，意思是這套架構(gòu)可以支持百萬(wàn)筆/秒量級(jí)的系統(tǒng)壓力。而這套架構(gòu)的核心，就是OceanBase 2.0分布式分區(qū)方案。
過(guò)去架構(gòu)下的DB擴(kuò)展，由于DB單機(jī)存在極限，且一個(gè)UID最多對(duì)應(yīng)一臺(tái)機(jī)器，所以這里的擴(kuò)展能力是通過(guò)DB新增集群，應(yīng)用加數(shù)據(jù)源來(lái)實(shí)現(xiàn)的。這就會(huì)帶來(lái)一系列的問(wèn)題，比如應(yīng)用的內(nèi)存增長(zhǎng)、多數(shù)據(jù)源導(dǎo)致彈出彈回費(fèi)時(shí)費(fèi)力、多個(gè)DB集群的日常維護(hù)成本高等。為解決這個(gè)問(wèn)題，考慮讓DB也能像應(yīng)用一樣可以動(dòng)態(tài)擴(kuò)容，且必須突破一個(gè)UID最多一臺(tái)機(jī)器的限制，從而能達(dá)到應(yīng)用和DB同步擴(kuò)容，不用增加新DB集群就能達(dá)到新的容量支撐能力。
由此，基于DB的分區(qū)功能，將DB的擴(kuò)展性大大增強(qiáng)，避免了必須增加集群來(lái)擴(kuò)容的尷尬。同時(shí)對(duì)應(yīng)用進(jìn)行了相關(guān)的升級(jí)改造，如全站流水號(hào)架構(gòu)的升級(jí)，系列中間件的改造，以及任務(wù)撈取場(chǎng)景的改造等。
OceanBase分區(qū)架構(gòu)
傳統(tǒng)數(shù)據(jù)庫(kù)彈性架構(gòu)，將數(shù)據(jù)進(jìn)行物理拆分到不同機(jī)器，業(yè)務(wù)在數(shù)據(jù)訪問(wèn)/研發(fā)/后期維護(hù)及數(shù)據(jù)配套設(shè)施上非常繁瑣；同時(shí)拆分后資源很難快速回收，且數(shù)據(jù)拆分及聚合無(wú)法實(shí)現(xiàn)業(yè)務(wù)無(wú)損。相比于傳統(tǒng)數(shù)據(jù)庫(kù)的彈性架構(gòu)，OceanBase 2.0架構(gòu)完全不侵入業(yè)務(wù)，內(nèi)部通過(guò)分區(qū)實(shí)現(xiàn)數(shù)據(jù)分片的自組織及負(fù)載均衡，通過(guò)生成列及分區(qū)規(guī)則實(shí)現(xiàn)自動(dòng)路由，通過(guò)分區(qū)聚合（partition_group）消除分布式事務(wù)性能開(kāi)銷(xiāo)以提升性能，從而實(shí)現(xiàn)無(wú)損線性伸縮。另數(shù)據(jù)分片間share_nothing的架構(gòu)，實(shí)現(xiàn)分片故障隔離及單點(diǎn)故障消除的高可用架構(gòu)。
2018年雙十一，OceanBase 2.0成功上線，并支持了交易和支付的全部流量。并且，基于OceanBase2.0分區(qū)方案的這套架構(gòu)可以輕松擴(kuò)展到支持百萬(wàn)級(jí)交易，關(guān)于應(yīng)對(duì)流量洪峰的戰(zhàn)役暫時(shí)告一段落。
技術(shù)保障：大促技術(shù)標(biāo)準(zhǔn)化
雙十一是新技術(shù)的演練場(chǎng)，那么怎么確定這些技術(shù)能有效支撐流量高峰呢？特別在支付寶，涉及到人們的資金安全，一旦發(fā)生問(wèn)題后果極其嚴(yán)重，更是要慎之又慎。
2014年，支付寶上線了全鏈路壓測(cè)，成為系統(tǒng)化技術(shù)驗(yàn)證的神器；從2017年起，支付寶開(kāi)始打造自動(dòng)化和智能化的技術(shù)風(fēng)險(xiǎn)防控體系；2018年的雙十一，大促中控上線，大促相關(guān)的技術(shù)開(kāi)始走向標(biāo)準(zhǔn)化。
大促中控示意圖
大促中控也就是一站式的大促保障解決方案，它的目的，就是將之前大促的經(jīng)驗(yàn)沉淀下來(lái)，形成套路和規(guī)范，最終向無(wú)人值守方向發(fā)展，搞大促不需要技術(shù)人再熬夜了。
有了大促中控，可以進(jìn)行自動(dòng)化的無(wú)損壓測(cè)，線上壓測(cè)能得到想要的結(jié)果的同時(shí)，不影響正在進(jìn)行的業(yè)務(wù)。它的核心技術(shù)能力是對(duì)環(huán)境、機(jī)器、線程的隔離，以及在壓測(cè)異常時(shí)的智能熔斷。
壓測(cè)并不是萬(wàn)能的，有些問(wèn)題可能在壓測(cè)中難以暴露，從2018年起，支付寶還展開(kāi)了紅藍(lán)攻防演練，為了在大促峰值出現(xiàn)異常時(shí)，檢查應(yīng)急策略、組織保障、響應(yīng)速度是否到位，以及驗(yàn)證新技術(shù)的穩(wěn)定性是否達(dá)標(biāo)。
對(duì)于大促中的資金安全，支付寶自研了實(shí)時(shí)的資金核對(duì)系統(tǒng)，實(shí)現(xiàn)峰值的資金安全實(shí)時(shí)驗(yàn)證，驗(yàn)證每一筆資金準(zhǔn)確無(wú)誤。
當(dāng)所有技術(shù)準(zhǔn)備就緒并不是就可以了，每次大促之前還有很多配置需要切換，一旦出錯(cuò)就會(huì)造成嚴(yán)重影響，因此支付寶打造了面向終態(tài)的技術(shù)風(fēng)險(xiǎn)巡檢能力，在大促前一天進(jìn)行成百上千的配置自動(dòng)化檢查，確認(rèn)所有系統(tǒng)進(jìn)入大促狀態(tài)，確保萬(wàn)無(wú)一失。
隨著時(shí)鐘漸漸指向零點(diǎn)，大促一觸即發(fā)。
未來(lái)可期，我們一路同行
總結(jié)起來(lái)，雙十一流量峰值考驗(yàn)的是架構(gòu)的可伸縮性、數(shù)據(jù)庫(kù)的承載能力、運(yùn)維的強(qiáng)大調(diào)度能力，以及完善的技術(shù)保障能力。為了確保大促順利完成，需要做的技術(shù)準(zhǔn)備也遠(yuǎn)遠(yuǎn)不只文中提到的，諸如全鏈路壓測(cè)這樣的幕后功臣還有很多，由于篇幅所限，這里就不再一一介紹了。
支付寶也在持續(xù)更新著自己的技術(shù)裝備庫(kù)。今年的雙十一，支付寶也有幾項(xiàng)新能力得到實(shí)戰(zhàn)檢驗(yàn)：OceanBase 2.2上線，該版本在TPC-C基準(zhǔn)測(cè)試中取得第一名，平穩(wěn)支撐了新大促；自研的Service Mesh 首次登上大促舞臺(tái)，目前已經(jīng) 100% 覆蓋支付寶核心支付鏈路，是業(yè)界最大的 Service Mesh 集群。
隨著普惠金融的落地，以及萬(wàn)物互聯(lián)的發(fā)展，支付平臺(tái)面臨的流量壓力會(huì)進(jìn)一步提升。現(xiàn)在我們看到的峰值，未來(lái)也許稀松平常；未來(lái)的峰值，也許比今天還要高幾個(gè)量級(jí)。支付峰值這場(chǎng)戰(zhàn)役仍會(huì)繼續(xù)下去，其中的技術(shù)也將不斷的更新進(jìn)化，未來(lái)雙十一的技術(shù)之戰(zhàn)將更加精彩。
原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。
總結(jié)
以上是生活随笔為你收集整理的超燃！支付宝技术双11纪录片《一心一役》全球独家首发的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 亿级规模的 Feed 流系统，如何轻松设
- 下一篇： 解读 Knative Eventing