快手基礎架構演進:如何支撐春晚紅包極端流量場景

2020 年除夕,作爲 BAT 以外第一家扛起春晚戰旗的互聯網公司,快手在當天的春晚紅包活動中,紅包互動總量達到 639 億次,創春晚史上最大的視頻點贊紀錄,紅包站外分享次數達到 5.9 億次。對於這場“大考”,InfoQ 此前曾經做過詳細報道:《春晚紅包:史上最難開卷考試,快手交卷了》。在春晚紅包這一極端場景背後,基礎架構團隊如何交付易於使用的高可用基礎組件和方案?如何模擬春晚流量進行預案、壓測?如何進行核心服務的擴容?

近日 InfoQ 記者採訪了快手基礎架構系統架構師王天舟,他也是此次 A1 項目(快手春晚紅包項目)基礎組件方面的負責人。就以上問題,他爲我們進行了詳細解答。王天舟在即將召開的 QCon 全球軟件開發大會(北京站)2020 上,將發表題爲《快手春晚活動基礎架構演進》的主題分享。

極端流量讓技術問題被放大

對於王天舟來說,春晚當天最讓他緊張的時刻是前兩輪口播。“按照往年 BAT 的經驗,這兩輪的壓力理論上是最高的。雖然我們經過模型推算和預測給出了分析,但是當流量真正來臨時,還是有一些緊張:如果我們之前的預測模型出現錯誤,實際流量超出預測流量,那麼我們就會非常被動,就需要啓動 Plan B 了。"不過最終結果是:”春晚當天峯值壓力來臨時,其實距離我們壓測容量還有差距。“

口播時候的突發性流量,其請求量要比正常服務高一個數量級以上,這就需要王天舟的團隊爲突發流量做額外的定製化設計——核心活動的架構設計也是此次 A1 項目最大挑戰之一

”口播瞬間觸發的量,如果用常規方式——每一個請求都在這一瞬間處理好,基本上是不可能的,有限的資源做不到這件事情。在這個情況下,我們採用了超高併發的架構設計理念——把核心請求進行預計算,然後提前預下發。“

在春晚紅包這樣極端流量加持下,很多技術問題會被放大。具體到此次春晚紅包的“視頻 + 點贊”發放形式,大家能夠想到的就是把視頻放到 CDN 上,讓 CDN 去扛流量。大多數公司也都具備這樣的成熟方案。但是這個方案放在此次春晚就行不通了。王天舟告訴我們:”當天主持人口播一瞬間,數億人同時用快手 App 看一條視頻,短視頻的播放流量是超過中國 CDN 總容量的,所以就需要去做額外的設計。“

快手選擇的設計方案是,提前把視頻預加載到 App 上。思路簡單,但真正做起來面臨的挑戰非常大。首先,什麼時候去做預下載、怎樣控制帶寬才能不影響用戶正常的體驗?其次,視頻有可能在春晚當天會變,怎麼應對變的情況?另外,預下載如何存在客戶端上不會被提前泄露;最後,預下載的覆蓋率如何把控:覆蓋率過低對緩解 CDN 壓力作用有限,覆蓋率過高對用戶的影響就會比較大。

基礎設施的架構能力經受考驗

2019 年,百度春晚的服務器數量是 10 萬臺,其中有 5 萬臺服務器是從百度核心的“鳳巢”廣告系統下讓渡而來。基於短視頻業務對服務器等基礎資源的更高要求來看,快手爲此次春晚活動準備的服務器數量不會低於百度。對於基礎架構團隊來說,硬件不僅考驗公司的採購以及部署能力,從另一個層面上,服務器從十到一百、一千、一萬、十萬… 更考驗基礎設施的架構能力。

對此王天舟解釋:”如果一個公司的架構演進過程是一個線性的緩慢演進的話,比如服務器是一批一批逐漸增長,那麼架構就可以進行漸進式迭代。但是如果像我們這次一樣,要用 2 個月時間去進行如此規模的服務器交付,尤其最後一個月,很多業務要跑在降級模式下,壓力和挑戰就會很大。不過還好最終我們架構都趕上了。“

據王天舟介紹,此次快手爲春晚採購的機器被分成了幾塊:一塊是交付給業務直接使用——全部使用容器的方式交互;另外一塊是緩存類、DB 類、中間件方面的公共資源組件,因爲採用了多租戶場景,按容量規劃去分配資源,不僅精確,而且利用效率也更高;此外還有極少數業務場景需要放到物理機上,沒有通過容器方式部署,這部分是另外一個場景,因爲運算密度高,所以這部分機器的容量也很容易察看。

扔一個猴子在機房,隨便敲

“不過準備工作再足,也無法完全模擬春晚當天的突發高流量,這意味着考驗我們的機會只有一次。”採訪中王天舟多次強調。在之前的準備工作中,快手準備了時間線預案(劇本)和緊急預案(觸發式),這些預案在元旦期間也都進行了完整的高擬真演練。

對於壓測,快手的做法是用混沌工程的理念做故障注入,核心思路是在包括單機、服務在內的所有服務器上隨機注入不同級別的故障,去模擬部分機器高負載、高延遲導致服務器宕機或半死不活的狀態,從而檢測高可用設計是否行之有效。

