B 站崩了,受害程式設計師聊聊

程式設計師魚皮發表於2021-07-14

非吃瓜,B 站事件始末分析 + 防治技術分享

大家好,我是魚皮,昨天小破站崩了的事情相信很多朋友都聽說了。

這要是擱以前,不愛吃瓜的我根本不會去關注這種事,崩了就崩了唄,反正天塌下來有程式設計師大佬們扛著,很快就會好的。

但這次不太一樣,因為我自己也成為了本事件的 “受害者”

所以今天以一名程式設計師的視角,帶大家回顧 B 站崩了事件的始末、理性推測原因、並分享一些防治技術和收穫感悟。

事件始末

B 站剛剛崩,但還沒有完全崩的時候,我正在直播間寫小程式碼、和小夥伴們友好交流。由於我在寫程式碼的時候不會經常看彈幕,沒有注意到彈幕不動了,沒有任何小夥伴發彈幕。

起初我以為只是自己寫程式碼太無聊了,沒人搭理我。然後我就擱哪兒喃喃自語:奇怪了,怎麼沒有小夥伴發彈幕?喂,有人麼?Hello?Hi?歪比八步?

後來我才發現,彈幕區連進房提示都沒了,總不可能幾分鐘沒人進來吧?肯定是出事了!

我以為是彈幕卡了,於是就關閉彈幕再開啟,結果還是一樣。然後我就想著重啟下直播,結果關掉之後再也打不開了,螢幕上直接提示:似乎已斷開和伺服器的連結。

實話說,在此之前,我根本沒想到 B 站這種億級流量的平臺會崩掉。所以第一反應和大家一樣,都懷疑是自己網路的問題,結果發現網頁能開啟,換了網也連不上。於是我突然細思極恐:握草?B 站竟然也把我封了?(老通緝犯了)

就是這樣,我是事故現場的受害人,是倒在地上懵逼的那個,所以直到事故發生十幾分鍾後,我才通過其他途徑瞭解到,哦,原來是 B 站出事了。

雖然錯過了第一現場,但通過熱搜,也能瞭解到 B 站崩盤的大致過程,簡單地說,就是在 幾個小時 內,使用者無法正常訪問 B 站的任何功能!

開啟 B 站,先是 404 Not Found 找不到資源:

然後是 502 錯誤閘道器:

1 個小時後,一些小夥伴表示 B 站的部分功能已經可以使用了,但還是沒有完全恢復,直到 14 日凌晨,B 站官方才終於回應,恢復正常了。

原因猜測

昨晚剪視訊到凌晨 2 點多,本來想直接睡覺,但手賤又開啟了知乎,發現 “B 站崩了” 是 Top 1 熱門的問題,出於好奇就點進去想了解下事故背後的真正原因,看看大家的高見。

本來我一個非 B 站工作的外來人,對它的技術架構沒有深入瞭解;再加上缺少關鍵資訊、沒有可靠的推測憑據,所以不準備發表意見的。結果發現前排沒有幾個程式設計師在從技術的角度推測事故原因,都是一些幫大家吃瓜更香的小回答。那我不妨根據過往學到的架構知識,做一波推測,萬一推中了感覺也挺驚喜的。

其實在 20 年的時候,B 站技術總監毛劍老師就在騰訊雲 + 社群分享過《B 站高可用架構實踐》講座,當時我全程看完了,但沒想到,有一天,高可用的 B 站不可用了。

所以在這次分析前,我先把《B 站高可用架構實踐》文章又讀了一遍,有趣的是,短短半天,這篇文章的閱讀量漲了 15 萬!

而且更有趣的是,文章底下多了不少 “嘲諷”,什麼 “八股文架構師” 之類的:

講座評論區

不過我覺得沒必要,因為毛劍老師分享的技術確實是很實用的高可用解決方案,只不過還是缺少了一些印證吧。

文章地址:https://cloud.tencent.com/developer/article/1618923

下面說下我的猜測。

猜測 1:閘道器掛了

首先,這次小破站事故發生時,其他站點竟然也崩了!比如 A 站、晉江、豆瓣,統統都上了熱搜。

這些事故同時發生,說明是這些系統依賴的公共服務出了問題,而唯一有能力導致大規模服務癱瘓的就是 CDN 了。

CDN 是內容分發網路,提前將源站內容發到各個地區的伺服器節點,之後就可以讓不同地區的使用者就近獲取內容,而不是都到源站獲取,從而起到內容加速、負載均衡的作用。

使用者就近訪問內容

一旦 CDN 掛了,該地區使用者的流量會全部打到閘道器上:

CDN 掛了

閘道器就像是家族老大,使用者有需求就跟老大說,然後老大再分配需求給弟弟們去完成。

此外,閘道器通常還承擔起了保護服務弟弟們的使命,統一負載均衡、控制流量、熔斷降級等。

