B站崩了，如何防止相似事故的出現？

你們都知道雖然我是一個程序員，可是我很是熱愛運動，好比跳舞，這不天天回家睡前我都會在B站舞蹈區學習相關的舞蹈。

昨天也不例外，我一洗漱完就飛奔坐在電腦前，打開B站舞蹈區準備學習咬人喵，欣小萌、小仙若他們新的舞蹈動做，不得不說老婆們跳的真好，連我這種內向的人也不自覺的跟着扭動了起來。

 

正當我準備學下一個動做的時候，我發現怎麼404 NOT found了。

 

壞了，做爲開發的我第一直覺是系統崩了，我甚至懷疑是我網的問題，我發現手機網絡正常電腦訪問其餘網頁也正常，我就知道開發要背鍋了。

我刷新了幾回，發現仍是這樣，我就有點同情對應的開發同窗了，年終應該沒了。（到我寫這個文章的時候網站還沒恢復）

 

做爲前程序員的我，就習慣性的去想B站的網站架構組成，以及此次事故覆盤下來，可能會出問題的點。（老職業習慣了）

 

首先咱們能夠大體畫一下簡單的一個網站組成的架構圖，咱們再去猜測此次問題可能出在什麼地方。

 

由於熬夜寫文章哈，我也沒在這種主要靠視頻直播的公司呆過，技術棧也不是很瞭解，因此就用電商的大概邏輯，畫了一個草圖，你們輕點噴。

 

從上到下，從入口到cdn內容分發，到前端服務器，後端服務器，分佈式存儲，大數據分析，風控到搜索引擎推薦這我就隨便畫了一下，我想總體架構應該不會差別特別大。

 

我去網上隨便查了一些相似鬥魚，B站，a站這樣的公司，主要技術棧和技術難點主要有：

視頻訪問存儲

• 流
• 就近節點
• 視頻編解碼
• 斷點續傳（跟咱們寫的io例子差多）
• 數據庫系統&文件系統隔離

併發訪問

• 流媒體服務器（各大廠商都有，帶寬成本較大）
• 數據集羣，分佈式存儲、緩存
• CDN內容分發
• 負載均衡
• 搜索引擎（分片）

彈幕系統

• 併發、線程
• kafka
• nio框架（netty）

其實跟咱們你們學的技術都差很少，不過他們的對應微服務的語言組成可能go、php、vue、node佔比比較大。

咱們分析下此次事故可能出事的緣由和地方：

 

1.刪庫跑路

以前微盟發生過這個事情，我以爲各個公司應該都不會把運維的權限給這麼大了，好比主機權限直接禁止了rm-rf、fdisk、drop這樣的命令。

 

並且數據庫如今大機率都是多主多從，多地備份的，容災也應該是作的很好的，並且光是數據庫炸了，那cdn的不少靜態資源應該也不會加載不出，整個頁面直接404了。

 

2.單微服務掛掉拖垮大集羣

如今都是先後端分離的，若是是後端掛了，前端不少東西依然是能加載只是數據出不來報錯，因此集羣要掛也多是前端掛了，或者先後端一塊兒掛了，可是仍是那個問題，如今看起來是全部靜態資源都沒法訪問了。

 

不過這個點我以爲也有一點可能，由於部分服務掛了，致使大量報錯，拉掛了集羣，並且越是這樣你們越會不斷刷新頁面，給其餘服務重啓增長難度，可是這個可能性沒我最後說的可能性大。

 

3.服務器廠商出問題了

這種大網站都是cdn+slb+站集羣，各類限流降級、負載均衡按道理都會作的很好，並且他們按道理不會不作容災。

 

因此只有多是這些前置服務的服務器廠商出問題了，CDN若是掛了那網關負載均衡啥的壓力都大了，最後致使連鎖的雪崩效應打掛了整套系統。

 

可是我比較疑惑的是B站的BFF應該會路由到一些接入節點比較進的機房，這樣全國各地的小夥伴刷的時候，應該是有些人好，有些人壞，有些人時好時壞纔對，可是如今看來是全壞了，難道他們押寶了一個廠商的一個節點片區？

 