“我們在服務端架構設計當中有兩個指標,一個是容量,就是你是不是能扛住流量;另外一個就是在當前容量下,我們的架構設計是否能承受住硬件的損壞。”在王天舟看來,高可用設計其實驗證起來比較困難,因爲它好的時候就是好,出問題的時候,到底是完全不受影響,還是有一半掛掉,還是全掛了,都不確定。

“我們會根據硬件可能發生的故障頻率給出一個列表,單機故障是最容易發生的,其次是機架級別故障,再其次是整個機房級別的故障,包括大家最常見的光纖被拉斷的事情。我們按照一個發生概率去排,然後人工模擬這些故障,直接在我們機房裏隨機去調機器。”

就是扔一個猴子在機房裏,你隨便搞,隨便敲。”

在快手,服務調用、測試、服務治理、服務發現、追蹤系統都收斂在基礎組件的一個範圍內,王天舟他們有全公司所有的調用信息。“機器級別的故障注入沒有什麼難度,因爲這種硬件級別的應用層故障和高延遲都是單機級別的,很容易操作。更高級別的就是抽象粒度的,比如某些網絡硬件設施造成某一類服務或者某幾類服務產生一個服務容量的下降,我們最怕的就是這個服務半死不活,這種時候就需要對服務級別進行故障注入。”

此外,模擬故障發生之後,熔斷後的降級措施也是基礎組件部門要提供的能力。不過王天舟強調:“熔斷的一些配置對業務來說是可感知的,業務需要知道一件事,就是當熔斷髮生之後,業務流程應該怎麼走。如果業務代碼有可能沒寫對的話,那麼一旦發生熔斷可能就不符合預期,就會發現很多問題。”

架構師是最容易陷入理想主義的一羣人

王天舟是“老快手”,他 2015 年加入公司,當年快手的基礎架構做過一次大的升級調整——核心的後端架構“換了一次血”。而在那之後,一直都是小補丁的方式去做“修修補補”。所以此次春晚紅包這樣量級的考驗,王天舟此前是沒有遇到過的。“雖然我們在做架構設計的時候會有一些前瞻性,比如會考慮未來漲十倍什麼樣,但實際能不能漲十倍,漲十倍的時候我們的架構能不能扛得住,這些都要在事情真正發生的過程中去發現問題、解決問題。”

王天舟所在團隊一共有接近 40 人,從 10 月接到春晚紅包的消息後,團隊就差不多是”All in“的狀態。這次春晚紅包,對基礎架構團隊來說,是一次巨大挑戰。一方面,基礎組件的 overhead 在常規壓力下其實並不會被凸顯,但是春晚極端情況下,基礎組件本身的性能開銷就變得格外重要。另一方面,基礎架構平時面臨的業務需求非常多樣,但是在春晚紅包活動期間,對一些極端需求會非常旺盛(例如超高精度數據統計,例如大量以自適應爲基礎的可用性組件等),這在以往服務規模不足的時候,未必是一個有效的需求,亦或者之前的解決方案其實是無法勝任的,需要做相應的微調、升級或者重構(例如我們的核心統計 perf 組件,就經歷了一次大的重構和架構升級)。

對於春晚紅包活動給團隊帶來的收穫,王天舟總結爲質的飛躍,“不光是技術能力,還包括個人的視野,人員戰鬥力以及組織能力。”

提及整個項目下來的整體感受,王天舟的感悟更多是從業務維度來看的。“基礎架構團隊最容易面臨的兩個問題:一是對業務瞭解不夠深入,需求只停留在表面,以建設能力爲導向,容易忽略解決問題的效果。二是基礎架構組件和方案在業務中推行容易受到阻礙,如果業務用腳投票,那麼基礎組件的收斂工作會有極大的挑戰,在這種高併發或者挑戰較大的活動時,往往容易出現各種意想不到的問題(因爲業務選擇方案和組件的導向往往更容易傾向於短期利益)。”

站在架構師的立場上,就對架構師的視野提出了比較高的挑戰:如何識別業務發展中的短期問題和長期問題,並把行業最佳實踐“剪裁”或者“嫁接”到業務當中,讓方案對業務更加適用,而不是讓業務去適配方案。這些就要求架構師一方面能深入業務,瞭解業務的特點和一線的實際痛點,另一方面又要對行業內的最佳實踐和未來方向保持敏感。

王天舟認爲架構師是最容易陷入理想主義的一羣人。他個人的經驗是:在和業務進行交流時,時刻保持敬畏之心,並且能識別出哪些問題是源於自己的“潔癖”或者“理念”。當出現意見不一的時候,以解決問題爲導向,以數據爲導向,而不是強調個人傾向、感受或者理念。因爲前者相對客觀,也容易達成共識,後者更加主觀,在很多時候也無法 100% 分出對錯。

嘉賓介紹:
王天舟,就職於快手,擔當基礎架構系統架構師,主要負責快手服務端 Java 開發方向架構、規範和基礎組件研發等工作。從業以來一直投入社交領域服務端開發和架構設計,有豐富的相關經驗。


活動推薦
在QCon北京2020的演講中,王天舟老師將介紹快手基礎架構團隊在應對春晚活動挑戰時,做了哪些技術層面的改造和升級,並如何最終在業務落地,發揮效果,點擊瞭解詳情

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章