2007年，國內(nèi)情報史專家高金虎出版過一本《看不見的第二戰(zhàn)場》，講述無線電情報與戰(zhàn)爭的關(guān)系。

“看不見的第二戰(zhàn)場”，這段話拿來形容BAT春晚紅包戰(zhàn)背后的云計算技術(shù)戰(zhàn)再合適不過了。每年的春晚紅包戰(zhàn)似乎成了BAT的正面戰(zhàn)場，三巨頭呼風喚雨，在短時間內(nèi)把紅包、福利全都撒出去。

大家明面上能看到是三家發(fā)了多少紅包、撒了多少現(xiàn)金，背后牽扯到的技術(shù)、資源等配置確是錯綜復(fù)雜。

從2014年春節(jié)，騰訊就因為“紅包”太受歡迎遇到了技術(shù)上的“驚險一刻”。2016年、2017年、2018年騰訊、阿里紛紛在云計算戰(zhàn)場投入重兵把分布式計算、線上智能容災(zāi)這些技術(shù)不斷普及并逐漸提高。

為支持春晚項目，百度再一次技術(shù)進化，讓全自動自如擴容縮容，技術(shù)體系彈性容器設(shè)計，智能調(diào)度系統(tǒng)智能感知不同地區(qū)資源緊張程度成為日常。

2019年春晚直播期間，百度APP紅包互動活動次數(shù)達208億次。蘋果APP Store、小米應(yīng)用商店、華為應(yīng)用商店以及微信紅包都在春晚出現(xiàn)崩潰時刻的時候，百度APP歷經(jīng)208億次紅包互動反而沒倒。

崩潰不崩潰?這是個問題。BAT春晚紅包戰(zhàn)背后暗暗較勁的正是云計算技術(shù)。它如正面戰(zhàn)場背后的情報戰(zhàn)一樣，看不見摸不著，但卻往往起到了決定作用。

春晚“驚險一刻”，家家都要應(yīng)對

2017年年初，我當時在一家媒體工作時，曾經(jīng)和騰訊FIT(騰訊支付基礎(chǔ)平臺與金融應(yīng)用線)春晚紅包技術(shù)負責人聊過紅包戰(zhàn)背后的技術(shù)問題。2014年春節(jié)前十幾天，騰訊春節(jié)紅包團隊為活躍新年氣氛，想到要在微信里加入搶紅包功能。一個大約10 人，隸屬于騰訊FIT技術(shù)部門的核心團隊主導(dǎo)了開發(fā)過程。

春節(jié)紅包正式上線前，團隊內(nèi)測時便發(fā)現(xiàn)，這個“小功能”使用人數(shù)遠遠超過預(yù)期：從廣州等一線城市開始，發(fā)紅包的習(xí)慣逐漸擴展到二、三、四線城市，直至全國。數(shù)據(jù)增長得“驚心動魄”，春節(jié)紅包團隊每天都要忙著給紅包系統(tǒng)擴容。

春節(jié)紅包團隊當時隱隱覺得，除夕夜可能會出問題，“用戶增長量太大了，這個功能一開始架構(gòu)就是按照小系統(tǒng)來設(shè)計的，但臨時改動已經(jīng)來不及了。”

墨菲定律中有這樣一條：如果你擔心某種情況發(fā)生，那么它就更有可能發(fā)生。

1月28日，除夕前倒數(shù)第二天那個下午，“新年紅包”的圖標第一次出現(xiàn)在“我的銀行卡”界面中，微信紅包潮隨即引爆全國。

驚險瞬間在除夕夜一觸即發(fā)，春節(jié)紅包團隊迅速啟動了過載保護。過載用戶想發(fā)紅包時，系統(tǒng)會提示“當前系統(tǒng)繁忙”。除夕夜還在加班的程序員們就像是交警一樣，在一條堵死的十字路口上不斷控制流量。

幸好，當時騰訊FIT技術(shù)團隊臨時調(diào)來了10倍于原設(shè)計數(shù)量的服務(wù)器，最終有驚無險地扛住了考驗。

此一役后，安全、容災(zāi)、性能成了每個春節(jié)紅包團隊需要長期考慮的問題。在2016年以后，騰訊FIT技術(shù)逐漸為春節(jié)紅包構(gòu)建了一套“多點多活、多地多中心”的分布式交易系統(tǒng)。