我看網上也在傳雲海數據中心起火了，不知道真假，只能等醒來看看B站官宣了，B站原則上，理論上，從CDN、分佈式存儲、大數據、搜索引擎都應該作了不少保證措施纔對，若是真all in了一個地方那確實不太明智。

 

個人感受就是沒作好所有上雲，線下的服務器出了問題，恰好是沒上雲的是關鍵業務，如今公司都是公有云+私有云這樣的混合雲搭配用的，可是私有云部分都是B站本身的內部業務，因此應該不會他本身的機房出問題。

 

若是真像我說的，押寶了一個服務器廠商，只是cdn出問題還好，若是物理機還出問題了，那數據恢復可能就慢了，我本身以前作大數據的，我知道數據備份都是增量+全量，恢復的時候真的好了一部分還能夠從其餘地區節點拉，可是若是是放在一個地方了，那就麻煩了。

 

覆盤

我想無論最後是什麼緣由形成的，咱們技術人和公司應該思考的就是怎麼去避免這樣事情的發生。

 

數據備份： 備份必定要作，否則若是真發生什麼天然災害，那是很難受的，因此不少雲廠商如今都選在貴州我老家這樣天然災害比較少的地方、或者湖底、海底（比較涼快成本能下去很多）。

 

全量、增量基本上都是一直要作的，分天、周、月不斷的增量數據，以及按時的全量數據備份，這樣可讓損失下降不少，就怕全部地區的機械盤都壞了（異地容災除了地球毀滅否則都能找回來）。

 

運維權限收斂，仍是怕刪庫跑路，反正我是常常在服務器上rm-rf，不過通常有跳板機才能進去的均可以作命令禁止。

 

上雲+雲原生： 雲產品的各類能力如今很成熟的，企業應該對對應的雲廠商有足夠的信任，固然也得選對才行，雲產品的各類能力是其一，還有關鍵時刻的容災、應急響應機制都是不少公司不具有的。

 

雲原生是近些年才你們才重視的技術，docker+k8s這對應的一些組合，加上雲計算的各類能力，其實能夠作到無人值守，動態縮擴容，以及上面說的應急響應，可是技術自己是須要一些嘗試成本的，並且我也不知道B站這樣視頻爲主的體系，適不適合。

 

kubernetes的設計上也會存在一些編排、通訊的問題。

 

自身實力打造： 其實我以爲無論是上雲，仍是不上雲，都不能太依賴不少雲廠商，本身的核心技術體系和應急機制仍是要有，若是雲廠商真的靠不住怎麼辦？怎麼去作真正的高可用，這我以爲是企業技術人員須要去思考的。

 

舉個例子，不少雲廠商都是一個物理機隔成多個虛擬機售賣，而後就會存在單物理機多宿主的狀況，假如其中一方是電商玩雙十一，一方是遊戲廠商，對方大量佔用網絡帶寬，你就可能存在丟包的狀況，這對遊戲用戶來講是體驗極差的，這樣就是我說爲啥不要過於信任和依賴雲廠商的緣由。

 

對方萬一買了去挖礦，那更過度，把算力榨乾，滿負荷跑更難受。

 

B站此次，好在這樣的問題提早暴露了，並且是晚上，應該有很多流量低谷的時間去恢復，我寫到這裏的時候，網頁大部分恢復了，可是我發現仍是部分恢復。

 

無論怎麼說下次就能夠徹底杜絕了，相信B站後面很長一段時間都會忙於架構體系改造，去保證本身真正的高可用。

 

但願之後能讓我穩定的在晚上看看舞蹈區，而不是盯着50二、404的2233娘發呆，嘻嘻

最後

最近我整理了整套《JAVA核心知識點總結》,說實話 ,做爲一名Java程序員,不論你需不須要面試都應該好好看下這份資料。拿到手老是不虧的~個人很多粉絲也所以拿到騰訊字節快手等公司的Offer

進【Java進階之路羣】，找管理員獲取哦-！

​