建站
咨詢
售后
建站咨詢
新聞中心
大家都知道雖然我是一個程序員，但是我非常熱愛運動，比如跳舞，這不每天回家睡前我都會在B站舞蹈區(qū)學習相關的舞蹈。
創(chuàng)新互聯公司堅持“要么做到，要么別承諾”的工作理念，服務領域包括：網站建設、成都網站設計、企業(yè)官網、英文網站、手機端網站、網站推廣等服務，滿足客戶于互聯網時代的平陰網站設計、移動媒體設計的需求，幫助企業(yè)找到有效的互聯網解決方案。努力成為您成熟可靠的網絡建設合作伙伴！
昨天也不例外，我一洗漱完就飛奔坐在電腦前，打開B站舞蹈區(qū)準備學習咬人喵，欣小萌、小仙若他們新的舞蹈動作，不得不說老婆們跳的真好，連我這種內向的人也不自覺的跟著扭動了起來。
正當我準備學下一個動作的時候，我發(fā)現怎么404 NOT found了。
壞了，作為開發(fā)的我第一直覺是系統崩了，我甚至懷疑是我網的問題，我發(fā)現手機網絡正常電腦訪問其他網頁也正常，我就知道開發(fā)要背鍋了。
我刷新了幾次，發(fā)現還是這樣，我就有點同情對應的開發(fā)同學了，年終應該沒了。(到我寫這個文章的時候網站還沒恢復)
作為前程序員的我，就習慣性的去想B站的網站架構組成，以及這次事故復盤下來，可能會出問題的點。(老職業(yè)習慣了)
首先我們可以大致畫一下簡單的一個網站組成的架構圖，我們再去猜想這次問題可能出在什么地方。
因為熬夜寫文章哈，我也沒在這種主要靠視頻直播的公司呆過，技術棧也不是很了解，所以就用電商的大概邏輯，畫了一個草圖，大家輕點噴。
從上到下，從入口到cdn內容分發(fā)，到前端服務器，后端服務器，分布式存儲，大數據分析，風控到搜索引擎推薦這我就隨便畫了一下，我想整體架構應該不會差異特別大。
我去網上隨便查了一些類似斗魚，B站，a站這樣的公司，主要技術棧和技術難點主要有：
視頻訪問存儲
- 流
- 就近節(jié)點
- 視頻編解碼
- 斷點續(xù)傳(跟我們寫的io例子差多)
- 數據庫系統&文件系統隔離
并發(fā)訪問
- 流媒體服務器(各大廠商都有，帶寬成本較大)
- 數據集群，分布式存儲、緩存
- CDN內容分發(fā)
- 負載均衡
- 搜索引擎(分片)
彈幕系統
- 并發(fā)、線程
- kafka
- nio框架(netty)
其實跟我們大家學的技術都差不多，不過他們的對應微服務的語言組成可能go、php、vue、node占比比較大。
我們分析下這次事故可能出事的原因和地方：
1.刪庫跑路
之前微盟發(fā)生過這個事情，我覺得各個公司應該都不會把運維的權限給這么大了，比如主機權限直接禁止了rm-rf、fdisk、drop這樣的命令。
而且數據庫現在大概率都是多主多從，多地備份的，容災也應該是做的很好的，而且光是數據庫炸了，那cdn的很多靜態(tài)資源應該也不會加載不出，整個頁面直接404了。
2.單微服務掛掉拖垮大集群
現在都是前后端分離的，如果是后端掛了，前端很多東西依然是能加載只是數據出不來報錯，所以集群要掛也可能是前端掛了，或者前后端一起掛了，但是還是那個問題，現在看起來是所有靜態(tài)資源都無法訪問了。
不過這個點我覺得也有一點可能，因為部分服務掛了，導致大量報錯，拉掛了集群，而且越是這樣大家越會不斷刷新頁面，給其他服務重啟增加難度，但是這個可能性沒我最后說的可能性大。
3.服務器廠商出問題了
這種大網站都是cdn+slb+站集群，各種限流降級、負載均衡按道理都會做的很好，而且他們按道理不會不做容災。
所以只有可能是這些前置服務的服務器廠商出問題了，CDN如果掛了那網關負載均衡啥的壓力都大了，最后導致連鎖的雪崩效應打掛了整套系統。
但是我比較疑惑的是B站的BFF應該會路由到一些接入節(jié)點比較近的機房，這樣全國各地的小伙伴刷的時候，應該是有些人好，有些人壞，有些人時好時壞才對，但是現在看來是全壞了，難道他們押寶了一個廠商的一個節(jié)點片區(qū)?
我看網上也在傳云海數據中心起火了，不知道真假，只能等醒來看看B站官宣了，B站原則上，理論上，從CDN、分布式存儲、大數據、搜索引擎都應該做了很多保證措施才對，如果真all in了一個地方那確實不太明智。
我的感覺就是沒做好全部上云，線下的服務器出了問題，剛好是沒上云的是關鍵業(yè)務，現在公司都是公有云+私有云這樣的混合云搭配用的，但是私有云部分都是B站自己的內部業(yè)務，所以應該不會他自己的機房出問題。
如果真像我說的，押寶了一個服務器廠商，只是cdn出問題還好，如果物理機還出問題了，那數據恢復可能就慢了，我自己之前做大數據的，我知道數據備份都是增量+全量，恢復的時候真的好了一部分還可以從其他地區(qū)節(jié)點拉，但是如果是放在一個地方了，那就麻煩了。
復盤
我想不管最后是什么原因造成的，我們技術人和公司應該思考的就是怎么去避免這樣事情的發(fā)生。
數據備份： 備份一定要做，不然如果真發(fā)生什么自然災害，那是很難受的，所以很多云廠商現在都選在貴州我老家這樣自然災害比較少的地方、或者湖底、海底(比較涼快成本能下去不少)。
全量、增量基本上都是一直要做的，分天、周、月不斷的增量數據，以及按時的全量數據備份，這樣可以讓損失降低很多，就怕所有地區(qū)的機械盤都壞了(異地容災除了地球毀滅不然都能找回來)。
運維權限收斂，還是怕刪庫跑路，反正我是經常在服務器上rm-rf，不過一般有跳板機才能進去的都可以做命令禁止。
上云+云原生： 云產品的各種能力現在很成熟的，企業(yè)應該對對應的云廠商有足夠的信任，當然也得選對才行，云產品的各種能力是其一，還有關鍵時刻的容災、應急響應機制都是很多公司不具備的。
云原生是近些年大家才重視的技術，docker+k8s這對應的一些組合，加上云計算的各種能力，其實可以做到無人值守，動態(tài)縮擴容，以及上面說的應急響應，但是技術本身是需要一些嘗試成本的，而且我也不知道B站這樣視頻為主的體系，適不適合。
kubernetes的設計上也會存在一些編排、通信的問題。
自身實力打造： 其實我覺得不管是上云，還是不上云，都不能太依賴很多云廠商，自己的核心技術體系和應急機制還是要有，如果云廠商真的靠不住怎么辦?怎么去做真正的高可用，這我覺得是企業(yè)技術人員需要去思考的。
舉個例子，很多云廠商都是一個物理機隔成多個虛擬機售賣，然后就會存在單物理機多宿主的情況，假如其中一方是電商玩雙十一，一方是游戲廠商，對方大量占用網絡帶寬，你就可能存在丟包的情況，這對游戲用戶來說是體驗極差的，這樣就是我說為啥不要過于信任和依賴云廠商的原因。
對方萬一買了去挖礦，那更過分，把算力榨干，滿負荷跑更難受。
B站這次，好在這樣的問題提前暴露了，而且是晚上，應該有不少流量低谷的時間去恢復，我寫到這里的時候，網頁大部分恢復了，但是我發(fā)現還是部分恢復。
不管怎么說下次就可以完全杜絕了，相信B站后面很長一段時間都會忙于架構體系改造，去保證自己真正的高可用。
希望以后能讓我穩(wěn)定的在晚上看看舞蹈區(qū)，而不是盯著502、404的2233娘發(fā)呆，嘻嘻
網站欄目：B站崩了，如何防止類似事故的出現？
路徑分享：http://www.5511xx.com/article/djhdsic.html
