微服務之Hystrix斷路器

2021-10-04 03:47:15 字數 4096 閱讀 2315

hystrix是乙個用於處理分布式系統的延遲和容錯的開源庫,在分布式系統裡,許多依賴不可避免的會呼叫失敗,比如超時、異常等,hystrix能夠保證在乙個依賴出問題的情況下,不會導致整體服務失敗,避免級聯故障,以提高分

布式系統的彈性。

「斷路器」本身是一種開關裝置,當某個服務單元發生故障之後,通過斷路器的故障監控(類似熔斷保險絲),向呼叫方返回乙個符合預期的、可處理的備選響應(fallback),而不是長時間的等待或者丟擲呼叫方無法處理的異常,這樣就保證了服務呼叫方的執行緒不會被長時間、不必要地占用,從而避免了故障在分布式系統中的蔓延,乃至雪崩。

典型的乙個案例就是服務血崩效應 我們來看一張圖:

來看下上圖, 我們聯想一下上圖, 如果發生這種情況, 也就是說所有發給微服務d的請求 都會被卡在微服務h那, 就會導致執行緒一直累計在這裡, 那麼其他的微服務(比如a,b,c…) 就沒有可用執行緒了, 導致整個伺服器崩潰,這就是服務血崩。

導致服務雪崩的情況我們來總結一下,再看看怎麼解決:

程式bug,資料不匹配,響應時間過長,服務不可用等等…

針對上面的問題,我們來看看有哪些解決方案 :

服務限流

超時監控

服務熔斷

服務降級

我們先來解釋一下降級,降級是當我們的某個微服務響應時間過長,或者不可用了,講白了也就是那個微服務呼叫不了了,我們不能吧錯誤資訊返回出來,或者讓他一直卡在那裡,所以要在準備乙個對應的策略(乙個方法)當發生這種問題的時候我們直接呼叫這個方法來快速返回這個請求,不讓他一直卡在那 。講了這麼多,我們來看看具體怎麼操作:

我們剛剛說了某個微服務呼叫不了了要做降級,也就是說,要在呼叫方做降級(不然那個微服務都down掉了再做降級也沒什麼意義了) 比如說我們 user 呼叫power 那麼就在user 做降級

先把hystrix的依賴加入:

org.springframework.cloud<

/groupid>

spring-cloud-starter-netflix-hystrix<

/artifactid>

<

/dependency>

啟動類加入註解@enablehystrix 或者@enablecircuitbreaker(他們之間是乙個繼承關係,2個註解所描述的內容是完全一樣的,可能看大家之前都是enable***(比如eureka)這裡專門再寫乙個enablehystrix方便大家記吧)

然後在我們的controller上面加入註解@hystrixcommand(fallbackmethod就是我們剛剛說的方法的名字)

("/feignpower.do"

)@hystrixcommand

(fallbackmethod =

"fallbackmethod"

)public object feignpower

(string name)

fallbackmethod:

這個r不重要,你看做乙個map就好了, 是我封裝的乙個返回值的類。

public object fallbackmethod

(string name)

然後啟動服務呼叫一下看看結果:

我們來測試一下超時:

我們改動一下power的** 讓他故意等待一回兒(模擬響應超時)

("/power.do"

)public object power

(string name)

throws exception

這裡我就把返回值內容改一下方便大家看:

可能有些同學有疑問, 我這裡什麼都沒乾, 就讓他休眠了一下 , 怎麼就知道我這裡超時了呢?

因為hystrix他有預設的超時監聽,當你這個請求預設超過了1秒鐘就會超時 當然,這個可以配置的,至於怎麼配置,待會兒我會把一些配置統一列出來

講了這麼多, 這個降級到底有什麼用呢?

第一, 他可以監聽你的請求有沒有超時,第二,報錯了他這裡直接截斷了沒有讓請求一直卡在這裡其實降級還有乙個好處, 就是當你的系統馬上迎來大量的併發(雙十一秒殺這種 或者**活動) 這時候如果發現系統馬上承載不了這麼大的併發時, 可以考慮先關閉一些不重要的微服務(在降級方法裡面返回乙個比較友好的資訊),把資源讓給主微服務,總結一下就是整體資源快不夠了,忍痛將某些服務先關掉,待渡過難關,再開啟回來。

