雲端計算的春節戰場：從“人肉”到智慧
編者按：本文來自微信公眾號Alter Pro，作者Alter，創業邦經授權轉載。
春晚紅包就像是一隻推門的手，門外是未知，門內是創新。
2015年，微信成為央視春晚的座上賓，全民“搖一搖”的紅包雨，讓電子紅包成為春節的新習俗；
2016年，支付寶成為春晚紅包的合作方，往年討論的是有什麼新節目，那一年的話題是敬業福和“咻一咻”。
2019年，百度“承包”起豬年春晚的紅包，全球觀眾參與互動紅包次數達208億次，百度系App成為今年紅包大戰的最大贏家。
今年的春晚也是百度雲的一次大練兵，此前從未經歷過如此大規模的流量峰值，簡單的“搶紅包”背後存在三個技術挑戰：如何處理極大的臨時使用者登入量，如何應對瞬時出現的流量峰值，以及如何解決短期的巨大資源需求？
在四個多小時的春晚過程中，一些第三方應用商店紛紛崩潰，百度App沒有出現宕機現象，成為第一個扛住春晚紅包衝擊的網際網路公司，百度雲近乎完美的結束了這場戰役。
搶紅包的“絲滑”體驗
在海量業務併發的場景裡，任何小問題都可能成為大隱患，原生的技術難點無疑是運維的深淵。
不同於往年的是，百度還推出了AI新玩法，語音搜一搜、與明星同框拜年等，多樣性的玩法也在考驗百度雲的AI能力。所幸，在整個春晚的過程中，百度系App的體驗足以用“絲滑”來形容：
晚上8點40分，主持人喊出“搶紅包開始”的口令時，參與“搖一搖”得紅包的使用者數迅速過億，3億元紅包隨後被搶光。僅在第一輪“搖一搖”紅包中，參與紅包互動就多達92億次。
為了應對第一波流量高峰，百度春晚技術保障部門對登入時的內容載入進行了優化。對於搶紅包活動中的出現的瞬間流量洪峰，後臺會自動檢測變化，快速計算資源需求，智慧排程增加系統容量，進行合理的頻寬分配。除此之外，百度雲在20天的專案籌備期內將簡訊承接能力至少提升了數十倍。還與運營商合作，在雲上部署了一鍵登入功能，減輕大量使用者在第一輪對登入系統的壓力。
晚上21點18分，第二輪小視訊紅包開始，互動次數隨即增加到115億次，對伺服器頻寬有著極為苛刻的考驗。
為了保證小視訊紅包的使用者體驗，百度進行了兩手準備：一是技術上的優化，對視訊、圖片進行極致壓縮，儘可能降低頻寬壓力；二是提前規劃佈局和建設網路資源，比如IDC和CDN在三個禮拜的時間內完成了相當於2018年全年的建設量。此外通過智慧排程系統，分鐘感知不同地區資源緊張程度，進行相應的資源排程和補給。
晚上22點40分，第三輪的搜尋的得紅包正式啟動，此輪互動還加入了語音搜尋的互動玩法。截至23：00，全球觀眾參與百度APP紅包互動次數累計增加到137億次。
晚上23點30分，最後一輪搖一搖得紅包活動開啟，使用者積極性較第一輪有所削弱，依然有超過70億次互動產生。
最終統計資料顯示，除夕當天百度提供了4輪9億紅包，全球觀眾參與互動活動次數達208億次，APP的DAU峰值突破3億。
春晚紅包不宕機的背後是百度春晚技術保障部門提前一個多月的周密規劃和準備，每個風險點都匹配了相應的技術解決方案。
比如在擴容IT資源方面，提前規劃佈局和建設網路資源。而且在時間緊任務重的壓力下，北京順義華威機房在8小時內完成了10000臺伺服器的物理上架，16小時完成自動化上線交付業務使用，創造了業界伺服器交付速度的新紀錄。在技術實力之外，體現了百度工程師們高效的執行能力。
智慧架構戰勝“人肉”
從2015年央視春晚引入紅包的玩法開始，幾乎所有的網際網路巨頭都在搶奪紅包活動的承辦權，但並非所有玩家都似百度這般“幸運”。
站在春晚紅包身後的“惡魔”正是宕機，以至於流傳著這樣一個說法：在春晚上投廣告的最低門檻是日活過億，否則伺服器很可能會瞬間崩掉。
早在2015年微信和春晚的合作中，就出現了多次宕機的情況：當晚九點左右微信出現了短暫的宕機，春晚過程中有1.2億個紅包送出，但也有不少網友在社交網路上反映卡頓、訊息無法接收、紅包發不出去等等。
2016年支付寶拿下春晚合作機會，除夕夜紅包活動的總參與人數達到3245億次，達到2015年春晚互動次數的29.5倍，同樣也出現了宕機時刻。
到了2018年，春晚宕機事件已經多次告警，合作方淘寶也提前推導了各自極端情況，並且在2017年雙11的基礎上擴容三倍。結果卻是，不少網友吐槽無法登入註冊、繫結親情號失敗、不能組團搶紅包等，經歷過數次雙11挑戰的阿里雲，也倒在了春晚的流量高峰面前。後來公佈的資料顯示，春晚當晚的流量峰值是2017年雙11的15倍。
宕機的頻繁發生，並非是騰訊、阿里沒有“一級警備”，相反往往要投入幾百人的技術保障團隊。春晚紅包是網際網路巨頭們爭奪的物件，也是雲端計算的春節戰場，所謂的宕機史，也是雲端計算的進化史。
坊間流傳最廣的無疑是阿里雙11的故事，早幾年的後臺保障也普遍被戲稱為“人肉”計算。比如2010年以前，網際網路公司普遍採用的是IOE系統，IBM的小型機配合Oracle資料庫和EMC的儲存裝置。為了一場雙11大考，從年初準備到年尾，可憐最後可能連及格的分數都沒有。
一位經歷過雙11的程式設計師，形象的還原了那個運維全靠吼、擴容全靠“殺掉”非關鍵系統的年代：“雙11那一天，每個人看自己伺服器的系統水位，出現問題吼一嗓子，哪裡有空閒的資源調過來，後來容量不夠，又把一些非關鍵系統殺掉。”
再來看百度雲在今年春晚的保障，系統隨時響應每秒數千萬的請求，並支援快速擴充套件支援更多請求處理，智慧取代了“人肉”。有百度技術人員打了一個形象的比方：“整個體系就像一個彈性容器，全自動自如擴容縮容。當遇到流量洪峰時，系統會智慧排程，快速接入頻寬資源，按照使用者任務的不同，匹配適應的容量。”
同時在基礎設施層面，百度雲的大放異彩與百度早已成熟的網路架構有關。過去十多年，百度網路架構經歷了自有業務規模快速增長和To B業務多樣需求的考驗，具有很好的高可擴充套件性和靈活性，可以快速調配伺服器，支撐快速接入頻寬資源，排程系統可以很好的支撐節點的快速擴容，極大的提升了保障服務的可用性和運維效率。
任何奇蹟的出現都離不開背後的努力，春晚紅包也不例外。
AI To B 小試牛刀
每一場實戰，都是對網際網路基礎設施的一個大考，也是技術迭代的跳板。
正如很多人的觀點，沒有“黑五”過剩的計算資源，就沒有亞馬遜押注雲端計算的決心，沒有雙11、618這樣的電商狂歡節，或許中國雲端計算的爆發還需要多等幾年。同樣的例子也出現在雲端計算的春節戰場上，首次迎戰的百度雲就交出了百分答卷，印證了百度躋身雲端計算一線陣營的地位，也讓百度的對話式搜尋、自然語言處理等AI能力曝光在鎂光燈下。
我想，其中的受益者不會侷限在百度系App，2018年9月份的百度雲智峰會上，正式對外推出了兼具深度學習、對話式搜尋、自然語言處理等全面AI能力的AI to B平臺，並通過雲服務框架整合在AI、大資料、雲端計算方面的能力，幫助企業快速接入雲端獲取AI能力。
中國網際網路上有很多流派，百度恰恰是技術派的典型代表，不宕機的春晚紅包，將百度的技術能力完美呈現。而在技術層面的較量背後，一場春晚紅包讓百度雲的AI To B 小試牛刀，註定是整個行業的紅利。
本文為專欄作者授權創業邦發表，版權歸原作者所有。文章系作者個人觀點，不代表創業邦立場，轉載請聯絡原作者。如有任何疑問，請聯絡[email protected]。