在微服務架構中,我們將系統拆分成了一個個的服務單元,各單元應用間通過服務注冊與發現的方式互相依賴。
由於每個單元都在不同的進程中運行,依賴通過遠程調用的方式執行,這樣就有可能因為網絡原因或是依賴服務自身問題出現調用故障或延遲,
而這些問題會直接導致調用方的對外服務也出現延遲,若此時調用方的請求不斷增加,最后就會出現因等待出現故障的依賴方響應而形成任務積壓,線程資源無法釋放,最終導致自身服務的癱瘓,
進一步甚至出現故障的蔓延最終導致整個系統的癱瘓。如果這樣的架構存在如此嚴重的隱患,那么相較傳統架構就更加的不穩定。
為了解決這樣的問題,因此產生了斷路器等一系列的服務保護機制。
為了使得故障隔離,Hystrix提供的解決方案我們需要關注一下幾個部分:
- 艙壁隔離(線程隔離)
- 超時控制
- 服務降級
- 熔斷機制
1.倉壁隔離
“艙壁模式”對於熟悉Docker的讀者一定不陌生,Docker通過“艙壁模式”實現進程的隔離,使得容器與容器之間不會互相影響。
而Hystrix則使用該模式實現線程池的隔離,它會為每一個Hystrix命令創建一個獨立的線程池,這樣就算某個在Hystrix命令包裝下的依賴服務出現延遲過高的情況,也只是對該依賴服務的調用產生影響,而不會拖慢其他的服務。
如何使用?
我們使用@HystrixCommand來將某個函數包裝成了Hystrix命令,Hystrix框架就會自動的為這個函數實現調用的隔離。
Spring Cloud構建微服務架構:服務容錯保護(Hystrix依賴隔離)
2.超時控制和服務降級
如果服務提供方延遲了自己設置的超時限制,而服務消費方觸發了服務請求超時異常,服務消費者就通過HystrixCommand注解中指定的降級邏輯進行執行,
因此該請求的結果返回了fallback。這樣的機制,對自身服務起到了基礎的保護,同時還為異常情況提供了自動的服務降級切換機制。
3.熔斷機制
“斷路器”本身是一種開關裝置,用於在電路上保護線路過載,當線路中有電器發生短路時,“斷路器”能夠及時的切斷故障電路,防止發生過載、發熱、甚至起火等嚴重后果。
在分布式架構中,斷路器模式的作用也是類似的,當某個服務單元發生故障(類似用電器發生短路)之后,通過斷路器的故障監控(類似熔斷保險絲),直接切斷原來的主邏輯調用。
那么當斷路器打開之后會發生什么呢?我們先來說說斷路器未打開之前,對於之前那個示例的情況就是每個請求都會在當hystrix超時之后返回fallback,每個請求時間延遲就是近似hystrix的超時時間,
如果設置為5秒,那么每個請求就都要延遲5秒才會返回。當熔斷器在10秒內發現請求總數超過20,並且錯誤百分比超過50%,這個時候熔斷器打開。
打開之后,再有請求調用的時候,將不會調用主邏輯,而是直接調用降級邏輯,這個時候就不會等待5秒之后才返回fallback。
通過斷路器,實現了自動地發現錯誤並將降級邏輯切換為主邏輯,減少響應延遲的效果。
附上一張終極原理圖:

Spring Cloud構建微服務架構:服務容錯保護(Hystrix斷路器)
注:一些配置
要使用hystrix需要在pom文件中添加下面兩個依賴:
服務消費者application.properties
這是做的全局默認配置,如果在某個服務級別上單獨配置,使用@DefaultProperties在類級別上做配置:
另外后還需要加注解@HystrixCommand做方法級別的命令控制,默認使用類級別的參數。