后來的微信紅包、支付寶紅包背后的云計算團隊每年都需要“一把屎一把尿”，不斷改進春晚紅包的技術(shù)框架，除夕這天加班加點避免紅包宕機。

創(chuàng)業(yè)邦在2017年就曾以《支付寶17年新春紅包技術(shù)體系剖析》一文介紹螞蟻金服技術(shù)團隊在春晚前的技術(shù)準備，其中這樣一段非常值得注意：

螞蟻金服在終端上采用了限流無感知、資源預(yù)下載、用戶操作數(shù)據(jù)緩存、開獎時間離散、數(shù)據(jù)項與開關(guān)動態(tài)配置等穩(wěn)定性操作;在服務(wù)端，進行了全鏈路梳理、全鏈路壓測、限流保護、應(yīng)急熔斷機制等。

百度今年也不例外。2019年1月4日收到百度春晚要發(fā)紅包的消息后，百度技術(shù)團隊首先要想的問題是，如何搭建春晚紅包的技術(shù)框架，原因很復(fù)雜。

百度APP不像微信是個日常應(yīng)用，它是一個剛需但低頻的工具型APP，用戶用完即走，不會保持長時間在線。但在春晚期間，用戶搶紅包、集卡會使得使用時長、操作頻次大大提高。

同時，春晚紅包涉及百度數(shù)十個產(chǎn)品、數(shù)百個操作場景，這會給百度APP帶來高并發(fā)、大流量，同時給百度云的服務(wù)器、帶寬等技術(shù)基礎(chǔ)設(shè)施帶來巨大沖擊。后果可能是用戶打開百度APP緩慢，無法登錄賬號，點擊界面無反應(yīng)，甚至白屏，更別說搶紅包。

因此，百度技術(shù)團隊需要梳理的問題很多，甚至比騰訊FIT、阿里云團隊更要繁瑣：

1、需要針對本次春晚的突發(fā)需求，讓外網(wǎng)骨干網(wǎng)可以支撐大帶寬快速接入;

2、技術(shù)方案確定后，還要解決資源供應(yīng)問題。比如要在2周內(nèi)采購到貨3000臺服務(wù)器。還需要運營商資源為百度核心IDC提供近10T帶寬和數(shù)十個CDN節(jié)點等資源;

3、準備時間過短引發(fā)運營商資源提供方面的許多問題，比如商務(wù)部門需要和50多個城市的CDN運營商資源緊急談判;

4、外部對接結(jié)束之后，內(nèi)部技術(shù)團隊還需要進行資源部署、系統(tǒng)聯(lián)調(diào)、壓力測試。

可以說，2019年以前，幾乎每一個春晚紅包團隊，都會遭到煉獄一般的技術(shù)考驗，從騰訊到阿里無一幸免。然而，2019年春晚，百度APP的“零宕機”紀錄是互聯(lián)網(wǎng)公司的首創(chuàng)。

你開心搶紅包時，程序員卻在心驚膽戰(zhàn)

春晚時，每一個人都在開心搶紅包。你以為只是頁面偶爾卡頓了一下、網(wǎng)絡(luò)延遲了1秒，實際上背后有著無數(shù)個技術(shù)團隊的“緊張時刻”。每一個程序員都是心驚膽戰(zhàn)，時時刻刻準備著對系統(tǒng)進行搶救。

對于2019年的春晚紅包而言，期間也是考驗頻頻，而背后的百度技術(shù)團隊總算讓這場紅包狂歡有驚無險。

簡單說，春晚紅包帶來的技術(shù)難點基本是這幾個：不可預(yù)見的峰值流量瞬間涌入，紅包系統(tǒng)架構(gòu)復(fù)雜帶來了協(xié)調(diào)成本，春節(jié)返鄉(xiāng)導(dǎo)致地區(qū)間流量資源分配要臨時調(diào)整。

1、不可預(yù)見的峰值流量瞬間涌入

淘寶春晚項目技術(shù)負責人此前在2018年春晚淘寶多次崩潰時曾出面解釋其中的原因——我們真的對春晚的力量一無所知。