講完降級,我們來講講熔斷,其實熔斷,就好像我們生活中的跳閘一樣, 比如說你的電路出故障了,為了防止出現大型事故 這裡直接切斷了你的電源以免意外繼續發生, 把這個概念放在我們程式上也是如此, 當乙個微服務呼叫多次出現問題時(預設是10秒內20次當然 這個也能配置),hystrix就會採取熔斷機制,不再繼續呼叫你的方法(會在預設5秒鐘內和電器短路一樣,5秒鐘後會試探性的先關閉熔斷機制,但是如果這時候再失敗一次那麼又會重新進行熔斷) 而是直接呼叫降級方法,這樣就一定程度上避免了服務雪崩的問題

這個東西光筆記不太好測試,只能你們自己去測試了

限流限流, 顧名思義, 就是限制你某個微服務的使用量(可用執行緒)

hystrix通過執行緒池的方式來管理你的微服務呼叫,他預設是乙個執行緒池(10大小) 管理你的所有微服務,你可以

給某個微服務開闢新的執行緒池:

("/feignorder.do"

)@hystrixcommand

(fallbackmethod =

"fallbackordermethod"

, threadpoolkey =

"order"

, threadpoolproperties =

)public object feignorder

(string name)

feign 預設是支援hystrix的, 但是在spring - cloud dalston 版本之後就預設關閉了, 因為不一定業務需求要用的到,

所以現在要使用首先得開啟他,在yml檔案加上如下配置:

feign

:hystrix

:enabled

:true

加上配置之後降級方法怎麼寫呢?

@feignclient

(value =

"server-power"

,fallback = powerservicefallback.

class

)public

inte***ce

powerserviceclient

在feign客戶端的註解上 有個屬性叫fallback 然後指向乙個類

powerservicefallback 類:

@componen

public

class

powerservicefallback

implements

powerserviceclient

}

這樣子,方法降級就寫好了

當然 可能你有這種需求, 需要拿到具體的錯誤資訊, 那麼可以這樣寫:

@component

public

class

powerserviceclientfallbackfactory

implements

fallbackfactory

};}}

客戶端指定乙個fallbackfactory就好了

@feignclient

(value =

"server-power"

,fallbackfactory = powerserviceclientfallbackfactory.

class

)public

inte***ce

powerserviceclient

這個message 就是拿到的錯誤資訊

至此, 就完成了feign與hystrix的整合

微服務斷路器Hystrix思考

1 超時機制 2 斷路器 hystrix,當你訪問數量超過一定時,進行報錯 它具體是如何做到的呢?hystrix有兩種形式進行熔斷策略的 執行緒池,訊號量 執行緒池,將請求的執行緒交給執行緒池,靠執行緒池的拒絕策略來控制 訊號量模式,semaphone,訊號量每次減一,當執行完,將訊號量釋放 隔離方...

Hystrix斷路器概述

hystrix官宣,停更進維即 1 被動修復bugs 2 不再接受合併請求 3 不再發布新版本 服務雪崩 1 服務降級 2 服務熔斷 3 接近實時的監控 即當客戶的請求發生問題後,不讓客戶端等待並立刻返回乙個友好提示,用fallback方法來實現這一點。通俗來說,加入有乙個請求發生問題了,要有乙個方...

斷路器 Hystrix 簡介

複雜分布式體系結構中的應用程式有數十個依賴關係,每個依賴關係在某些時候將不可避免的失敗。hystrix 是乙個用於處理分布式系統延遲和容錯的開元庫,在分布式系統裡,許多依賴不可避免的會呼叫失敗,比如超時 異常等。hystrix能夠保證在乙個依賴出問題的情況下,不會導致整體服務失敗,避免級聯故障,以提...