B 站崩，小紅書崩，罪魁禍?zhǔn)拙谷皇恰！ｋy繃！

大家好，我是程序員魚皮。

今天上午 10 點(diǎn) ~ 11 點(diǎn)左右，B 站和小紅書都崩了，出現(xiàn)了不同程度的故障。

根據(jù)用戶反饋，B 站崩潰時(shí)，無(wú)法刷新內(nèi)容和評(píng)論區(qū)，也發(fā)不了評(píng)論和彈幕，而且用戶主頁(yè)、消息界面、客服頁(yè)面均不可用。具體表現(xiàn)為用戶訪問(wèn)某些頁(yè)面時(shí)會(huì)看到 -500 錯(cuò)誤碼，評(píng)論區(qū)列表一直顯示為 “加載中” 等等。

這是什么概念？給我的感覺(jué)是，大半個(gè) B 站基本都崩了，就很離譜！

一般情況下，像 B 站這種大用戶量、大規(guī)模的平臺(tái)，肯定是使用微服務(wù)等架構(gòu)獨(dú)立部署各個(gè)模塊的，但是這次竟然這么多功能一起崩掉了？魚皮大膽猜測(cè)，應(yīng)該是公共服務(wù)或者是底層基礎(chǔ)設(shè)施出現(xiàn)了問(wèn)題。

何為公共服務(wù)？比如用戶服務(wù)，幾乎所有面向用戶的模塊都會(huì)調(diào)用到用戶服務(wù)來(lái)獲取用戶信息。仔細(xì)觀察可以發(fā)現(xiàn)，B 站崩潰的功能基本都是和用戶強(qiáng)相關(guān)的。比如用戶要發(fā)送評(píng)論，沒(méi)有用戶信息，怎么能讓他發(fā)送呢？要看用戶主頁(yè)，獲取不到用戶信息，看個(gè)毛呢？

當(dāng)然，以上僅僅是我的猜測(cè)。這次和 B 站一起崩掉的，還有小紅書、酷安網(wǎng)、戀與深空等等，這就意味著事情并沒(méi)有那么簡(jiǎn)單，絕對(duì)不只是 B 站自己的鍋。

根據(jù)網(wǎng)上的信息，在差不多同一時(shí)間， 阿里云的網(wǎng)絡(luò)訪問(wèn)服務(wù)出了問(wèn)題。

北京時(shí)間 2024 年 07 月 02 日 10:04 分，也就是 B 站崩掉的時(shí)候，阿里云監(jiān)控發(fā)現(xiàn)上海地域可用區(qū) N 網(wǎng)絡(luò)訪問(wèn)出現(xiàn)了異常。如圖：

不過(guò)很快，阿里云就完成了網(wǎng)絡(luò)切流調(diào)度，并且很快恢復(fù)了上海可用區(qū) N 的網(wǎng)絡(luò)，過(guò)了一段時(shí)間后，崩掉的系統(tǒng)都開始陸續(xù)恢復(fù)。

解釋一下什么是可用區(qū) N 網(wǎng)絡(luò)。可用區(qū)是指在同一地域內(nèi)，電力和網(wǎng)絡(luò)互相獨(dú)立的物理區(qū)域。例如，華北2（北京）地域支持 12 個(gè)可用區(qū)，包括北京可用區(qū) A 和北京可用區(qū) B 等。同一可用區(qū)內(nèi)實(shí)例之間的網(wǎng)絡(luò)延時(shí)更小，其用戶訪問(wèn)速度更快。

而 B 站和小紅書的總部正好都在上海，所以選擇了阿里云的上海可用區(qū)，提高網(wǎng)絡(luò)訪問(wèn)速度，這很合理；然后給他們提供服務(wù)的阿里云的上海地域的網(wǎng)絡(luò)出了問(wèn)題，導(dǎo)致他們崩掉，這再合理不過(guò)了。

網(wǎng)絡(luò)訪問(wèn)異常的后果想必大家都經(jīng)歷過(guò)，比如你家里網(wǎng)絡(luò)中斷時(shí)，就無(wú)法訪問(wèn)網(wǎng)站。而同樣的，依賴網(wǎng)絡(luò)去傳輸數(shù)據(jù)的 B 站，一旦網(wǎng)絡(luò)中斷，各種依賴該網(wǎng)絡(luò)的 API、服務(wù)調(diào)用都會(huì)故障，就導(dǎo)致無(wú)法獲取到展示給用戶的數(shù)據(jù)。

