非吃瓜，B 站事件始末分析 + 防治技術(shù)分享

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

這要是擱以前，不愛吃瓜的我根本不會(huì)去關(guān)注這種事，崩了就崩了唄，反正天塌下來有程序員大佬們扛著，很快就會(huì)好的。

但這次不太一樣，因?yàn)槲易约阂渤蔀榱吮臼录?“受害者” ！

所以今天以一名程序員的視角，帶大家回顧 B 站崩了事件的始末、理性推測(cè)原因、并分享一些防治技術(shù)和收獲感悟。

事件始末

B 站剛剛崩，但還沒有完全崩的時(shí)候，我正在直播間寫小代碼、和小伙伴們友好交流。由于我在寫代碼的時(shí)候不會(huì)經(jīng)?？磸椖?，沒有注意到彈幕不動(dòng)了，沒有任何小伙伴發(fā)彈幕。

起初我以為只是自己寫代碼太無聊了，沒人搭理我。然后我就擱哪兒喃喃自語：奇怪了，怎么沒有小伙伴發(fā)彈幕？喂，有人么？Hello？Hi？歪比八步？

后來我才發(fā)現(xiàn)，彈幕區(qū)連進(jìn)房提示都沒了，總不可能幾分鐘沒人進(jìn)來吧？肯定是出事了！

我以為是彈幕卡了，于是就關(guān)閉彈幕再打開，結(jié)果還是一樣。然后我就想著重啟下直播，結(jié)果關(guān)掉之后再也打不開了，屏幕上直接提示：似乎已斷開和服務(wù)器的鏈接。

實(shí)話說，在此之前，我根本沒想到 B 站這種億級(jí)流量的平臺(tái)會(huì)崩掉。所以第一反應(yīng)和大家一樣，都懷疑是自己網(wǎng)絡(luò)的問題，結(jié)果發(fā)現(xiàn)網(wǎng)頁能打開，換了網(wǎng)也連不上。于是我突然細(xì)思極恐：握草？B 站竟然也把我封了？（老通緝犯了）

就是這樣，我是事故現(xiàn)場(chǎng)的受害人，是倒在地上懵逼的那個(gè)，所以直到事故發(fā)生十幾分鐘后，我才通過其他途徑了解到，哦，原來是 B 站出事了。

雖然錯(cuò)過了第一現(xiàn)場(chǎng)，但通過熱搜，也能了解到 B 站崩盤的大致過程，簡(jiǎn)單地說，就是在 幾個(gè)小時(shí) 內(nèi)，用戶無法正常訪問 B 站的任何功能！

打開 B 站，先是 404 Not Found 找不到資源：

然后是 502 錯(cuò)誤網(wǎng)關(guān)：

1 個(gè)小時(shí)后，一些小伙伴表示 B 站的部分功能已經(jīng)可以使用了，但還是沒有完全恢復(fù)，直到 14 日凌晨，B 站官方才終于回應(yīng)，恢復(fù)正常了。

原因猜測(cè)

昨晚剪視頻到凌晨 2 點(diǎn)多，本來想直接睡覺，但手賤又打開了知乎，發(fā)現(xiàn) “B 站崩了” 是 Top 1 熱門的問題，出于好奇就點(diǎn)進(jìn)去想了解下事故背后的真正原因，看看大家的高見。

本來我一個(gè)非 B 站工作的外來人，對(duì)它的技術(shù)架構(gòu)沒有深入了解；再加上缺少關(guān)鍵信息、沒有可靠的推測(cè)憑據(jù)，所以不準(zhǔn)備發(fā)表意見的。結(jié)果發(fā)現(xiàn)前排沒有幾個(gè)程序員在從技術(shù)的角度推測(cè)事故原因，都是一些幫大家吃瓜更香的小回答。那我不妨根據(jù)過往學(xué)到的架構(gòu)知識(shí)，做一波推測(cè)，萬一推中了感覺也挺驚喜的。

其實(shí)在 20 年的時(shí)候，B 站技術(shù)總監(jiān)毛劍老師就在騰訊云 + 社區(qū)分享過《B 站高可用架構(gòu)實(shí)踐》講座，當(dāng)時(shí)我全程看完了，但沒想到，有一天，高可用的 B 站不可用了。

