一：什么是Hystrix?

在分布式環境中，許多服務依賴項中的一些將不可避免地失敗。Hystrix是一個庫，通過添加延遲容差和容錯邏輯來幫助您控制這些分布式服務之間的交互。Hystrix通過隔離服務之間的訪問點，停止其間的級聯故障以及提供回退選項，從而提高系統的整體彈性。

Hystrix旨在執行以下操作

1：對通過第三方客戶端庫訪問（通常通過網絡）的依賴關系提供保護并控制延遲和故障。

2：隔離復雜分布式系統中的級聯故障。

3：快速發現故障，盡快恢復。

4：回退，盡可能優雅地降級。

5：啟用近實時監控，警報和操作控制。

二：為什么需要Hystrix?

分布式系統所面臨的分體：大型分布式系統中，一個客戶端或者服務依賴外部服務，如果一個服務宕了，那么由于我們設置了服務調用系統超時時間，勢必會影響相應時間，在高并發的情況下大多數服務器的線程池就出現阻塞(BLOCK),影響整個線上服務的穩定性。嚴重會產生服務雪崩

服務雪崩效應:

? ? ? ? ?多個微服務之間調用的時候，假設微服務A服務調用微服務B服務和C服務，微服務B和微服務C又調用其他微服務，這就是所謂的 "扇出" 。如果扇出的鏈路上某個微服務的調用響應時間過長或者不可用，對微服務A的調用就會占用越來越多的的系統資源，進而引起系統資源崩潰，這就是所謂的雪崩效應。

(圖片官方圖片)

當一切都健康時，請求可以看起來像這樣

?

下圖A? ?P? ?H? ? I? 四個服務，如果I服務超時會出現什么情況呢？

當許多后端服務系統中的一個宕掉時或者響應超時，整個用戶請求：

如果多個客戶端調用同一個異常服務的時候，出現的情況是：

?

?

?

?

?

三：Hystrix解決什么問題？

分布式架構中的應用程序具有幾十個依賴關系，每個依賴關系在某個時刻將不可避免的出現異常。如果應用程序不與這些外部故障隔離，則可能出現線程池阻塞，引起系統雪崩。

例如，對于依賴30個服務的應用程序，每個服務的正常運行時間為99.99％，您可以：

99.99%的30次方 = 99.7％正常運行時間

0.3％的10億次請求= 3,000,000次故障

2+小時宕機/月，即使所有依賴關系正常運行時間。

當使用Hystrix進行熔斷后，每個依賴關系彼此隔離了，限制了當發生延遲時的阻塞。

?

四：Hystrix能干嘛

　1.請求熔斷： 當Hystrix Command請求后端服務失敗數量超過一定比例(默認50%), 斷路器會切換到開路狀態(Open). 這時所有請求會直接失敗而不會發送到后端服務. 斷路器保持在開路狀態一段時間后(默認5秒), 自動切換到半開路狀態(HALF-OPEN).這時會判斷下一次請求的返回情況, 如果請求成功, 斷路器切回閉路狀態(CLOSED), 否則重新切換到開路狀態(OPEN). Hystrix的斷路器就像我們家庭電路中的保險絲, 一旦后端服務不可用, 斷路器會直接切斷請求鏈, 避免發送大量無效請求影響系統吞吐量, 并且斷路器有自我檢測并恢復的能力.2.服務降級：Fallback相當于是降級操作. 對于查詢操作, 我們可以實現一個fallback方法, 當請求后端服務出現異常的時候, 可以使用fallback方法返回的值. fallback方法的返回值一般是設置的默認值或者來自緩存.告知后面的請求服務不可用了，不要再來了。3.依賴隔離(采用艙壁模式，Docker就是艙壁模式的一種)：在Hystrix中, 主要通過線程池來實現資源隔離. 通常在使用的時候我們會根據調用的遠程服務劃分出多個線程池.比如說，一個服務調用兩外兩個服務，你如果調用兩個服務都用一個線程池，那么如果一個服務卡在哪里，資源沒被釋放后面的請求又來了，導致后面的請求都卡在哪里等待，導致你依賴的A服務把你卡在哪里，耗盡了資源，也導致了你另外一個B服務也不可用了。這時如果依賴隔離，某一個服務調用A B兩個服務，如果這時我有100個線程可用，我給A服務分配50個，給B服務分配50個，這樣就算A服務掛了，我的B服務依然可以用。4.請求緩存：比如一個請求過來請求我userId=1的數據，你后面的請求也過來請求同樣的數據，這時我不會繼續走原來的那條請求鏈路了，而是把第一次請求緩存過了，把第一次的請求結果返回給后面的請求。5.請求合并：我依賴于某一個服務，我要調用N次，比如說查數據庫的時候，我發了N條請求發了N條SQL然后拿到一堆結果，這時候我們可以把多個請求合并成一個請求，發送一個查詢多條數據的SQL的請求，這樣我們只需查詢一次數據庫，提升了效率。

?

總結

以上是生活随笔為你收集整理的springcloud hystrix概述（一）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。