事實(shí)上，哪怕是阿里云，網(wǎng)絡(luò)故障這類事件也無(wú)法完全避免。舉個(gè)極端的例子，因?yàn)橐恍庀笤颉⒒蛘哂袀€(gè)不法分子把網(wǎng)線鏟斷了，都可能會(huì)導(dǎo)致網(wǎng)絡(luò)故障。不過(guò)阿里云通過(guò)劃分可用區(qū)，起碼保證故障不會(huì)影響到多個(gè)地域。而且通過(guò)網(wǎng)絡(luò)切留調(diào)度，快速將系統(tǒng)切換到另一個(gè)可用網(wǎng)絡(luò)，解決速度也還算高效。

通過(guò)這次故障，我們能夠了解到大廠工程師應(yīng)對(duì)此類問(wèn)題的解決方案。

B 站和小紅書都采用了 服務(wù)降級(jí) 的策略，比如 B 站的做法是提供一個(gè)加載出錯(cuò)的頁(yè)面，引導(dǎo)用戶稍后再試。

雖然有些頁(yè)面降級(jí)的不夠優(yōu)雅，把錯(cuò)誤碼和英文的報(bào)錯(cuò)信息返回給了用戶。。

小紅書的策略不太一樣，故障的表現(xiàn)是無(wú)法刷新內(nèi)容、并且首頁(yè)刷出來(lái)的不是用戶的推薦內(nèi)容：

但用戶還是能夠看到一些內(nèi)容的，如圖：

小紅書應(yīng)該是使用了緩存作為降級(jí)策略，比如無(wú)法通過(guò)網(wǎng)絡(luò)獲取到用戶推薦的信息流，那么就直接從分布式緩存或者服務(wù)器本地的緩存中獲取一些默認(rèn)內(nèi)容即可。

當(dāng)然，還有一種可能，就是沒(méi)走緩存，而是改為調(diào)用獲取公共信息流的服務(wù)。舉個(gè)例子，假如小紅書的熱門板塊沒(méi)有故障，那么 APP 主頁(yè)可以獲取熱門板塊的數(shù)據(jù)，而不用獲取故障的推薦信息流。

這讓我想起來(lái)，之前在騰訊的時(shí)候，導(dǎo)師跟我說(shuō)過(guò) “不要信任第三方服務(wù)”。也就是說(shuō)，我們要遵循防御性編程，假設(shè)第三方系統(tǒng)一定會(huì)出現(xiàn)故障，并且提前做好應(yīng)對(duì)它的準(zhǔn)備。比如使用了 XX 云的數(shù)據(jù)同步，即使官方承諾說(shuō)同步不會(huì)出現(xiàn)數(shù)據(jù)丟失，我們也要考慮到數(shù)據(jù)丟失的可能性，在業(yè)務(wù)代碼中編寫應(yīng)對(duì)策略。

雖然本次故障無(wú)法預(yù)料，但是對(duì)于 B 站這樣大型的公司來(lái)說(shuō)，我覺(jué)得應(yīng)該還是有應(yīng)對(duì)之法的。比如將服務(wù)跨可用區(qū)部署，不止將服務(wù)部署在阿里云可用區(qū) N 網(wǎng)絡(luò)，還可以部署在上海的其他可用區(qū)；還可以采用多云部署，同時(shí)將服務(wù)部署在其他云服務(wù)提供商，發(fā)現(xiàn)阿里云寄了，就自動(dòng)切換到其他服務(wù)商；甚至還可以采用異地多活，在不同地理位置同時(shí)運(yùn)行同一個(gè)服務(wù)，從而提高可用性和容災(zāi)能力。

當(dāng)然，理論歸理論，B 站可能也用到了這些策略，或者有自己不用這些策略的原因（比如成本），由于咱也不是內(nèi)部人士，只能通過(guò)有限的信息隨便聊聊，也給大家科普一些開發(fā)知識(shí)。相信不久后官方就會(huì)發(fā)布事故復(fù)盤報(bào)告啦~

???? 點(diǎn)擊下方閱讀原文，獲取魚皮往期編程干貨。