所以在這次分析前，我先把《B 站高可用架構(gòu)實(shí)踐》文章又讀了一遍，有趣的是，短短半天，這篇文章的閱讀量漲了 15 萬！

而且更有趣的是，文章底下多了不少 “嘲諷”，什么 “八股文架構(gòu)師” 之類的：

不過我覺得沒必要，因?yàn)槊珓蠋煼窒淼募夹g(shù)確實(shí)是很實(shí)用的高可用解決方案，只不過還是缺少了一些印證吧。

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

下面說下我的猜測(cè)。

猜測(cè) 1：網(wǎng)關(guān)掛了

首先，這次小破站事故發(fā)生時(shí)，其他站點(diǎn)竟然也崩了！比如 A 站、晉江、豆瓣，統(tǒng)統(tǒng)都上了熱搜。

這些事故同時(shí)發(fā)生，說明是這些系統(tǒng)依賴的公共服務(wù)出了問題，而唯一有能力導(dǎo)致大規(guī)模服務(wù)癱瘓的就是 CDN 了。

CDN 是內(nèi)容分發(fā)網(wǎng)絡(luò)，提前將源站內(nèi)容發(fā)到各個(gè)地區(qū)的服務(wù)器節(jié)點(diǎn)，之后就可以讓不同地區(qū)的用戶就近獲取內(nèi)容，而不是都到源站獲取，從而起到內(nèi)容加速、負(fù)載均衡的作用。

一旦 CDN 掛了，該地區(qū)用戶的流量會(huì)全部打到網(wǎng)關(guān)上：

網(wǎng)關(guān)就像是家族老大，用戶有需求就跟老大說，然后老大再分配需求給弟弟們?nèi)ネ瓿伞?/p>

此外，網(wǎng)關(guān)通常還承擔(dān)起了保護(hù)服務(wù)弟弟們的使命，統(tǒng)一負(fù)載均衡、控制流量、熔斷降級(jí)等。

按道理來講，通常網(wǎng)關(guān)不僅要保護(hù)下游的服務(wù)，自身也是需要安全保護(hù)的。但為什么網(wǎng)關(guān)沒有保護(hù)好自己呢？

我的猜測(cè)是：網(wǎng)關(guān)還沒有來的及開啟保護(hù)措施（自身的熔斷降級(jí)等），就被流量瞬狙了。

網(wǎng)關(guān)一掛，服務(wù)沒爹，服務(wù)缺少了調(diào)用入口，自然就不可用了，未必所有網(wǎng)關(guān)后的服務(wù)都處于癱瘓狀態(tài)。

猜測(cè) 2：服務(wù)雪崩

還有一種猜測(cè)是 B 站系統(tǒng)存在很多服務(wù)的 調(diào)用鏈 。由于 CDN 或者部分機(jī)器掛掉，導(dǎo)致某個(gè)下游服務(wù) A 的執(zhí)行耗時(shí)增加，從而導(dǎo)致上游調(diào)用服務(wù) A 的服務(wù) B 執(zhí)行耗時(shí)也增加，讓系統(tǒng)單位時(shí)間的處理能力變差。再加上上游不斷積壓請(qǐng)求，最終導(dǎo)致整個(gè)調(diào)用鏈雪崩，所有鏈上服務(wù)從兒子到爸爸全部滅門。

舉個(gè)通俗的例子就是家里的馬桶堵了，桶里的還沒充下去，上面卻還在不斷 “送貨”，最終下場(chǎng)就是你不能再 “送貨” 了，馬桶爆了！

官方解釋

在官方解釋是服務(wù)器機(jī)房發(fā)生故障之后，又看了其他老師的分析，感覺官方的解釋還說的過去。

的確之前 B 站在對(duì)外分享高可用架構(gòu)時(shí)幾乎沒有提到 災(zāi)備 和 多活 方面的設(shè)計(jì)，更多的是在本地服務(wù)層和應(yīng)用層去處理，比如限流、降級(jí)、熔斷、重試、超時(shí)處理等，所以在設(shè)計(jì)大規(guī)模分布式系統(tǒng)時(shí)還是要考慮更全面一些，引以為戒~

直到發(fā)文前，知乎 Top 1 的回答者又很用心地整理了線索：

