14日凌晨，B站發佈消息稱：
昨晚，B站的部分服務器機房發生故障，造成無法訪問。技術團隊隨即進行了問題排查和修復，現在服務已經陸續恢復正常。耽誤大家看視頻了，對不起！
已知：
- Bilibili，Acfun，豆瓣都出現崩潰404.
- 豆瓣和Acfun很快恢復，Bilibili大約用了一個小時讓用戶能夠正常訪問。
- Bilibili直播是可以正常觀看的，朋友看喫雞直播沒有受到影響。
- B站高可用用架構實踐 - 雲+社區 - 騰訊雲 (tencent.com)
- 根據上面文章可知，Bilibili的LB（負載均衡器）是自研的，一系列爲了高可用配套的服務和中間件都是自研的。
- 在逐漸可以訪問主站時，推薦系統並沒有推薦正常的視頻給用戶。
看知乎餘歌[1]分析說：
a. Bilibili、Acfun、豆瓣等的雲服務供應商出現了問題。但是不清楚CDN出現問題還是掛載着容器的機器出問題
假設是容器出現問題，一個工作正常的LB會訪問其他可用的容器。在這種情況下很難出現昨天的問題，畢竟Bilibili這麼大一公司也不會把雞蛋放在一個籃子裏，肯定是異地多機房容災。而且Bilibili這種大型視頻網站，讀請求和讀流量肯定大部分走的都是CDN和緩存，發生這種情況的概率要小很多，另一種情況的概率很大。
那麼另一種可能是CDN出現了問題，假設CDN出現了問題，大量讀請求發送到CDN，由於供應商出現意外，請求無法在CDN上找到資源，大量請求回源到Bilibili主站。這是一個比較合理的情況。
進行了一個猜測。7 / 14 Bilibili出現問題的整體流程可能如下：
1. 雲服務供應商出現意外，大量請求繞過CDN直接打到應用網關，多家互聯網公司的主站發生無法訪問的現象。
2.1 豆瓣，Acfun等公司的運維收到告警，緊急切換了CDN，或啓動了容災策略進行降流，系統正常對外提供服務。
2.2 Bilibili同樣收到告警，啓動了容災策略，但是當時正是Bilibili流量高峯期，有兩個可能：
2.2.1 自研的LB沒辦法處理這麼多請求，直接崩了
但是如果LB崩了，只需要切換CDN並且重啓LB就可以成功繼續對外服務了，對於Bilibili來說這個概率要小一些。
2.2.2 自研的降流有問題，導致大量請求發送到後續底層服務，服務雪崩，整個環境炸了。
結合上述提到的事實，我個人認爲服務雪崩的概率要更大一些。現代的微服務系統是一個相當龐大的系統，當整個系統出現問題時，重啓需要的時間是相當大的。評論區有說到k8s重啓很快，針對單個容器的啓動確實很快，Bilibili這麼大一公司，一整個後端系統至少要重啓幾十上百個不同的容器才能才能一定程度上對外保持服務，這些容器也要好幾百甚至上千個副本才能正常扛下高峯期流量。結合Bilibili成功訪問經過的時間，我認爲這樣的流程是相對合理的。結合事實[2]和[5]，佐證了Bilibili的運維按照優先級重啓了各個容器組，Bilibili的服務正在逐漸恢復。
總的來說主要就刪庫跑路、單個微服務拖垮大集羣、服務器廠商着火、被蒙古上單刺殺幾種情況。刪庫跑路現在的運維基本都分級操作，一般不會給這樣的權限，幾乎排除。上海服務器着火也被上海消防排除，並未發現火情。蒙古上單一直沒有迴應，排除。所以極大可能是單個微服務拖垮大集羣，也就是上面博主分析的那樣。[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-tl54BBWI-1626315215563)![(C:/Users/win10/AppData/Local/Temp/enhtmlclip/Image.png)]](https://pic1.xuehuaimg.com/proxy/refer/https://img-blog.csdnimg.cn/20210715101427351.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tuaWdodDc3NjU=,size_16,color_FFFFFF,t_70)
以及，b站高可用架構實踐的Q&A：
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-QUxpHCp8-1626315215576)(C:/Users/win10/AppData/Local/Temp/enhtmlclip/Image(1)].png)
具體原因還是等後續公佈吧，咱來對上述技術點，我們進行部分學習回顧。
對於b站 a站這種，核心技術點如下：
視頻訪問存儲
- 流
- 就近節點
- 視頻編解碼
- 斷點續傳（跟我們寫的io例子差多）
- 數據庫系統&文件系統隔離
併發訪問
- 流媒體服務器（各大廠商都有，帶寬成本較大）
- 數據集羣，分佈式存儲、緩存
- CDN內容分發
- 負載均衡搜索引擎（分片）
彈幕系統
- 併發、線程
- kafka
- nio框架（netty）
其實跟我們大家學的技術都差不多，大部分技術體系差不多，不過語言應該是go爲主，前端框架vue，node爲主。
此次事故中出現的熱點名詞大致如下：CDN，降級，熔斷，分佈式存儲，備份回滾數據等等。下面對主要關鍵詞進行解析：
先來看下什麼是CDN。
CDN全稱：content Delivery Network ;內容分發網絡， 是建立並覆蓋在承載網之上，由分佈在不同區域的邊緣節點服務器羣組成的分佈式網絡。在用戶訪問高峯期，圖片、音視頻內容大批量發生變化，大量用戶的訪問就會穿透cdn，對源站造成巨大的壓力。
就淘寶而言， 圖片的訪問鏈路有三級緩存（客戶端本地、CDN L1、CDN L2），所有圖片都持久化的存儲到OSS中。[3]
這樣會帶來2個問題：
（1）CDN及手機淘寶原本緩存的圖片內容失效了，用戶訪問圖片會全部回源到img-picasso。
（2）由於更改了商品的字段，交易的核心應用（購物車和商品中心）的緩存也失效了，用戶瀏覽及購物時，對商品的訪問會走到db。源站img-picasso處理圖片，以及查詢商品DB，都是非常消耗資源的。CDN及商品的緩存命中率降低後，對源站img-picsasso以及db會產生巨大的壓力。
拿CDN緩存爲例，簡單計算一下，CDN平時的命中率是98%，假設命中率降低1個點，對源站的壓力就會增加1/3（原本承擔2%的流量，現在需要承擔3%的流量），意味着img-picasso需要擴容1/3。如果全網一半的圖片都同時變化，cdn的命中率降到50%，對img-picasso的訪問量就會增加25倍，這個擴容成本肯定沒法接受。
服務雪崩
如圖所示，一個服務失敗，導致整條鏈路服務都崩潰，稱爲服務雪崩。[2]
當你頻繁更換圖片時，
解決災難性雪崩效應的方式：
1.降級
超時降級、資源不足時(線程或信號量)降級，降級後可以配合降級接口返回託底數據。
服務降級有很多種降級方式！如開關降級、限流降級、熔斷降級!
服務熔斷屬於降級方式的一種！
撇開框架，以最簡單的代碼來說明！上游代碼如下
try{//調用下游的helloWorld服務xxRpc.helloWorld();}catch(Exception e){//因爲熔斷，所以調不通doSomething();}
注意看，下游的helloWorld服務因爲熔斷而調不通。此時上游服務就會進入catch裏頭的代碼塊，那麼catch裏頭執行的邏輯，你就可以理解爲降級邏輯!
服務降級大多是屬於一種業務級別的處理。當然，我這裏要講的是另一種降級方式，也就是開關降級 !
這也是我們生產上常用的另一種降級方式！做法很簡單，做個開關，然後將開關放配置中心！在配置中心更改開關，決定哪些服務進行降級。至於配置變動後，應用怎麼監控到配置發生了變動，這就不是本文該討論的範圍。
那麼，在應用程序中部下開關的這個過程，業內也有一個名詞，稱爲埋點！
那接下來最關鍵的一個問題，哪些業務需要埋點？
一般有以下方法
(1)簡化執行流程自己梳理出核心業務流程和非核心業務流程。然後在非核心業務流程上加上開關，一旦發現系統扛不住，關掉開關，結束這些次要流程。
(2)關閉次要功能一個微服務下肯定有很多功能，那自己區分出主要功能和次要功能。然後次要功能加上開關，需要降級的時候，把次要功能關了吧！
(3)降低一致性假設，你在業務上發現執行流程沒法簡化了，愁啊！也沒啥次要功能可以關了，桑心啊！那隻能降低一致性了，即將核心業務流程的同步改異步，將強一致性改最終一致性！
2.隔離（線程池隔離和信號量隔離）限制調用分佈式服務的資源使用，某一個調用的服務出現問題不會影響其他服務調用。
3.熔斷當失敗率(如因網絡故障/超時造成的失敗率高)達到閥值自動觸發降級，熔斷器觸發的快速失敗會進行快速恢復。服務熔斷：當下遊的服務因爲某種原因突然變得不可用或響應過慢，上游服務爲了保證自己整體服務的可用性，不再繼續調用目標服務，直接返回，快速釋放資源。如果目標服務情況好轉則恢復調用
4.降級熔斷當Service A調用Service B，失敗多次達到一定閥值，Service A不會再去調Service B，而會去執行本地的降級方法！對於這麼一套機制:在Spring cloud中結合Hystrix,將其稱爲熔斷降級!與服務降級區別不同。
最後不管怎樣，都要祝B站越辦越好咯！b站崩了，知乎熱榜第一，微博熱榜第一，不愧是年輕人聚集的地方，bilibili，乾杯！
