昨天晚上，正在B站舞蹈區(qū)刷視頻呢！突然，我發(fā)現(xiàn)一下子404 NOT found了？

壞了，作為開發(fā)的我第一直覺是系統(tǒng)崩了，我甚至懷疑是我網(wǎng)的問題，我發(fā)現(xiàn)手機(jī)網(wǎng)絡(luò)正常電腦訪問其他網(wǎng)頁也正常，我就知道開發(fā)要背鍋了。

文章來源：微信公眾號丨敖丙

我刷新了幾次，發(fā)現(xiàn)還是這樣，我就有點(diǎn)同情對應(yīng)的開發(fā)同學(xué)了，年終應(yīng)該沒了。（到我寫這個文章的時候網(wǎng)站還沒恢復(fù)）

作為前程序員的我，就習(xí)慣性的去想B站的網(wǎng)站架構(gòu)組成，以及這次事故復(fù)盤下來，可能會出問題的點(diǎn)。（老職業(yè)習(xí)慣了）

首先我們可以大致畫一下簡單的一個網(wǎng)站組成的架構(gòu)圖，我們再去猜想這次問題可能出在什么地方。

因為熬夜寫文章哈，我也沒在這種主要靠視頻直播的公司呆過，技術(shù)棧也不是很了解，所以就用電商的大概邏輯，畫了一個草圖，大家輕點(diǎn)噴。

從上到下，從入口到cdn內(nèi)容分發(fā)，到前端服務(wù)器，后端服務(wù)器，分布式存儲，大數(shù)據(jù)分析，風(fēng)控到搜索引擎推薦這我就隨便畫了一下，我想整體架構(gòu)應(yīng)該不會差異特別大。

我去網(wǎng)上隨便查了一些類似斗魚，B站，a站這樣的公司，主要技術(shù)棧和技術(shù)難點(diǎn)主要有：

視頻訪問存儲

流

就近節(jié)點(diǎn)

視頻編解碼

斷點(diǎn)續(xù)傳（跟我們寫的io例子差多）

數(shù)據(jù)庫系統(tǒng)&文件系統(tǒng)隔離

并發(fā)訪問

流媒體服務(wù)器（各大廠商都有，帶寬成本較大）

數(shù)據(jù)集群，分布式存儲、緩存

CDN內(nèi)容分發(fā)

負(fù)載均衡

搜索引擎（分片）

彈幕系統(tǒng)

并發(fā)、線程

kafka

nio框架（netty）

其實跟我們大家學(xué)的技術(shù)都差不多，不過他們的對應(yīng)微服務(wù)的語言組成可能go、php、vue、node占比比較大。

我們分析下這次事故可能出事的原因和地方：

1.刪庫跑路

之前微盟發(fā)生過這個事情，我覺得各個公司應(yīng)該都不會把運(yùn)維的權(quán)限給這么大了，比如主機(jī)權(quán)限直接禁止了rm-rf、fdisk、drop這樣的命令。

而且數(shù)據(jù)庫現(xiàn)在大概率都是多主多從，多地備份的，容災(zāi)也應(yīng)該是做的很好的，而且光是數(shù)據(jù)庫炸了，那cdn的很多靜態(tài)資源應(yīng)該也不會加載不出，整個頁面直接404了。

2.單微服務(wù)掛掉拖垮大集群

現(xiàn)在都是前后端分離的，如果是后端掛了，前端很多東西依然是能加載只是數(shù)據(jù)出不來報錯，所以集群要掛也可能是前端掛了，或者前后端一起掛了，但是還是那個問題，現(xiàn)在看起來是所有靜態(tài)資源都無法訪問了。

不過這個點(diǎn)我覺得也有一點(diǎn)可能，因為部分服務(wù)掛了，導(dǎo)致大量報錯，拉掛了集群，而且越是這樣大家越會不斷刷新頁面，給其他服務(wù)重啟增加難度，但是這個可能性沒我最后說的可能性大。

3.服務(wù)器廠商出問題了

這種大網(wǎng)站都是cdn+slb+站集群，各種限流降級、負(fù)載均衡按道理都會做的很好，而且他們按道理不會不做容災(zāi)。

所以只有可能是這些前置服務(wù)的服務(wù)器廠商出問題了，CDN如果掛了那網(wǎng)關(guān)負(fù)載均衡啥的壓力都大了，最后導(dǎo)致連鎖的雪崩效應(yīng)打掛了整套系統(tǒng)。

但是我比較疑惑的是B站的BFF應(yīng)該會路由到一些接入節(jié)點(diǎn)比較進(jìn)的機(jī)房，這樣全國各地的小伙伴刷的時候，應(yīng)該是有些人好，有些人壞，有些人時好時壞才對，但是現(xiàn)在看來是全壞了，難道他們押寶了一個廠商的一個節(jié)點(diǎn)片區(qū)？