為什么其他兩家很快就恢復(fù)了，B 站卻花了幾個(gè)小時(shí)才恢復(fù)正常呢？

感覺多少和 B 站自研組件有關(guān)系，一方面受到云服務(wù)商的影響，導(dǎo)致下游的服務(wù)連鎖掛掉了，故障面積大 ；另一方面重啟也需要時(shí)間，而且重啟過程中，上游的負(fù)載均衡也未必能承受住流量高峰，所以想要恢復(fù)到正常水平，至少要等待很多容器副本完全重啟。

另外昨天 23 點(diǎn)半左右，我打開 B 站時(shí)，看到的內(nèi)容是幾個(gè)小時(shí)前的老數(shù)據(jù)，說明這個(gè)時(shí)候 B 站已經(jīng)重啟了部分服務(wù)副本，并且開啟了降級(jí)措施，并沒有查詢真實(shí)數(shù)據(jù)。

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

保命：以上本身就是我的猜測(cè)哈哈，專業(yè)度有限，歡迎大家評(píng)論區(qū)討論，輕噴輕噴。

防治技術(shù)

再簡(jiǎn)單聊一下服務(wù)故障的防治技術(shù)，就是如何保證服務(wù)的高可用性，盡量持續(xù)為用戶提供服務(wù)而不宕機(jī)。

我將了解到的技術(shù)簡(jiǎn)單分類，整理成了一張思維導(dǎo)圖：

暫時(shí)想到這么多，當(dāng)然還有其他的技術(shù)。

時(shí)間有限，就先不對(duì)這些技術(shù)展開去講了。關(guān)于如何減少系統(tǒng)出現(xiàn)的 Bug、保證服務(wù)高可用，歡迎大家閱讀我的歷史文章：揭秘軟件開發(fā)的達(dá)摩克利斯之劍，以上很多技術(shù)也都有講解。

收獲感悟

關(guān)于這次事故，我作為受害者之一，也有一些收獲和感悟，而不是吃瓜吃了個(gè)寂寞。

首先是要有 質(zhì)疑精神 ，我們?cè)趯懗绦虺霈F(xiàn)問題時(shí)，習(xí)慣性地先從自己身上找原因沒有任何問題，但自己排查沒有發(fā)現(xiàn) Bug 后，應(yīng)該大膽推測(cè)是我們用到的類庫、組件、或者依賴服務(wù)、甚至有可能是編輯器出了問題，而不是認(rèn)為知名的東西一定正確。像小破站出了問題后，我竟然懷疑是自己的直播被封了哈哈，差點(diǎn)想找到管理去跪了。

在編程方面，我們不能只去背知識(shí)、聽別人講，做 八股文架構(gòu)師；而是要做實(shí)踐經(jīng)驗(yàn)豐富的工程師，不盲目相信、不想當(dāng)然，而是在實(shí)踐中積累經(jīng)驗(yàn)、結(jié)合實(shí)際去優(yōu)化系統(tǒng)。

通過這次結(jié)合實(shí)際故障過程的分析，我也復(fù)習(xí)了一遍之前學(xué)到的架構(gòu)知識(shí)，對(duì)一些高可用的設(shè)計(jì)有了更深的理解。有朝一日，盡量不讓 編程導(dǎo)航（www.code-nav.cn） 成為下一個(gè) B 站（狗頭）。

還有就是上面提到的，要時(shí)刻居安思危，養(yǎng)成防御性編程的好習(xí)慣，而不是出了問題再去補(bǔ)救。像 B 站這種知名平臺(tái)，出一點(diǎn)小問題，對(duì)用戶、對(duì)企業(yè)帶來的損失都是難以估量的。

感謝 B 站爸爸送來的一天大會(huì)員補(bǔ)償 ??

最后再送大家一些 幫助我拿到大廠 offer 的學(xué)習(xí)資料：

指路：https://t.1yb.co/qOJG

我是如何從零開始通過自學(xué)，拿到騰訊、字節(jié)等大廠 offer 的，可以看這篇文章，不再迷茫！

指路：https://t.1yb.co/q0mS

我是魚皮，點(diǎn)贊 還是要求一下的，祝大家都能心想事成、發(fā)大財(cái)、行大運(yùn)。