以2018年春晚為例，當時淘寶是那年春晚的主角，主要策略是綁親情賬號、發(fā)紅包。技術(shù)團隊很早就預(yù)估到了登錄系統(tǒng)壓力。當時基于一些歷史數(shù)據(jù)推導(dǎo)出了極端情況，最終決定以2017年雙十一的容量為基礎(chǔ)，對登錄數(shù)擴容3倍。

結(jié)果，春晚當晚登錄的實際峰值超過了2017年雙十一的15倍，尤其新用戶的瞬時登錄更是完全超出預(yù)料。

可以說，互聯(lián)網(wǎng)公司上春晚，等于是往下沉市場扔了一顆炸彈——這一次據(jù)百度技術(shù)部門統(tǒng)計，春晚期間登錄值可達到日常用戶登錄峰值的2500倍。

大量用戶在同一時間發(fā)、搶紅包、點頁面，瞬間產(chǎn)生每秒千萬級，甚至億級的請求，請求如果不加以疏導(dǎo)處理直接到達后臺，會導(dǎo)致服務(wù)過載甚至崩潰。

為完成今年春晚的高并發(fā)流量考驗，百度提前進行服務(wù)流量隔離、系統(tǒng)升級、專線新增以及服務(wù)器擴容等工作，完善流量峰值時段的體驗，還進行了多輪全鏈路壓力測試和多輪的方案預(yù)演。

今年春晚百度APP也的確相對平穩(wěn)，沒有出現(xiàn)崩潰的情況。

2、紅包系統(tǒng)架構(gòu)復(fù)雜帶來了協(xié)調(diào)成本

和淘寶注冊、登陸系統(tǒng)還不一樣，注冊登陸一般只有一次響應(yīng)，注冊登陸之后響應(yīng)就結(jié)束了。今年百度的紅包系統(tǒng)更多是支付系統(tǒng)，支付系統(tǒng)的響應(yīng)次數(shù)往往是多次的，而且表面上看，一個紅包從發(fā)出到搶到時間不足一秒，但背后是在紅包業(yè)務(wù)系統(tǒng)、交易支付系統(tǒng)、零錢賬戶系統(tǒng)這三個層級之間游走——它需要多方提前溝通測試。

因為一個紅包如果是通過銀行卡發(fā)出，必須要先向銀行提出申請，銀行會進行扣款，扣款成功后，后臺會通知支付系統(tǒng)，紅包系統(tǒng)到這時才會把紅包放出。在其他用戶搶到紅包后，又會以零錢形式進入用戶賬戶中。

紅包幾秒鐘現(xiàn)金出出進進，都需要耗費服務(wù)器資源，由于資金頻繁進出銀行，部分銀行的技術(shù)能力又非常有限，百度也需要和銀行前期協(xié)調(diào)，進行承壓測試。

百度工程效率部對用戶剛登錄APP時的內(nèi)容加載進行了優(yōu)化。后臺系統(tǒng)還會自動檢測流量變化，快速計算資源，智能調(diào)度早已準備好的冗余資源，增加系統(tǒng)容量，合理分配帶寬。這些措施可以讓數(shù)億級用戶同步登錄APP，正常加載服務(wù)，不出現(xiàn)白屏。

3、春節(jié)返鄉(xiāng)導(dǎo)致地區(qū)間流量資源分配要臨時調(diào)整

搶紅包的指令是從全國不同地區(qū)下達的，服務(wù)器還需要根據(jù)不同地區(qū)進行響應(yīng)。

百度系統(tǒng)部一位負責人就提到，因為回家過年，網(wǎng)民會從一線城市下沉到三四線城市。這使得流量結(jié)構(gòu)發(fā)生改變，DC數(shù)據(jù)中心和CDN帶寬不得不進行調(diào)整。

阿里云2017年也曾遇到過這個問題，當時的解決方案還相對簡單。螞蟻金服技術(shù)專家天鏡飛在2017年的一場活動中就曾提到阿里是如何應(yīng)對流量結(jié)構(gòu)變化這個問題的：