我看網(wǎng)上也在傳云海數(shù)據(jù)中心起火了，不知道真假，只能等醒來看看B站官宣了，B站原則上，理論上，從CDN、分布式存儲、大數(shù)據(jù)、搜索引擎都應(yīng)該做了很多保證措施才對，如果真all in了一個地方那確實不太明智。

我的感覺就是沒做好全部上云，線下的服務(wù)器出了問題，剛好是沒上云的是關(guān)鍵業(yè)務(wù)，現(xiàn)在公司都是公有云+私有云這樣的混合云搭配用的，但是私有云部分都是B站自己的內(nèi)部業(yè)務(wù)，所以應(yīng)該不會他自己的機(jī)房出問題。

如果真像我說的，押寶了一個服務(wù)器廠商，只是cdn出問題還好，如果物理機(jī)還出問題了，那數(shù)據(jù)恢復(fù)可能就慢了，我自己之前做大數(shù)據(jù)的，我知道數(shù)據(jù)備份都是增量+全量，恢復(fù)的時候真的好了一部分還可以從其他地區(qū)節(jié)點(diǎn)拉，但是如果是放在一個地方了，那就麻煩了。

復(fù)盤

我想不管最后是什么原因造成的，我們技術(shù)人和公司應(yīng)該思考的就是怎么去避免這樣事情的發(fā)生。

數(shù)據(jù)備份：備份一定要做，不然如果真發(fā)生什么自然災(zāi)害，那是很難受的，所以很多云廠商現(xiàn)在都選在貴州我老家這樣自然災(zāi)害比較少的地方、或者湖底、海底（比較涼快成本能下去不少）。

全量、增量基本上都是一直要做的，分天、周、月不斷的增量數(shù)據(jù)，以及按時的全量數(shù)據(jù)備份，這樣可以讓損失降低很多，就怕所有地區(qū)的機(jī)械盤都壞了（異地容災(zāi)除了地球毀滅不然都能找回來）。

運(yùn)維權(quán)限收斂，還是怕刪庫跑路，反正我是經(jīng)常在服務(wù)器上rm-rf，不過一般有跳板機(jī)才能進(jìn)去的都可以做命令禁止。

上云+云原生：云產(chǎn)品的各種能力現(xiàn)在很成熟的，企業(yè)應(yīng)該對對應(yīng)的云廠商有足夠的信任，當(dāng)然也得選對才行，云產(chǎn)品的各種能力是其一，還有關(guān)鍵時刻的容災(zāi)、應(yīng)急響應(yīng)機(jī)制都是很多公司不具備的。

云原生是近些年才大家才重視的技術(shù)，docker+k8s這對應(yīng)的一些組合，加上云計算的各種能力，其實可以做到無人值守，動態(tài)縮擴(kuò)容，以及上面說的應(yīng)急響應(yīng)，但是技術(shù)本身是需要一些嘗試成本的，而且我也不知道B站這樣視頻為主的體系，適不適合。

kubernetes的設(shè)計上也會存在一些編排、通信的問題。

自身實力打造：其實我覺得不管是上云，還是不上云，都不能太依賴很多云廠商，自己的核心技術(shù)體系和應(yīng)急機(jī)制還是要有，如果云廠商真的靠不住怎么辦？怎么去做真正的高可用，這我覺得是企業(yè)技術(shù)人員需要去思考的。

舉個例子，很多云廠商都是一個物理機(jī)隔成多個虛擬機(jī)售賣，然后就會存在單物理機(jī)多宿主的情況，假如其中一方是電商玩雙十一，一方是游戲廠商，對方大量占用網(wǎng)絡(luò)帶寬，你就可能存在丟包的情況，這對游戲用戶來說是體驗極差的，這樣就是我說為啥不要過于信任和依賴云廠商的原因。

對方萬一買了去挖礦，那更過分，把算力榨干，滿負(fù)荷跑更難受。

B站這次，好在這樣的問題提前暴露了，而且是晚上，應(yīng)該有不少流量低谷的時間去恢復(fù)，我寫到這里的時候，網(wǎng)頁大部分恢復(fù)了，但是我發(fā)現(xiàn)還是部分恢復(fù)。

不管怎么說下次就可以完全杜絕了，相信B站后面很長一段時間都會忙于架構(gòu)體系改造，去保證自己真正的高可用。

希望以后能讓我穩(wěn)定的在晚上看看舞蹈區(qū)，而不是盯著502、404的2233娘發(fā)呆，嘻嘻

寫在最后

從一個過來人的角度來說，新手學(xué)編程方法真的很重要，不然就會造成高消耗，低效能的情況。如果你想更好的提升你的編程核心能力（內(nèi)功），下面的這個資料也建議去看看，對基礎(chǔ)提升挺有幫助的。

微信公眾號：C語言編程學(xué)習(xí)基地

整理分享（多年學(xué)習(xí)的源碼、項目實戰(zhàn)視頻、項目筆記，基礎(chǔ)入門教程）

歡迎轉(zhuǎn)行和學(xué)習(xí)編程的伙伴，利用更多的資料學(xué)習(xí)成長比自己琢磨更快哦！