前面幾篇我們介紹了Eureka服務註冊中心、Ribbon客戶端負載均衡以及Feign聲明式REST服務調用組件，還有它們常見的配置以及問題的解決。
下面我們來逐步學習Spring Cloud的斷路器Hystrix，本篇我們先來了解一下超時機制以及斷路器相關的介紹。
一、目前的架構存在的問題
我們之前搭建了服務提供者microserver-provider-user微服務，以及服務消費者microserver-consumer-movie微服務，並且都將相關服務註冊到Eureka Server註冊中心中，各個微服務也使用了Ribbon進行了客戶端負載均衡，使用了Feign進行聲明式REST服務調用，所以截止到目前，我們搭建的Demo的結構如下模式：
在上面的架構下，在某些場景下，可能會有一些問題出現，例如服務提供響應非常緩慢，那麼消費者對提供者的請求就會被強制等待，直到服務返回。在高負載場景下，如果不做任何處理，這種問題很可能造成所有用戶請求的線程都被耗竭，而不能響應用戶的進一步請求。
嚴重一些的，會引起所謂的“雪崩效應”。
二、雪崩效應
在微服務架構中通常會有多少個服務層調用，大量的微服務通過網絡進行通信，從而支撐起整個系統。各個微服務之間也難免存在大量的依賴關係。然而任何服務都不是100%可用的，網絡也往往是脆弱的，所以避免有些請求會失敗。基礎服務的故障導致級聯故障，進而造成了整個系統的不可用，這種現象被稱爲雪崩式效應。服務雪崩效應描述的是一種因服務提供者的不可用導致服務消費者的不可用，並將不可用逐漸放大的過程。
A作爲服務提供者，B爲A的服務消費者，C和D是B的服務消費者。A不可用引起了B的不可用，並將不可用像雪球一樣放大到C和D時，雪崩效應就形成了。
三、解決方案
1.超時機制
通過網絡請求其他服務器時，都必須設置超時。正常情況下，一個遠程調用一般在幾十毫秒內就返回了。當依賴的服務不可用，或者因爲網絡問題，響應時間將會變得很長（幾十秒）。而通常情況下，一次遠程調用對應了一個線程/進程，如果響應太慢，那個線程/進程就會得不到釋放。而線程/進程都對應了系統資源，如果大量的線程/進程得不到釋放，並且越積越多，服務資源就會被耗盡，從而導致自身服務不可用。
所以必須爲每個請求設置超時時間，當請求超過超時時間後，就會自動放棄本次請求，並且反饋請求超時的結果，防止服務器長時間等待，無法釋放無效請求資源。
2.斷路器模式
試想一下，家庭裏如果沒有斷路器，電流過載了（例如功率過大、短路等），電路不斷開，電路就會升溫，甚至是燒斷電路、起火。有了斷路器之後，當電流過載時，會自動切斷電路（跳閘），從而保護了整條電路與家庭的安全。當電流過載的問題被解決後，只要關閉斷路器，電路又可以工作了。
同樣的道理，當依賴的服務有大量超時時，再讓新的請求去訪問已經沒有太大意義，只會無謂的消費現有資源。譬如我們設置了超時時間爲1秒，如果短時間內有大量的請求（譬如50個）在1秒內都得不到響應，就往往意味着異常。此時就沒有必要讓更多的請求去訪問這個依賴了，我們應該使用斷路器避免資源浪費。
斷路器可以實現快速失敗，如果它在一段時間內偵測到許多類似的錯誤（譬如超時），就會強迫其以後的多個調用快速失敗，不再請求所依賴的服務，從而防止應用程序不斷地嘗試執行可能會失敗的操作，這樣應用程序可以繼續執行而不用等待修正錯誤，或者浪費CPU時間去等待長時間的超時。斷路器也可以使應用程序能夠診斷錯誤是否已經修正，如果已經修正，應用程序會再次調用操作。
斷路器模式就像是那些容易導致錯誤的操作的一種代理，這種代理能夠記錄最近調用發生錯誤的次數，然後決定是允許操作繼續，還是立即返回錯誤。
一個斷路器大概有三種狀態：關閉、打開、半開狀態，如下圖所示：
正常情況下，斷路器是關閉的；當請求服務出現異常時，斷路器打開，請求該服務時，立即返回錯誤；當斷路器設置的時間窗結束，就會進行請求分流，一部分依然直接返回錯誤，一部分嘗試去重新請求服務，此時爲半開狀態，當檢測到服務的請求通過率正常時（低於開關閾值），就會將斷路器半開閉狀態修改爲關閉狀態；當檢測到服務的請求通過率依然不行，依然會將斷路器全部打開。
以上的解決方案都是理論操作，實現超時機制和斷路器模式都是很有挑戰和難度的。而在開發界中，Hystrix就是實現了超時機制和斷路器模式的服務組件。
Hystrix大致實現了以下功能：
(1)服務監控 總共多少次請求，假設請求失敗10%，斷路器打開
(2)斷路器的狀態
(3)分流
(4)自我修復（斷路器狀態的切換）
下一篇我們就正式來學習Hystrix斷路器組件。
參考：《51CTO學院Spring Cloud高級視頻》
轉載請註明出處：https://blog.csdn.net/acmman/article/details/100151511