04 年貨節時間節點開啟了(等了八年，春晚輪到京東)

不多在一小時內，春晚有七輪口播則意味著有七次潮涌式超大峰值。根據預測數據顯示，春晚的流量峰值差不多是618、雙十一的數十倍。以去年的春晚為例，相關數據統計，全球約12.72億人觀看了春晚，期間累計產生紅包互動達700多億次，并且在數十秒內，有數十億甚至數百億人次（累計）參與互動點擊，形成數億級別的QPS流量洪峰，因此這非常考驗平臺的承載力和穩定性。

常規紅包互動的高并發已經是全球最大規模的網絡互動，更何況還疊加了京東的“年貨春運”，可謂是春晚史上的 歷史 性突破——這是第一次打破基于全程虛擬互動的春晚玩法，“從虛到實”的把線上線下場景結合進來——誠然，物流效率是京東無可比擬的絕對優勢，但在如此關鍵的時點，如此生猛的給自己加難度，還是讓人瞠目。

因為，這堪稱世界級的龐大而復雜的供應鏈應用場景，涉及了前端網站、訂單、結算、支付、搜索、推薦，還有后端的倉儲、配送、客服、售后等諸多業務系統，并且都需要依托京東云的技術支撐，每一個鏈路環節的增加，對春晚場景的復雜度和應對難度都是指數級的增長。

因此，2022年的虎年春晚，成為了全球規模最大、場景最復雜、周期最長，同時籌備時間又最短的活動之一。

多年以來，人們很少把京東和“技術”這個符號聯系在一起，雖然劉強東在2018年曾經喊話——未來，京東只有三樣東西:技術!技術!技術!

但是，這依舊讓人們擔心，京東的技術平臺是否能從支撐內部業務延展到能接下來春晚這個超大流量和復雜場景。

今年的春節期間，京東人忙壞了，要備戰春晚，還有年貨節以及冬奧期間的物流保障。而最大的挑戰，是如何在現有的資源配置下，應對4小時的春晚幾億觀眾同時參與的紅包、搶好貨的活動，再同時保證其他戰略級項目的絲滑運轉，要知道，總體備戰時間只有19天。

不重視顯然是不行的，由于整個春晚紅包互動項目任務急、挑戰大，場景復雜涉及的人員又多，京東拉通了數十個部門參與備戰，涉及京東零售、京東 科技 、京東物流等各BGBU。

更準確的說法是，京東集團技術體系有超3000名技術人員參與了春晚項目的技術攻關與保障工作，除夕當天參與一線值守的技術保障人員近2000人，超萬名技術人員協同作戰，支持跨度超過一個多月的年貨節、春晚等超級項目。

當然，到底是孤注一擲以贏得“技術京東”這塊金牌？還是早有把握渡過難關？筆者傾向于后者–—成功固然可喜可賀，但如果失敗則頗損美譽，京東輸不起也不能輸。

這里面的關鍵角色，是作為整個技術底座和動力引擎的京東云。

前段時間，京東云發布的業內首個混合多云操作系統云艦(JDOS)，實現了更大規模異構基礎設施的統一化調度，而京東云依托云原生基礎設施、混合云操作系統云艦，能夠根據場景的不同，快速變身滿足不同的業務需求。

其實，如果真正說希望借助春晚打開市場，那京東瞄準的也絕不僅僅是紅包流量帶來的消費級市場，而是增量空間更大的云計算市場。這個市場的目前已經有巨頭林立，如果要進入賽道的第一序列，春晚紅包互動這塊最硬的“試金石“是京東云必須磕下的硬仗。

的確多年以來，京東都扛住了618、雙十一等大促下的高并發流量洪峰，但畢竟是體系內的戰斗。京東云希望春晚可以證明——經歷過高壓復雜的超級應用場景“大考”之后，京東云的實力認可度將不局限于服務京東生態，可以延伸到行業層面。

然而春晚這個場景京東是第一次遇到，只有19天的備戰時間讓搞定這場硬仗多了一些緊迫。

從技術方面來看，往屆合作廠商應對高并發場景的萬無一失的辦法是增加服務器做到超級冗余。但如果僅僅靠此拿下大考，則技術含量大打折扣，因此京東云內部有了一個戰略性決定：在零增加服務器資源的情況下獨自支持春晚，而整體方案的設計上，將計算資源在搖紅包和購物兩個場景間來回切換。