按道理來講,通常閘道器不僅要保護下游的服務,自身也是需要安全保護的。但為什麼閘道器沒有保護好自己呢?

我的猜測是:閘道器還沒有來的及開啟保護措施(自身的熔斷降級等),就被流量瞬狙了。

閘道器一掛,服務沒爹,服務缺少了呼叫入口,自然就不可用了,未必所有閘道器後的服務都處於癱瘓狀態。

猜測 2:服務雪崩

還有一種猜測是 B 站系統存在很多服務的 呼叫鏈 。由於 CDN 或者部分機器掛掉,導致某個下游服務 A 的執行耗時增加,從而導致上游呼叫服務 A 的服務 B 執行耗時也增加,讓系統單位時間的處理能力變差。再加上上游不斷積壓請求,最終導致整個呼叫鏈雪崩,所有鏈上服務從兒子到爸爸全部滅門。

服務呼叫鏈

舉個通俗的例子就是家裡的馬桶堵了,桶裡的還沒充下去,上面卻還在不斷 “送貨”,最終下場就是你不能再 “送貨” 了,馬桶爆了!

官方解釋

在官方解釋是伺服器機房發生故障之後,又看了其他老師的分析,感覺官方的解釋還說的過去。

的確之前 B 站在對外分享高可用架構時幾乎沒有提到 災備多活 方面的設計,更多的是在本地服務層和應用層去處理,比如限流、降級、熔斷、重試、超時處理等,所以在設計大規模分散式系統時還是要考慮更全面一些,引以為戒~

直到發文前,知乎 Top 1 的回答者又很用心地整理了線索:

為什麼其他兩家很快就恢復了,B 站卻花了幾個小時才恢復正常呢?

感覺多少和 B 站自研元件有關係,一方面受到雲服務商的影響,導致下游的服務連鎖掛掉了,故障面積大 ;另一方面重啟也需要時間,而且重啟過程中,上游的負載均衡也未必能承受住流量高峰,所以想要恢復到正常水平,至少要等待很多容器副本完全重啟。

另外昨天 23 點半左右,我開啟 B 站時,看到的內容是幾個小時前的老資料,說明這個時候 B 站已經重啟了部分服務副本,並且開啟了降級措施,並沒有查詢真實資料。

沒想到自己的這個回答還在知乎小火了一把,第一次成為了 千萬瀏覽量 問題的 Top 2,受寵若驚,受寵若驚。。。

保命:以上本身就是我的猜測哈哈,專業度有限,歡迎大家評論區討論,輕噴輕噴。

防治技術

再簡單聊一下服務故障的防治技術,就是如何保證服務的高可用性,儘量持續為使用者提供服務而不當機。

我將瞭解到的技術簡單分類,整理成了一張思維導圖:

故障防治思維導圖

暫時想到這麼多,當然還有其他的技術。

時間有限,就先不對這些技術展開去講了。關於如何減少系統出現的 Bug、保證服務高可用,歡迎大家閱讀我的歷史文章:揭祕軟體開發的達摩克利斯之劍,以上很多技術也都有講解。

收穫感悟

關於這次事故,我作為受害者之一,也有一些收穫和感悟,而不是吃瓜吃了個寂寞。

首先是要有 質疑精神 ,我們在寫程式出現問題時,習慣性地先從自己身上找原因沒有任何問題,但自己排查沒有發現 Bug 後,應該大膽推測是我們用到的類庫、元件、或者依賴服務、甚至有可能是編輯器出了問題,而不是認為知名的東西一定正確。像小破站出了問題後,我竟然懷疑是自己的直播被封了哈哈,差點想找到管理去跪了。

在程式設計方面,我們不能只去背知識、聽別人講,做 八股文架構師;而是要做實踐經驗豐富的工程師,不盲目相信、不想當然,而是在實踐中積累經驗、結合實際去優化系統。

通過這次結合實際故障過程的分析,我也複習了一遍之前學到的架構知識,對一些高可用的設計有了更深的理解。有朝一日,儘量不讓 程式設計導航(www.code-nav.cn) 成為下一個 B 站(狗頭)。

還有就是上面提到的,要時刻居安思危,養成防禦性程式設計的好習慣,而不是出了問題再去補救。像 B 站這種知名平臺,出一點小問題,對使用者、對企業帶來的損失都是難以估量的。

感謝 B 站爸爸送來的一天大會員補償 ❤️


最後再送大家一些 幫助我拿到大廠 offer 的學習資料

跑了,留下 6T 的資源!

我是如何從零開始通過自學,拿到騰訊、位元組等大廠 offer 的,可以看這篇文章,不再迷茫!

我學計算機的四年,共勉!

我是魚皮,點贊 還是要求一下的,祝大家都能心想事成、發大財、行大運。

相關文章