2007年，國內情報史專家高金虎出版過一本《看不見的第二戰場》，講述無線電情報與戰爭的關係。“看不見的第二戰場”，這段話拿來形容BAT春晚紅包戰背後的雲計算技術戰再合適不過了。每年的春晚紅包戰似乎成了BAT的正面戰場，三巨頭呼風喚雨，在短時間內把紅包、福利全都撒出去。

大家明面上能看到是三家發了多少紅包、撒了多少現金，背後牽扯到的技術、資源等配置確是錯綜複雜。

從2014年春節，就因為“紅包”太受歡迎遇到了技術上的“驚險一刻”。2016年、2017年、2018年騰訊、阿里紛紛在雲計算戰場投入重兵把分佈式計算、線上智能容災這些技術不斷普及並逐漸提高。

為支持春晚項目，百度再一次技術進化，讓全自動自如擴容縮容，技術體系彈性容器設計，智能調度系統智能感知不同地區資源緊張程度成為日常。

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

崩潰不崩潰？這是個問題。BAT春晚紅包戰背後暗暗較勁的正是雲計算技術。它如正面戰場背後​​的情報戰一樣，看不見摸不著，但卻往往起到了決定作用。

春晚“驚險一刻”，家家都要應對

2017年年初，我當時在一家媒體工作時，曾經和騰訊FIT（騰訊支付基礎平台與金融應用線）春晚紅包技術負責人聊過紅包戰背後的技術問題。2014年春節前十幾天，騰訊春節紅包團隊為活躍新年氣氛，想到要在微信裡加入搶紅包功能。一個大約10人，隸屬於騰訊FIT技術部門的核心團隊主導了過程。

春節紅包正式上線前，團隊內測時便發現，這個“小功能”使用人數遠遠超過預期：從廣州等一線城市開始，發紅包的習慣逐漸擴展到二、三、四線城市，直至全國。數據增長得“驚心動魄”，春節紅包團隊每天都要忙著給紅包系統擴容。

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

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

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

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

幸好，當時騰訊FIT技術團隊臨時調來了10倍於原設計數量的服務器，最終有驚無險地扛住了考驗。

此一役後，安全、容災、性能成了每個春節紅包團隊需要長期考慮的問題。在2016年以後，騰訊FIT技術逐漸為春節紅包構建了一套“多點多活、多地多中心”的分佈式交易系統。

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

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

螞蟻金服在終端上採用了限流無感知、資源預下載、用戶操作數據緩存、開獎時間離散、數據項與開關動態配置等穩定性操作；在服務端，進行了全鏈路梳理、全鏈路壓測、限流保護、應急熔斷機制等。

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

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

同時，春晚紅包涉及百度數十個產品、數百個操作場景，這會給百度APP帶來高並發、大流量，同時給百度雲的服務器、帶寬等技術基礎設施帶來巨大衝擊。後果可能是用戶打開百度APP緩慢，無法登錄賬號，點擊界面無反應，甚至白屏，更別說搶紅包。

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

1、需要針對本次春晚的突發需求，讓外網骨幹網可以支撐大帶寬快速接入；

2、技術方案確定後，還要解決資源供應問題。比如要在2週內採購到貨3000台服務器。還需要運營商資源為百度核心IDC提供近10T帶寬和數十個CDN節點等資源；

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

4、外部對接結束之後，內部技術團隊還需要進行資源部署、系統聯調、壓力測試。

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

你開心搶紅包時，程序員卻在心驚膽戰

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

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

簡單說，春晚紅包帶來的技術難點基本是這幾個：不可預見的峰值流量瞬間湧入，紅包系統架構複雜帶來了協調成本，春節返鄉導致地區間流量資源分配要臨時調整。

1、不可預見的峰值流量瞬間湧入

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

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

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

可以說，互聯網公司上春晚，等於是往下沉市場扔了一顆炸彈——這一次據百度技術部門統計，春晚期間登錄值可達到日常用戶登錄峰值的2500倍。

大量用戶在同一時間發、搶紅包、點頁面，瞬間產生每秒千萬級，甚至億級的請求，請求如果不加以疏導處理直接到達後台，會導致服務過載甚至崩潰。

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

今年春晚百度APP也的確相對平穩，沒有出現崩潰的情況。

2、紅包系統架構複雜帶來了協調成本

和淘寶註冊、登陸系統還不一樣，註冊登陸一般只有一次響應，註冊登陸之後響應就結束了。今年百度的紅包系統更多是支付系統，支付系統的響應次數往往是多次的，而且表面上看，一個紅包從發出到搶到時間不足一秒，但背後是在紅包業務系統、交易支付系統、零錢賬戶系統這三個層級之間遊走——它需要多方提前溝通測試。

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

紅包幾秒鐘現金出出進進，都需要耗費服務器資源，由於資金頻繁進出銀行，部分銀行的技術能力又非常有限，百度也需要和銀行前期協調，進行承壓測試。

百度工程效率部對用戶剛登錄APP時的內容加載進行了優化。後台系統還會自動檢測流量變化，快速計算資源，智能調度早已準備好的冗餘資源，增加系統容量，合理分配帶寬。這些措施可以讓數億級用戶同步登錄APP，正常加載服務，不出現白屏。

3、春節返鄉導致地區間流量資源分配要臨時調整

搶紅包的指令是從全國不同地區下達的，服務器還需要根據不同地區進行響應。

百度系統部一位負責人就提到，因為回家過年，網民會從一線城市下沉到三四線城市。這使得流量結構發生改變，DC數據中心和CDN帶寬不得不進行調整。

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

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

不過，百度吸取前人教訓後，把這種應對策略進行了改進調整：提前規劃好了不同地區的所需要的網絡資源。通過智能調度系統，分鐘感知不同地區資源緊張程度，並進行相對應的資源調度和補給。也就是說，流量資源調度分配更智能了。

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

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

2014年-2019年這6年間，BAT應對春晚紅包的技術一直處於進步之中。

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

1、分佈式：紅包系統可適性強。高度靈活，能應對多種不同環境。某個部件發生突變，不會影響整個系統。在某些部件失效的情況下，仍然能夠應對響應，抗風險能力高。

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

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

百度使用這樣的技術架構中，使得整個技術保障體係就像一個彈性容器，可以全自動自如擴容縮容。當遇到流量洪峰時，系統智能化調度，快速接入帶寬資源，據用戶任務的不同，匹配適應的容量。

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

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

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

在當年的雙十一時代，互聯網公司的雲計算基礎設施用來應付每年一度活動期的瞬時高峰流量，但畢竟運用電商的人還是有限的。在如今的春晚時代，流量有了數十倍的增長，互聯網公司需要更龐大的雲計算基礎設施來應對。

正如我在《春晚紅包宕機史，也是半部中國互聯網技術進步史》中所說的：

春晚的流量規模，未來可能正是5G和物聯網時代的“常規需求”。提前排兵布陣，百利無一害。

要知道，2018年全球有70億台IoT 設備，有機構預測到2020年全球將有500億台設備同時連接網絡，2023年則是有790億設備連接到物聯網。5G時代流量每小時所產生的數據高達數百GB，預計將處理比4G多1000倍的數據。

春晚紅包的挑戰，正是提前練兵的好時機。這場看不見的雲計算戰爭，推動了中國互聯網技術整體演進。

如果說過去的雲計算還停留在“雙十一時代”。BAT歷經的春晚紅包戰之後，雲計算正在邁向“春晚時代”。（本文首發鈦媒體）文｜吳俊宇