[[411114]]

大家都知道雖然我是一個程序員，但是我非常熱愛運動，比如跳舞，這不每天回家睡前我都會在B站舞蹈區(qū)學(xué)習(xí)相關(guān)的舞蹈。

昨天也不例外，我一洗漱完就飛奔坐在電腦前，打開B站舞蹈區(qū)準(zhǔn)備學(xué)習(xí)咬人喵，欣小萌、小仙若他們新的舞蹈動作，不得不說老婆們跳的真好，連我這種內(nèi)向的人也不自覺的跟著扭動了起來。

正當(dāng)我準(zhǔn)備學(xué)下一個動作的時候，我發(fā)現(xiàn)怎么404 NOT found了。

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

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

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

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

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

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

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

視頻訪問存儲

• 流
• 就近節(jié)點
• 視頻編解碼
• 斷點續(xù)傳(跟我們寫的io例子差多)
• 數(shù)據(jù)庫系統(tǒng)&文件系統(tǒng)隔離

并發(fā)訪問

• 流媒體服務(wù)器(各大廠商都有，帶寬成本較大)
• 數(shù)據(jù)集群，分布式存儲、緩存
• CDN內(nèi)容分發(fā)
• 負載均衡
• 搜索引擎(分片)

彈幕系統(tǒng)

• 并發(fā)、線程
• kafka
• nio框架(netty)

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

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

1.刪庫跑路

之前微盟發(fā)生過這個事情，我覺得各個公司應(yīng)該都不會把運維的權(quán)限給這么大了，比如主機權(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)資源都無法訪問了。

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

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

[[411115]]

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

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

但是我比較疑惑的是B站的BFF應(yīng)該會路由到一些接入節(jié)點比較近的機房，這樣全國各地的小伙伴刷的時候，應(yīng)該是有些人好，有些人壞，有些人時好時壞才對，但是現(xiàn)在看來是全壞了，難道他們押寶了一個廠商的一個節(jié)點片區(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)該不會他自己的機房出問題。

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

復(fù)盤

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

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

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

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

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

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

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

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

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

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

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

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

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