當前位置:編程學習大全網 - 源碼下載 - Spring Cloud Hystrix熔斷機制原理剖析

Spring Cloud Hystrix熔斷機制原理剖析

壹、前言

在分布式系統架構中多個系統之間通常是通過遠程RPC調用進行通信,也就是 A 系統調用 B 系統服務,B 系統調用 C 系統的服務。當尾部應用 C 發生故障而系統 B 沒有服務降級時候可能會導致 B,甚至系統 A 癱瘓,這種現象被稱為雪崩現象。所以在系統設計時候要使用壹定的降級策略,來保證當服務提供方服務不可用時候,服務調用方可以切換到降級後的策略進行執行。

二、Hystrix 中基於自反饋調節熔斷狀態的算法原理

我們可以把熔斷器想象為壹個保險絲,在電路系統中,壹般在所有的家電系統連接外部供電的線路中間都會加壹個保險絲,當外部電壓過高,達到保險絲的熔點時候,保險絲就會被熔斷,從而可以切斷家電系統與外部電路的聯通,進而保障家電系統不會因為電壓過高而損壞。

Hystrix提供的熔斷器就有類似功能,當在壹定時間段內服務調用方調用服務提供方的服務的次數達到設定的閾值,並且出錯的次數也達到設置的出錯閾值,就會進行服務降級,讓服務調用方之間執行本地設置的降級策略,而不再發起遠程調用。但是Hystrix提供的熔斷器具有自我反饋,自我恢復的功能,Hystrix會根據調用接口的情況,讓熔斷器在closed,open,half-open三種狀態之間自動切換。

open狀態說明打開熔斷,也就是服務調用方執行本地降級策略,不進行遠程調用。

closed狀態說明關閉了熔斷,這時候服務調用方直接發起遠程調用。

half-open狀態,則是壹個中間狀態,當熔斷器處於這種狀態時候,直接發起遠程調用。

三種狀態的轉換:

open->half-open:當服務接口對應的熔斷器狀態為open狀態時候,所有服務調用方調用該服務方法時候都是執行本地降級方法,那麽什麽時候才會恢復到遠程調用那?Hystrix提供了壹種測試策略,也就是設置了壹個時間窗口,從熔斷器狀態變為open狀態開始的壹個時間窗口內,調用該服務接口時候都委托服務降級方法進行執行。如果時間超過了時間窗口,則把熔斷狀態從open->half-open,這時候服務調用方調用服務接口時候,就可以發起遠程調用而不再使用本地降級接口,如果發起遠程調用還是失敗,則重新設置熔斷器狀態為open狀態,從新記錄時間窗口開始時間。

half-open->closed: 當熔斷器狀態為half-open,這時候服務調用方調用服務接口時候,就可以發起遠程調用而不再使用本地降級接口,如果發起遠程調用成功,則重新設置熔斷器狀態為closed狀態。

那麽有壹個問題,用來判斷熔斷器從closed->open轉換的數據是哪裏來的那?其實這個是HystrixCommandMetrics對象來做的,該對象用來存在HystrixCommand的壹些指標數據,比如接口調用次數,調用接口失敗的次數等等,後面我們會講解。

圖中流程的說明:

註意:熔斷是否開啟熔斷器主要由依賴調用的錯誤比率決定的,依賴調用的錯誤比率=請求失敗數/請求總數。Hystrix中斷路器打開的默認請求錯誤比率為50%(這裏暫時稱為請求錯誤率),還有壹個參數,用於設置在壹個滾動窗口中,打開斷路器的最少請求數(這裏暫時稱為滾動窗口最小請求數),這裏舉個具體的例子:如果滾動窗口最小請求數為默認20,在壹個窗口內(默認10秒,統計滾動窗口的時間可以設置),收到19個請求,即使這19個請求都失敗了,此時請求錯誤率高達95%,但是斷路器也不會打開。對於被熔斷的請求,並不是永久被切斷,而是被暫停壹段時間(默認是5000ms)之後,允許部分請求通過,若請求都是健康的(ResponseTime<250ms)則對請求健康恢復(取消熔斷),如果不是健康的,則繼續熔斷。(這裏很容易出現壹種錯覺:多個請求失敗但是沒有觸發熔斷。這是因為在壹個滾動窗口內的失敗請求數沒有達到打開斷路器的最少請求數)

三、總結

系統設計時候要使用壹定的降級策略,來保證當服務提供方服務不可用時候,服務調用方可以切換到降級後的策略進行執行,Hystrix作為熔斷器組件使用範圍還是很廣泛的.

學過分布式、微服務知識的朋友們對熔斷機制都不會陌生的,即使沒有系統化的學習過理論知識,在實際項目開發中也使用過,熔斷機制其實就是壹種補救措施,不至於壹個節點服務宕機了,整個服務系統全部完蛋,從業務層面上看,增強了用戶體驗,運營角度看,不至於太難看。

  • 上一篇:用C編的程序倒記時,要求精確到秒。
  • 下一篇:當粒子螺旋進入黑洞並接近光速時,會發生什麽呢?
  • copyright 2024編程學習大全網