SpringCloud 熔斷引數配置說明

2021-08-31 18:46:43 字數 3090 閱讀 6336

2023年06月26日 17:57:42

jack281706

hystrix是由netflix建立乙個類庫。

在微服務的分布式環境中,系統存在許多服務依賴。在高併發訪問下,這些依賴的穩定性與否對系統的影響非常大,但是依賴有很多不可控問題:如網路連線緩慢,資源繁忙,暫時不可用,服務離線等。 hystrix可以通過新增延遲容錯和容錯邏輯來幫助我們控制這些分布式服務之間的互動。 hystrix通過隔離服務之間的接入點,阻止它們之間的級聯故障,並提供備用選項,從而提高系統的整體彈性。

每次呼叫建立乙個新的hystrixcommand,把依賴呼叫封裝在run()方法中.

執行execute()/queue做同步或非同步呼叫.

是否開啟請求快取,如果開啟了,並且如果快取中對請求的響應可用,則此快取響應將立即以「observable」的形式返回。

判斷熔斷器(circuit-breaker)是否開啟,如果開啟跳到步驟8,進行降級策略,如果關閉進入步驟.

判斷執行緒池/佇列/訊號量是否跑滿,如果跑滿進入降級步驟8,否則繼續後續步驟.

呼叫hystrixcommand的run方法.執行依賴邏輯

依賴邏輯呼叫超時,進入步驟8.

判斷邏輯是否呼叫成功

返回成功呼叫結果

呼叫出錯,進入步驟8.

計算熔斷器狀態,所有的執行狀態(成功, 失敗, 拒絕,超時)上報給熔斷器,用於統計從而判斷熔斷器狀態.

getfallback()降級邏輯.

沒有實現getfallback的command將直接丟擲異常

fallback降級邏輯呼叫成功直接返回

降級邏輯呼叫失敗丟擲異常

返回執行成功結果

分布式微服務系統中有多依賴,在高併發訪問下,這些依賴的穩定性與否對系統的影響非常大,但是依賴有很多不可控問題:如網路連線緩慢,資源繁忙,暫時不可用,服務離線等。高併發情況下,某個依賴服務(如下面的vehicle service)失敗,其他依賴服務可用。

如果不對失敗依賴採取隔離措施,將會生產雪崩效應,最終可能導致當前應用服務就有被拖垮的風險。

解決以上問題的方案-斷路器:

斷路器(英文名稱:circuit-breaker,circuit breaker)是指能夠關合、承載和開斷正常迴路條件下的電流並能關合、在規定的時間內承載和開斷異常迴路條件下的電流的開關裝置。

下圖是家用配電箱

hystrix實現的斷路器模式,在分布式微服務系統中當對特定服務的呼叫達到一定閾值時(hystrix中預設為20秒,20秒),電路將開啟,不進行通話。在錯誤和開路的情況下,開發人員可以提供後備

還是回到剛才的底層依賴服務失敗的場景,在消費者一端多次呼叫依賴服務失敗,達到斷路器開啟的閾值,斷路器被開啟,對應 的fallback方法被執行,一段時間內將不會再向失敗的服務發起請求。

展開原始碼

展開原始碼

展開原始碼

@hystrixcommand(fallbackmethod ="stubmyservicefallback",

commandproperties =

)

hystrix.command.default.execution.isolation.thread.timeoutinmilliseconds 命令執行超時時間,預設1000ms

hystrix.command.default.execution.timeout.enabled 執行是否啟用超時,預設啟用true

hystrix.command.default.execution.isolation.thread.interruptontimeout 發生超時是是否中斷,預設true

hystrix.command.default.execution.isolation.semaphore.maxconcurrentrequests 最大併發請求數,預設10,該引數當使用executionisolationstrategy.semaphore策略時才有效。如果達到最大併發請求數,請求會被拒絕。理論上選擇semaphore size的原則和選擇thread size一致,但選用semaphore時每次執行的單元要比較小且執行速度快(ms級別),否則的話應該用thread。

semaphore應該佔整個容器(tomcat)的執行緒池的一小部分。

這些引數可以應用於hystrix的thread和semaphore策略

hystrix.command.default.requestcache.enabled 預設true,需要過載getcachekey(),返回null時不快取

hystrix.command.default.requestlog.enabled 記錄日誌到hystrixrequestlog,預設true

hystrix.collapser.default.maxrequestsinbatch 單次批處理的最大請求數,達到該數量觸發批處理,預設integer.max_value

hystrix.collapser.default.timerdelayinmilliseconds 觸發批處理的延遲,也可以為建立批處理的時間+該值,預設10

hystrix.collapser.default.requestcache.enabled 是否對hystrixcollapser.execute() and hystrixcollapser.queue()的cache,預設true

執行緒數預設值10適用於大部分情況(有時可以設定得更小),如果需要設定得更大,那有個基本得公式可以follow:

requests per second at peak when healthy × 99th percentile latency in seconds + some breathing room

每秒最大支撐的請求數 (99%平均響應時間 + 快取值)

比如:每秒能處理1000個請求,99%的請求響應時間是60ms,那麼公式是:

1000 (0.060+0.012)

基本得原則時保持執行緒池盡可能小,他主要是為了釋放壓力,防止資源被阻塞。

當一切都是正常的時候,執行緒池一般僅會有1到2個執行緒啟用來提供服務

/wiki/configuration

Spring Cloud(七)熔斷機制

服務熔斷也稱服務隔離或者過載保護。在微服務應用中,服務存在一定的依賴關係,形成一定的依賴鏈。如果某個目標服務呼叫慢或者有大量超時,造成服務不可用,間接導致其他的依賴服務不可用,最嚴重的可能會阻塞整條依賴鏈,最終導致業務系統崩潰 又稱雪崩效應 此時,對該服務的呼叫執行熔斷,對於後續請求,不再繼續呼叫該...

五 springcloud服務熔斷

服務提供方宕機或者請求太太超出自己承受範圍,則熔斷 註解實現 基於hystrix,訪問傳入負數則報錯,當10次有2次出錯則斷開,並保持一段時間逐漸恢復。熔斷 hystrixcommand fallbackmethod paymentinfo timeout handler commandproper...

SpringCloud配置熔斷 負載均衡

首先的是pom的依賴 eureka依賴 org.springframework.cloud groupid spring cloud starter netflix eureka client artifactid dependency feign依賴 org.springframework.clo...