大家好,我是碼哥,可以叫我靚仔。
作為靚仔,是應該經常打開 B 站的,畢竟里面很多美好的“東西”,結果出現網絡錯誤,我以為由于日夜觀摩 B 站的視頻導致流量超了。
吃瓜雖好,可不要貪杯。我們的重點是根據 B 站、小紅書服務故障來聊聊高可用架構的一些設計思路。
在 2020-07-02 上午 10 點~11 點左右,B 站和小紅書都崩了,出現了不同程度的故障。
打開微博, 看到 #B 站(嗶哩嗶哩)、小紅書崩了# 的話題相繼登上熱搜。
圖片
還有網友反映小紅書首頁內容無法刷新。有的則表示刷出來的內容也不是我的推薦。
圖片
圖片
圖片
@酷安網 也發文表示網站崩了。隨后,阿里云客戶服務中心回復:北京時間 2024 年 07 月 02 日 10:04,阿里云監控發現上海地域可用區 N 網絡訪問出現異常,阿里云工程師正在緊急處理中。
圖片
B 站、小紅書崩了之后,對于阿里云的回應,網友認為裁員裁到大動脈了有網友認為,這次是阿里云裁員裁到大動脈了。
碼哥跳動
Infoq簽約作者,51CTO Top紅人,阿里云開發者社區專家博主,擔任后端架構師職責,擅長 Redis,Spring,Kafka,MySQL技術和云原生微服務。愿大家擁抱硬核技術和對象,面向人民幣編程。
169篇原創內容
公眾號
言歸正傳,吃瓜歸吃瓜,我們應該從阿里云的網絡切換故障,看到一些高可用的解決方案。
雖然網絡故障,B 站、并不是所有的網頁打不開,而且系統并沒有垮掉,依然返回相關錯誤信息或者頁面給用戶。我們也能從里面了解到大廠工程師如何應對此問題的解決方案。
從這次的故障可以看出,B 站和小紅書的系統均滿足系統服務可降級。
B 站的做法是提供一個加載錯誤的頁面,引導用戶重試。
圖片
小紅書的降級策略有所不同,因為其表現為無法刷新內容,首頁刷出來的內容不是用戶推薦的。
所以小紅書的降級策略是使用了緩存作為降級,比如平臺無法通過網絡獲取用戶推薦的信息流時,就直接從緩存系統或者服務器本地的緩存中獲取一些內容返回給用戶。
這些也是只碼哥根據有限的信息哥大家聊聊,估計不久就會有官方的反饋了。本次故障相當于驗證了一把 B 站和小紅書的高可用是否足夠強大。
系統宕機原因主要有以下:
無計劃的
有計劃的
分個類。
系統出現問題的地方很多,解決的方式各不相同,想要解決問題,先說下高可用的總體解決思路,才能更好的解決問題。
想要系統高可用,我們要想辦法避免問題的發生。比如說,我們可以通過 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 技術和云原生微服務。
本文鏈接:http://www.tebozhan.com/showinfo-26-98421-0.html高可用架構下 B 站、小紅書崩了?對于阿里回應,網友認為裁員裁到大動脈
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。郵件:2376512515@qq.com
上一篇: Python用戶寶典:了解并實現遺傳算法