[[411114]]

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

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

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

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

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

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

首先我們可以大致畫(huà)一下簡(jiǎn)單的一個(gè)網(wǎng)站組成的架構(gòu)圖，我們?cè)偃ゲ孪脒@次問(wèn)題可能出在什么地方。

因?yàn)榘疽箤?xiě)文章哈，我也沒(méi)在這種主要靠視頻直播的公司呆過(guò)，技術(shù)棧也不是很了解，所以就用電商的大概邏輯，畫(huà)了一個(gè)草圖，大家輕點(diǎn)噴。

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

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

視頻訪問(wèn)存儲(chǔ)

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

并發(fā)訪問(wèn)

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

彈幕系統(tǒng)

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

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

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

1.刪庫(kù)跑路

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

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

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

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

不過(guò)這個(gè)點(diǎn)我覺(jué)得也有一點(diǎn)可能，因?yàn)椴糠址?wù)掛了，導(dǎo)致大量報(bào)錯(cuò)，拉掛了集群，而且越是這樣大家越會(huì)不斷刷新頁(yè)面，給其他服務(wù)重啟增加難度，但是這個(gè)可能性沒(méi)我最后說(shuō)的可能性大。

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

[[411115]]

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

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

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

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

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

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

復(fù)盤(pán)

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

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

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

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

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

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

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

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

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

對(duì)方萬(wàn)一買(mǎi)了去挖礦，那更過(guò)分，把算力榨干，滿負(fù)荷跑更難受。

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

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

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