非吃瓜，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 萬！
而且更有趣的是，文章底下多了不少 “嘲諷”，什麼 “八股文架構師” 之類的：
不過我覺得沒必要，因為毛劍老師分享的技術確實是很實用的高可用解決方案，只不過還是缺少了一些印證吧。
下面說下我的猜測。
猜測 1：閘道器掛了
首先，這次小破站事故發生時，其他站點竟然也崩了！比如 A 站、晉江、豆瓣，統統都上了熱搜。
這些事故同時發生，說明是這些系統依賴的公共服務出了問題，而唯一有能力導致大規模服務癱瘓的就是 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 的學習資料：
我是如何從零開始通過自學，拿到騰訊、位元組等大廠 offer 的，可以看這篇文章，不再迷茫！
我是魚皮，點贊 還是要求一下的，祝大家都能心想事成、發大財、行大運。