也就是說，在虎年春晚紅包互動活動中，京東云需要高度彈性的控制著近300萬的容器、超過千萬核的資源，在購物和紅包互動的場景中來回切換，一個場景結束后，需要馬上把部分資源釋放到下個場景的應用上，也就是在不影響常規業務的前提下，將底層空間騰出來重構。

京東云敢這樣做是有底氣的。

在多年618、雙十一大促的歷練下，京東云習慣了用“備戰常態化”來降低大型活動對IT計算資源的集中消耗。也就是，京東一直通過大促的技術標準來提高日常技術標準，逐漸縮短研發的備戰時長，提高備戰的效率，還能以更少的人力、資源，達到更好的科學備戰效果。

因此，京東不缺高并發的業務場景，而云艦又能幫助京東云在不需要購置大量服務器的前提，能實現敏捷調度、平穩運行和高效協同，最終，如果順利的話，京東云能采用快速通過積木拆解和重組的方式搭建基礎設施，進而讓業務得以快速研發和部署。

京東云的信心來源之一，是作為電商巨頭而擁有超過1000萬種自營商品、幾十萬品牌商和制造企業，并服務了超過5.5億消費者的超級供應鏈，已經實現了全棧式的數智化技術連接，因此此次備戰春晚，京東將依靠豐富的經驗和系列運營保障機制，主要依靠系統而并非人力來確保關鍵節點的穩定性。

“剛接到這個任務的時候，其實我們是非常激動的，都有點發抖”， 京東云云艦架構師趙建星回憶說，剛聽到要做春晚互動項目的時候，瞬間想起多年前京東大促各種告急的時候，當時大家接到消息后就直接跑到機房里保障各種業務。

的確，京東是在大促環節結結實實摔過幾跤的，而電商節大促不僅檢驗企業的 科技 實力，也在考驗技術團隊。

2011年11月1日，京東做圖書限時促銷的活動，“秒殺”活動讓流量瞬間達到每秒10萬單，然而系統癱瘓了，總指揮直接請來負責當時IT前端的和后端的兩位副總裁到辦公室“喝茶”。

其實，這個段子并不是真的，但對于相關的負責人，還是有批評但也有寬容的。

和當年比起來，京東無論技術、體量、規模、用戶群體和現在都不是一個等級，如今接到如此重磅的任務對趙建星來說，意味著升級了武器再挑戰終極BOSS，他內心的感觸頗深。

趙建星團隊的任務之一，是在不降低日常商城業務模式的前提，保障年貨節和冬奧期間物流配送的資源支持，從資源角度對京東云來說，是歷年挑戰最大，對底層的資源調度和分發的壓力也是巨大的。

整體活動來看，是隨著春晚搖紅包的節奏，將整個資源在購物應用和搖紅包之間來回做切換，而這個切換核心是云艦對底層資源調度的能力。而且調度方面，搖紅包時間上是一分鐘，而很多資源的調度要求秒級到位，而后又要釋放給其他應用，這涉及到隔離性和容器化管理的精準調度能力。

“京東所有的業務系統都跑在云艦上，都是容器化的。”趙建星說，“這是我們的底氣。”

云艦管理的這個超大資源池，要支持年貨春運購物交易系統，還有春晚紅包互動系統，也有冬奧期間物流保障系統，在這幾個系統來回做保障，當期的業務資源需求量相當大。而且春晚的每輪口播產生的搖紅包場景，都伴隨著潮汐式的上億級流量高峰，因此在備戰春晚的過程中，趙建星帶著團隊做了很多根據業務場景交替來回切換資源的技術保障。

也就是在零增加服務器的情況下，通過快速調度資源支持業務場景的切換，得以短暫且高效地為春晚提供資源保障。

由于資源有限，需要將京東的整個業務進行等級調整、劃分、保障，針對不同的優先級和業務場景，分別進行不同的調度，有的升級有的降級。

趙建星表示，團隊幾乎每兩天一次壓測，不停地擴充和保障資源，再根據業務的協同和整個項目組的溝通，保障資源來回按需降級和恢復正常。

以春晚口播這個場景為例，首先口播紅包業務場景的優先級是最高的。

“每次口播都會來回切換。”當口播紅包的頂峰流量下來后，再將這些資源歸還到正常的業務系統中去。因此，在調度的過程中業務系統數量相當龐大，調度的過程也需要針對所有的業務系統進行一些定級精致化的分類。

盡管多年618、雙十一大促的經驗下京東不缺高并發的場景，然而從來沒做過如此大規模、高密度、高精度的調度，同時需要在秒級完成調度，這無疑來說對京東云具有極高的挑戰。

“整體來說，規模量、快速調度的精準性、高密度隔離性，對我們來說都是極大的挑戰。”趙建星表示。

其中，穩定性是最高優先級，資源的騰挪必須高效，同時，各業務間還要具有很高的隔離性。由于盡可能全部由自動化實現，總體超過80%的調度速度都在秒級，S級項目必須是秒極完成，所有預案都是分鐘級完成。

而趙建星帶著團隊，通過秒極完成全部資源的管理與統一調度，最終保障了春晚4小時互動項目里系統最穩、敏捷度最高、成本最優。

“京東云的春晚保障是想把人算做到極致，去迎接天算的考驗。”

常亮是京東云春晚項目組IDC基礎保障1號位，對于他們團隊來說，作為整個項目的基礎建設部分，從最前端到最后端都要做技術保障，所有的前中臺，包括云底座都會落在數據中心、網絡和硬件上這三大件上，“哪個部分發生一丁點的抖動，再精彩的內容都會受到影響。”

因此，京東要將所有的需求劃定在可控范圍內。

常亮回憶，1月13日團隊就確定不再承接新的需求，盡管資源不夠，但是需求已在可控范圍內，有了明確的邊界和框架和天花板，所有的工作就能被精準、精細地落地和執行下去了。因此，理論上每次的壓測結果和十次結果都一樣，用計算機學的術語就是系統越趨近于冪等性，所得的結果都可預期。

那么天算呢？

面對突發的未知情況，靠的是快速響應，同時需要兜底方案、需要預演，要靠一個完備的組織和決策機制，因為現實情況是，一號位、核心接口入場可能要在3-5分鐘這樣的極致時間里做決策，要通過這種方式應對各個環節發生的問題。

所以說，只要在需求確定的情況下，無論突發情況是什么，都可以應對自如。

比如，1月6日、1月7日，常亮帶領團隊開始做了第一次的壓測，直到1月22日進行了七次壓測，當時所有的流量模型都固定了，然而在23日預演的時候發現，有諸多需要修改的地方，這會給CDN帶來什么直接后果呢？此前做的流量模型全部作廢、重新做。

常亮表示，原始數據的由來，是將所有業務線，從前臺，包括從零售、 健康 、物流、 科技 等所有業務線的需求進行優先級和主次、分層圈定，因此一旦加了修改，首先遇到的問題就是，有些業務要犧牲了，舍誰保誰是個很大的問題。

常亮坦言，一旦出現涉及到資源的臨時需求，就要看能否人定勝天。具體來看，如果還有10天的時間，把相應的元素包全部替換、預置在手機里就行了，如果只有5天的時間，重做一款APP，審核時間是不可控的。

而為了更好地解決應急挑戰，京東也首創了“應急劇本預案”模式，重點排查和預防TOP 級困難。而整個劇本涉及了從前臺、中臺、后臺，包括安全，包括基礎設施三大塊，所有涉及到春晚支持的應急演練劇本。

常亮分享了一個有趣的故事，核心劇本里有個情節，就是流量峰值的時候，兩個機房間的網絡專線之間如果出現堵塞或中斷問題，系統會是什么樣子？

“當時我們的劇本很簡單，就是在這種場景下，誰是網絡組的負責人，誰做專線切換操作，要多少時間生效... ...”常亮表示，當時大家按照劇本是執行完了，結果每五分鐘出現一個掉坑，大家就不理解這種規律性抖動到底是怎么回事。

經過兩個小時的排查發現，其實是三個不同的原因恰好卡在了每五分鐘的一個時間點上，第一個坑因為網絡線路中斷引起了抖動，第二次因為中臺的容器在沒溝通的前提做了loc

很赞哦!（572）