華東1機房和華南機房分別承擔40%和60%的流量，并且它們都是非云的機器。在新春紅包業(yè)務(wù)上，支付寶將60%的流量切到華東2機房中，并且將其上云。此外，在華南機房會部署15%的云機器。也就是說，新春紅包業(yè)務(wù)中，75%的機器是在云上運行的，在活動結(jié)束后，流量又會切出。

不過，百度吸取前人教訓(xùn)后，把這種應(yīng)對策略進行了改進調(diào)整：提前規(guī)劃好了不同地區(qū)的所需要的網(wǎng)絡(luò)資源。通過智能調(diào)度系統(tǒng)，分鐘感知不同地區(qū)資源緊張程度，并進行相對應(yīng)的資源調(diào)度和補給。也就是說，流量資源調(diào)度分配更智能了。

在這個系統(tǒng)中，整個體系就像一個彈性容器，可以全自動自如擴容縮容。

云計算從“雙十一時代”邁向“春晚時代”

2014年-2019年這6年間，BAT應(yīng)對春晚紅包的技術(shù)一直處于進步之中。

從最早的懵懵懂懂、毫無認知，對技術(shù)難點預(yù)估不足，到后來每年都會提前做好準備，但依舊要靠熔斷機制來限制流量。再到今天限制為輔，分布式、自動化、智能化為主，云計算技術(shù)不斷在演進之中。

1、分布式：紅包系統(tǒng)可適性強。高度靈活，能應(yīng)對多種不同環(huán)境。某個部件發(fā)生突變，不會影響整個系統(tǒng)。在某些部件失效的情況下，仍然能夠應(yīng)對響應(yīng)，抗風險能力高。

2、自動化：基于需求預(yù)期和流量模式進行自動合理規(guī)劃，不需要太多人工干預(yù)，保持相對較低的運營成本。

3、彈性化：可彈性擴展的資源用量，在高峰期可以根據(jù)需求按需所取、彈性分配，系統(tǒng)如同彈簧一般可以根據(jù)用戶搶紅包的需求來自動分配資源。

百度使用這樣的技術(shù)架構(gòu)中，使得整個技術(shù)保障體系就像一個彈性容器，可以全自動自如擴容縮容。當遇到流量洪峰時，系統(tǒng)智能化調(diào)度，快速接入帶寬資源，據(jù)用戶任務(wù)的不同，匹配適應(yīng)的容量。

凱文凱利在《失控》一書中曾提到蜂群的一個特征：

蜂群的能力不會因為其中幾個成員的損失而喪失機能……必須從簡單的局部控制中衍生出分布式控制，必須從已有運作良好的簡單系統(tǒng)上衍生出復(fù)雜系統(tǒng)。

這段話拿來形容春晚紅包這幾年來的技術(shù)演進再恰當不過了。

在當年的雙十一時代，互聯(lián)網(wǎng)公司的云計算基礎(chǔ)設(shè)施用來應(yīng)付每年一度活動期的瞬時高峰流量，但畢竟運用電商的人還是有限的。在如今的春晚時代，流量有了數(shù)十倍的增長，互聯(lián)網(wǎng)公司需要更龐大的云計算基礎(chǔ)設(shè)施來應(yīng)對。

正如我在《春晚紅包宕機史，也是半部中國互聯(lián)網(wǎng)技術(shù)進步史》中所說的：

春晚的流量規(guī)模，未來可能正是5G和物聯(lián)網(wǎng)時代的“常規(guī)需求”。提前排兵布陣，百利無一害。

要知道，2018年全球有70億臺IoT 設(shè)備，有機構(gòu)預(yù)測到2020年全球?qū)⒂?00億臺設(shè)備同時連接網(wǎng)絡(luò)，2023年則是有790億設(shè)備連接到物聯(lián)網(wǎng)。5G時代流量每小時所產(chǎn)生的數(shù)據(jù)高達數(shù)百GB，預(yù)計將處理比4G多1000倍的數(shù)據(jù)。

春晚紅包的挑戰(zhàn)，正是提前練兵的好時機。這場看不見的云計算戰(zhàn)爭，推動了中國互聯(lián)網(wǎng)技術(shù)整體演進。

如果說過去的云計算還停留在“雙十一時代”。BAT歷經(jīng)的春晚紅包戰(zhàn)之后，云計算正在邁向“春晚時代”。