大家好，我是碼哥，可以叫我靚仔。

作為靚仔，是應該經常打開 B 站的，畢竟里面很多美好的“東西”，結果出現網絡錯誤，我以為由于日夜觀摩 B 站的視頻導致流量超了。

吃瓜雖好，可不要貪杯。我們的重點是根據 B 站、小紅書服務故障來聊聊高可用架構的一些設計思路。

B 站、小紅書崩了

在 2024-07-02 上午 10 點~11 點左右，B 站和小紅書都崩了，出現了不同程度的故障。

打開微博， 看到 #B 站（嗶哩嗶哩）、小紅書崩了# 的話題相繼登上熱搜。

圖片

用戶反饋，B 站崩潰，無法拉取新內容和評論區，用戶主頁、消息界面、客服頁面均不可用。有的頁面會返回 -500 錯誤，視頻評論區則一直顯示“加載中”。

圖片

還有網友反映小紅書首頁內容無法刷新。有的則表示刷出來的內容也不是我的推薦。

圖片

圖片

圖片

@酷安網 也發文表示網站崩了。隨后，阿里云客戶服務中心回復：北京時間 2024 年 07 月 02 日 10:04，阿里云監控發現上海地域可用區 N 網絡訪問出現異常，阿里云工程師正在緊急處理中。

圖片

B 站、小紅書崩了之后，對于阿里云的回應，網友認為裁員裁到大動脈了有網友認為，這次是阿里云裁員裁到大動脈了。

高可用架構

言歸正傳，吃瓜歸吃瓜，我們應該從阿里云的網絡切換故障，看到一些高可用的解決方案。

雖然網絡故障，B 站、并不是所有的網頁打不開，而且系統并沒有垮掉，依然返回相關錯誤信息或者頁面給用戶。我們也能從里面了解到大廠工程師如何應對此問題的解決方案。

從這次的故障可以看出，B 站和小紅書的系統均滿足系統服務可降級。

B 站的做法是提供一個加載錯誤的頁面，引導用戶重試。

圖片

小紅書的降級策略有所不同，因為其表現為無法刷新內容，首頁刷出來的內容不是用戶推薦的。

所以小紅書的降級策略是使用了緩存作為降級，比如平臺無法通過網絡獲取用戶推薦的信息流時，就直接從緩存系統或者服務器本地的緩存中獲取一些內容返回給用戶。

這些也是只碼哥根據有限的信息哥大家聊聊，估計不久就會有官方的反饋了。本次故障相當于驗證了一把 B 站和小紅書的高可用是否足夠強大。

故障來源

系統宕機原因主要有以下：

無計劃的

• 系統級故障，包括主機、操作系統、中間件、數據庫、網絡、電源以及外圍設備。
• 數據和中介的故障，包括人員誤操作、硬盤故障、數據亂了。
• 還有自然災害、人為破壞，以及供電問題等。

有計劃的

• 日常任務：備份，容量規劃，用戶和安全管理，后臺批處理應用。
• 運維相關：數據庫維護、應用維護、中間件維護、操作系統維護、網絡維護。
• 升級相關：數據庫、應用、中間件、操作系統、網絡，包括硬件升級。

分個類。

1. 網絡問題。網絡鏈接出現問題，網絡帶寬出現擁塞……
2. 性能問題。數據庫慢 SQL、Java Full GC、硬盤 IO 過大、CPU 飆高、內存不足……
3. 安全問題。被網絡攻擊，如 DDoS 等。
4. 運維問題。系統總是在被更新和修改，架構也在不斷地被調整，監控問題……
5. 管理問題。沒有梳理出關鍵服務以及服務的依賴關系，運行信息沒有和控制系統同步……
6. 硬件問題。硬盤損壞、網卡出問題、交換機出問題、機房掉電、挖掘機問題……

高可用架構原則

系統出現問題的地方很多，解決的方式各不相同，想要解決問題，先說下高可用的總體解決思路，才能更好的解決問題。

避免發生

想要系統高可用，我們要想辦法避免問題的發生。比如說，我們可以通過 UPS（Uninterruptible Power System，不間斷電源）來避免服務器斷電。

故障轉移

如果問題真的發生了，我們要考慮的是如何故障轉移，比如說，我們可以通過冗余部署，當一個節點發生故障時，用其它正常的節點來代替問題節點。

主從復制

幾乎所有的存儲系統都提供了主從復制的功能，例如 MySQL、Redis、MongoDB 等。

主從復制要點：

• 存在一主多從。
• 主機負責讀&寫，并定期復制數據給從機。
• 從機只負責讀。
• 一旦主機宕機，可以通過人工手段，將其中一個從節點作為主節點。

圖片

圖片來源https://raw.githubusercontent.com/dunwu/images/master/snap/20200614184921.png

分片集群

主從復制有一個問題，每個機器上存儲的都是全量數據。

但是，單機的數據存儲量總是有上限的，當數據量上升為 TB 級甚至 PB 級數據，單機終究有無法支撐的時候。這時，就需要對數據進行分片（sharding）。

分片后的節點可以視為一個獨立的子集，每個子集也要保證高可用降級：系統拋棄部分不重要的功能，比如不發送短信通知，以此確保核心功能不受影響。。

圖片

圖片來源https://raw.githubusercontent.com/dunwu/images/master/snap/20200614184921.png

服務可降級

如果故障無法正面方式解決，那我們要做的就是努力降低故障帶來的影響。比如說流量太大，我們可以通過限流，來保證部分用戶可以正常使用，或者通過業務降級的手段，關閉一些次要功能，保證核心功能仍舊可用。

這次 B 站、小紅書亦是采取了該方案。

限流

限流則是從用戶訪問壓力的角度來考慮如何應對故障。限流指只允許系統能夠承受的訪問量進來，超出系統訪問能力的請求將被丟棄。

降級

降級指系統將某些業務或者接口的功能降低，可以是只提供部分功能，也可以是完全停掉所有功能。比如 B 站返回錯誤引導頁，以此確保核心功能不受影響。

拒絕服務 - 拒絕低優先級應用的調用，減少服務調用并發數，確保核心應用正常使用。或者隨機拒絕部分調用，節約資源，避免要死大家一起死的慘劇。

關閉服務 - 關閉部分不重要的服務，或者服務內部關閉部分不重要的功能，以節約資源。

熔斷

熔斷和降級是兩個比較容易混淆的概念，因為單純從名字上看好像都有禁止某個功能的意思，但其實內在含義是不同的，原因在于降級的目的是應對系統自身的故障，而熔斷的目的是應對依賴的外部系統故障的情況。

我們不去調用出問題的服務，讓系統繞開故障點，就像電路的保險絲一樣，自己熔斷，切斷通路，避免系統資源大量被占用

監控

在實踐中，系統的故障防不勝防，問題的定位和解決也非常的困難，所以，要想全面保障系統的可用性，最重要的手段就是監控。

通過監控，我們可以實時地了解系統的當前狀態，這樣很多時候，業務還沒出問題，我們就可以提前干預，避免事故；而當系統出現問題時，我們也可以借助監控信息，快速地定位和解決問題。

博主簡介

碼哥，9 年互聯網公司后端工作經驗，InfoQ 簽約作者、51CTO Top 紅人，阿里云開發者社區專家博主，目前擔任后端架構師主責，擅長 Redis、Spring、Kafka、MySQL 技術和云原生微服務。