非吃瓜职员，B 站事件始末分析 + 防治技術分享
昨天小破站崩了的事情相信很多朋友都聽說了焊切。
這要是擱以前，不愛吃瓜的我根本不會去關注這種事糙箍，崩了就崩了唄深夯，反正天塌下來有程序員大佬們扛著咕晋，很快就會好的掌呜。
但這次不太一樣质蕉，因為我自己也成為了本事件的 “受害者” 模暗！
所以今天以一名程序員的視角兑宇，帶大家回顧 B 站崩了事件的始末粱坤、理性推測原因、并分享一些防治技術和收獲感悟枚驻。
事件始末
B 站剛剛崩再登，但還沒有完全崩的時候霎冯，我正在直播間寫小代碼沈撞、和小伙伴們友好交流缠俺。由于我在寫代碼的時候不會經(jīng)骋际浚看彈幕躏救，沒有注意到彈幕不動了盒使，沒有任何小伙伴發(fā)彈幕少办。
起初我以為只是自己寫代碼太無聊了挽放，沒人搭理我辑畦。然后我就擱哪兒喃喃自語：奇怪了航闺，怎么沒有小伙伴發(fā)彈幕？喂侮措，有人么澄成？Hello畏吓？Hi肾砂？歪比八步宏悦？
后來我才發(fā)現(xiàn)，彈幕區(qū)連進房提示都沒了诗越，總不可能幾分鐘沒人進來吧嚷狞？肯定是出事了！
我以為是彈幕卡了即硼，于是就關閉彈幕再打開只酥，結果還是一樣裂允。然后我就想著重啟下直播，結果關掉之后再也打不開了十饥，屏幕上直接提示：似乎已斷開和服務器的鏈接。
實話說祖乳，在此之前逗堵，我根本沒想到 B 站這種億級流量的平臺會崩掉。所以第一反應和大家一樣眷昆，都懷疑是自己網(wǎng)絡的問題蜒秤，結果發(fā)現(xiàn)網(wǎng)頁能打開，換了網(wǎng)也連不上亚斋。于是我突然細思極恐：握草作媚？B 站竟然也把我封了？（老通緝犯了）
就是這樣帅刊，我是事故現(xiàn)場的受害人纸泡，是倒在地上懵逼的那個，所以直到事故發(fā)生十幾分鐘后，我才通過其他途徑了解到，哦民逼，原來是 B 站出事了。
雖然錯過了第一現(xiàn)場俊犯，但通過熱搜，也能了解到 B 站崩盤的大致過程，簡單地說坟比，就是在 幾個小時 內籍琳，用戶無法正常訪問 B 站的任何功能谣蠢！
打開 B 站，先是 404 Not Found 找不到資源：
然后是 502 錯誤網(wǎng)關：
1 個小時后，一些小伙伴表示 B 站的部分功能已經(jīng)可以使用了，但還是沒有完全恢復，直到 14 日凌晨，B 站官方才終于回應侄柔，恢復正常了薪者。
原因猜測
昨晚剪視頻到凌晨 2 點多，本來想直接睡覺渣窜，但手賤又打開了知乎详瑞，發(fā)現(xiàn) “B 站崩了” 是 Top 1 熱門的問題锣杂，出于好奇就點進去想了解下事故背后的真正原因蝶押，看看大家的高見。
本來我一個非 B 站工作的外來人打却，對它的技術架構沒有深入了解；再加上缺少關鍵信息饥悴、沒有可靠的推測憑據(jù)，所以不準備發(fā)表意見的库车。結果發(fā)現(xiàn)前排沒有幾個程序員在從技術的角度推測事故原因珍坊，都是一些幫大家吃瓜更香的小回答回还。那我不妨根據(jù)過往學到的架構知識运提，做一波推測坎缭，萬一推中了感覺也挺驚喜的。
其實在 20 年的時候，B 站技術總監(jiān)毛劍老師就在騰訊云 + 社區(qū)分享過《B 站高可用架構實踐》講座窍侧，當時我全程看完了其骄，但沒想到亏镰，有一天，高可用的 B 站不可用了拯爽。
所以在這次分析前，我先把《B 站高可用架構實踐》文章又讀了一遍钧忽，有趣的是毯炮，短短半天，這篇文章的閱讀量漲了 15 萬耸黑！
而且更有趣的是桃煎，文章底下多了不少 “嘲諷”，什么 “八股文架構師” 之類的：
不過我覺得沒必要大刊，因為毛劍老師分享的技術確實是很實用的高可用解決方案为迈，只不過還是缺少了一些印證吧。
下面說下我的猜測缺菌。
猜測 1：網(wǎng)關掛了
首先葫辐，這次小破站事故發(fā)生時，其他站點竟然也崩了伴郁！比如 A 站耿战、晉江、豆瓣焊傅，統(tǒng)統(tǒng)都上了熱搜剂陡。
這些事故同時發(fā)生，說明是這些系統(tǒng)依賴的公共服務出了問題狐胎，而唯一有能力導致大規(guī)模服務癱瘓的就是 CDN 了鸭栖。
CDN 是內容分發(fā)網(wǎng)絡，提前將源站內容發(fā)到各個地區(qū)的服務器節(jié)點握巢，之后就可以讓不同地區(qū)的用戶就近獲取內容晕鹊，而不是都到源站獲取，從而起到內容加速镜粤、負載均衡的作用捏题。
一旦 CDN 掛了，該地區(qū)用戶的流量會全部打到網(wǎng)關上：
網(wǎng)關就像是家族老大肉渴，用戶有需求就跟老大說公荧，然后老大再分配需求給弟弟們去完成。
此外同规，網(wǎng)關通常還承擔起了保護服務弟弟們的使命循狰，統(tǒng)一負載均衡窟社、控制流量、熔斷降級等绪钥。
按道理來講灿里，通常網(wǎng)關不僅要保護下游的服務，自身也是需要安全保護的程腹。但為什么網(wǎng)關沒有保護好自己呢匣吊？
我的猜測是：網(wǎng)關還沒有來的及開啟保護措施（自身的熔斷降級等），就被流量瞬狙了寸潦。
網(wǎng)關一掛色鸳，服務沒爹，服務缺少了調用入口见转，自然就不可用了命雀，未必所有網(wǎng)關后的服務都處于癱瘓狀態(tài)。
猜測 2：服務雪崩
還有一種猜測是 B 站系統(tǒng)存在很多服務的 調用鏈 斩箫。由于 CDN 或者部分機器掛掉吏砂，導致某個下游服務 A 的執(zhí)行耗時增加，從而導致上游調用服務 A 的服務 B 執(zhí)行耗時也增加乘客，讓系統(tǒng)單位時間的處理能力變差狐血。再加上上游不斷積壓請求，最終導致整個調用鏈雪崩寨典，所有鏈上服務從兒子到爸爸全部滅門氛雪。
舉個通俗的例子就是家里的馬桶堵了，桶里的還沒充下去耸成，上面卻還在不斷 “送貨”报亩，最終下場就是你不能再 “送貨” 了，馬桶爆了井氢！
官方解釋
在官方解釋是服務器機房發(fā)生故障之后弦追，又看了其他老師的分析，感覺官方的解釋還說的過去花竞。
的確之前 B 站在對外分享高可用架構時幾乎沒有提到 災備 和 多活 方面的設計劲件，更多的是在本地服務層和應用層去處理，比如限流约急、降級零远、熔斷、重試厌蔽、超時處理等牵辣，所以在設計大規(guī)模分布式系統(tǒng)時還是要考慮更全面一些，引以為戒~
直到發(fā)文前奴饮，知乎 Top 1 的回答者又很用心地整理了線索：
為什么其他兩家很快就恢復了纬向，B 站卻花了幾個小時才恢復正常呢择浊？
感覺多少和 B 站自研組件有關系，一方面受到云服務商的影響逾条，導致下游的服務連鎖掛掉了琢岩， 故障面積大 ；另一方面重啟也需要時間师脂，而且重啟過程中担孔，上游的負載均衡也未必能承受住流量高峰，所以想要恢復到正常水平危彩，至少要等待很多容器副本完全重啟攒磨。
另外昨天 23 點半左右，我打開 B 站時汤徽，看到的內容是幾個小時前的老數(shù)據(jù)，說明這個時候 B 站已經(jīng)重啟了部分服務副本灸撰，并且開啟了降級措施谒府，并沒有查詢真實數(shù)據(jù)。
沒想到自己的這個回答還在知乎小火了一把浮毯，第一次成為了 千萬瀏覽量 問題的 Top 2 完疫，受寵若驚，受寵若驚债蓝。壳鹤。。
保命：以上本身就是我的猜測哈哈饰迹，專業(yè)度有限芳誓，歡迎大家評論區(qū)討論，輕噴輕噴啊鸭。
防治技術
再簡單聊一下服務故障的防治技術锹淌，就是如何保證服務的高可用性，盡量持續(xù)為用戶提供服務而不宕機赠制。
我將了解到的技術簡單分類赂摆，整理成了一張思維導圖：
暫時想到這么多，當然還有其他的技術钟些。
時間有限烟号，就先不對這些技術展開去講了。
收獲感悟
關于這次事故政恍，我作為受害者之一汪拥，也有一些收獲和感悟，而不是吃瓜吃了個寂寞抚垃。
首先是要有 質疑精神 喷楣，我們在寫程序出現(xiàn)問題時趟大，習慣性地先從自己身上找原因沒有任何問題，但自己排查沒有發(fā)現(xiàn) Bug 后铣焊，應該大膽推測是我們用到的類庫逊朽、組件、或者依賴服務曲伊、甚至有可能是編輯器出了問題叽讳，而不是認為知名的東西一定正確。像小破站出了問題后坟募，我竟然懷疑是自己的直播被封了哈哈岛蚤，差點想找到管理去跪了。
在編程方面懈糯，我們不能只去背知識涤妒、聽別人講，做 八股文架構師 赚哗；而是要做實踐經(jīng)驗豐富的工程師她紫，不盲目相信、不想當然屿储，而是在實踐中積累經(jīng)驗贿讹、結合實際去優(yōu)化系統(tǒng)。
通過這次結合實際故障過程的分析够掠，我也復習了一遍之前學到的架構知識民褂，對一些高可用的設計有了更深的理解。有朝一日疯潭，盡量不讓 編程導航 （www.code-nav.cn） 成為下一個 B 站（狗頭）赊堪。
還有就是上面提到的，要時刻居安思危袁勺，養(yǎng)成防御性編程的好習慣雹食，而不是出了問題再去補救。像 B 站這種知名平臺期丰，出一點小問題群叶，對用戶、對企業(yè)帶來的損失都是難以估量的钝荡。
感謝 B 站爸爸送來的一天大會員補償 :heart:
