云計算的春節戰場：從“人肉”到智能
春晚紅包就像是一只推門的手，門外是未知，門內是創新。
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 小試牛刀，注定是整個行業的紅利。
評論
評論
推薦評論
暫無評論哦，快來評論一下吧！
全部評論（0條）