Facebook + Instagram + WhatsApp 同時故障，損失上億美金

業餘草發表於2019-03-15

點選上方“業餘草”，選擇“置頂公眾號”

第一時間獲取技術乾貨和業界資訊！

640?wx_fmt=png

相信不少人今天上班時候，被各大新聞網站彈出一條訊息，類似 Facebook 全球發生故障之類的新聞。

Facebook 做為全球少有的幾大網際網路巨頭，發生點故障就能引起巨大的波瀾。Facebook 全球十幾億使用者，一時間大家上不了 Facebook。除此之外，Facebook 的 Instagram、WhatsApp 等熱門應用也同時發生故障。

這就是一個典型的故障雪崩效應。一個系統故障，發生雪崩，蔓延至其他系統。這也說明了，Facebook 的熔斷機制，斷路器，短路保護機制做的不夠好！

640

系統崩了之後，各大使用者瘋狂的上 Twitter 進行吐槽。並且 Facebook 自己也在 Twitter 上釋出訊息承認了此次服務中斷，該公司稱：“我們知道，目前有些人在訪問 Facebook 旗下各個應用程式時遇到了困難。我們正在努力盡快解決這個問題。“

並且 Facebook 證實，這個問題不是 DDoS 攻擊帶來的結果。DDoS 攻擊即“分散式拒絕服務攻擊”，是指黑客通過向一個站點輸送大量虛假流量來發動攻擊。

640

有網站統計了 Facebook 的問題的報告，多達 1.1 萬多份。使用者報告的問題，呈現各種各樣的，從根本無法載入網站到無法釋出評論等。

也有廣告主吐槽，準備好的廣告，也無法展現。廣告主工具同樣也遭遇了故障，有些廣告主們試圖投放“黑色星期五”（Black Friday）和“網路星期一”（Cyber Monday）廣告。但是，這些廣告都不能進行展現和營銷了。

為此，有人預估了，Facebook 的這次故障，損失至少上億美金。

參考其他網際網路的故障損失，谷歌 2013 年故障 5 分鐘損失 55 萬美元，並且全球流量下跌！另外 2018 年 Prime Day 故障讓亞馬遜損失 $9900 萬。2015 年 App Store 等服務故障導致蘋果損失 2640 萬美元。

微服務轉型，雪崩效應是繞不過的一道坎。Hystrix 的隔離和熔斷，執行緒池隔離和訊號量隔離建議大家多學習學習！Facebook 這是多麼疼的代價。

執行緒隔離技術，也稱是執行緒池隔離技術。最著名的使用者算 Hystrix 了。Hystrix 提供了兩種隔離策略，分散式：執行緒隔離和訊號量隔離。Hystrix 預設的隔離技術就是執行緒池隔離，因為隔離技術有一個除網路超時以外的額外保護層。

THREAD（執行緒隔離）：使用該方式，HystrixCommand將會在單獨的執行緒上執行，併發請求受執行緒池中執行緒數量的限制。
SEMAPHORE（訊號量隔離）：使用該方式，HystrixCommand將會在呼叫執行緒上執行，開銷相對較小，併發請求受訊號量的個數的限制。

之所以，訊號量隔離 SEMAPHORE 不是 Hystrix 的首選（預設隔離）的原因是，訊號量隔離一般僅適用於非網路呼叫的隔離。比如，操作記憶體等。而對於跨網路的，呼叫負載非常高的（例如每個例項每秒呼叫數百次）才需要使用訊號量隔離，因為這種場景下使用 THREAD 開銷會比較高。

所謂的執行緒隔離主要有執行緒池隔離，在實際使用時我們會把請求分類，然後交給不同的執行緒池處理，當一種業務的請求處理髮生問題時，不會將故障擴散到其他執行緒池，從而保證其他服務可用。

打個比方，在我們的電商系統中，假設現在有 3 個業務呼叫分別是查詢訂單、查詢商品、查詢使用者，且這三個業務請求都是依賴第三方服務-訂單服務、商品服務、使用者服務。三個服務都需要跨網路請求呼叫，可以是 RPC 呼叫，也可以是 Rest 的 HTTP 呼叫。當查詢訂單服務出現故障時，假如執行緒阻塞了，這個時候後續有大量的查詢訂單請求過來，那麼容器中的執行緒數量則會持續增加直致 CPU 資源耗盡到 100%，整個服務對外不可用，叢集環境下就是雪崩。

640