微服務容錯限流框架Hystrix
1、Hystrix是什麼?
2、Hystrix能做什麼?
3、Hystrix解決什麼問題?
4、Hystrix的設計原則是什麼?
5、Hystrix如何實現其目標?
1、Hystrix是什麼?
在分散式環境中,不可避免地會有許多服務依賴項中的某些失敗。 Hystrix是一個庫,可通過新增延遲公差和容錯邏輯來幫助您控制這些分散式服務之間的互動。 Hystrix通過隔離服務之間的訪問點,停止服務之間的級聯故障並提供後備選項來實現此目的,所有這些都可以提高系統的整體彈性。
Hystrix歷史
Hystrix源自Netflix API團隊於2011年開始的彈性工程工作。2012年,Hystrix不斷髮展和成熟,Netflix內部的許多團隊都採用了它。 如今,每天在Netflix上通過Hystrix執行數以千億計的執行緒隔離和數以千計的訊號隔離呼叫。 這大大提高了正常執行時間和彈性。
2、Hystrix能做什麼?
超時、隔離、限流、熔斷、降級,以及監控
Hystrix旨在執行以下操作:
- 提供保護並控制通過第三方客戶端庫(通常是通過網路)訪問的依賴項的延遲和失敗。
- 停止複雜的分散式系統中的級聯故障。
- 快速失敗並快速恢復。
- 回退並在可能的情況下正常降級。
- 啟用近乎實時的監視,警報和操作控制。
3、Hystrix解決什麼問題?
複雜分散式體系結構中的應用程式具有數十種依賴關係,每種依賴關係不可避免地會在某個時刻失敗。 如果主機應用程式未與這些外部故障隔離開來,則可能會被淘汰。
例如,對於依賴30個服務的應用程式,其中每個服務的正常執行時間為99.99%,您可以期望:
99.99^30 = 99.7%的正常執行時間
10億個請求中的0.3%= 3,000,000個失敗
即使所有依賴項都具有出色的正常執行時間,每月也會有2個小時以上的停機時間,現實通常更糟。
即使您沒有對整個系統進行永續性設計,即使所有依賴項都能很好地執行,即使當機0.01%,對數十種服務中的每一項的總體影響也等於一個月可能會有數小時的當機。
當一切正常時,請求流如下所示:
當許多後端系統之一變得潛在時,它可以阻止整個使用者請求:
隨著高流量,單個後端依賴關係變得潛在,這可能導致所有伺服器上的所有資源在幾秒鐘內變得飽和。
應用程式中可能會導致網路請求的,通過網路或客戶端庫延伸的每個點都是潛在故障的根源。 比故障更糟糕的是,這些應用程式還會導致服務之間的等待時間增加,從而備份佇列,執行緒和其他系統資源,從而導致整個系統出現更多級聯故障。
當通過第三方客戶端進行網路訪問時,這些問題會更加嚴重。“第三方”是一個隱藏了實施細節的“黑匣子”,可以隨時更改,並且每個客戶端庫的網路或資源配置都不相同,通常難以監控和更改。
更糟糕的是,傳遞依賴項會執行潛在的昂貴或易出錯的網路呼叫,而不會被應用程式明確呼叫。
網路連線失敗或降級。服務和伺服器出現故障或變慢。新的庫或服務部署會更改行為或效能特徵。客戶端庫有錯誤。
所有這些都代表需要隔離和管理的故障和延遲,以使單個故障依賴項無法關閉整個應用程式或系統。
#####/4、Hystrix的設計原則是什麼?
Hystrix的工作原理:
- 防止任何單個依賴項耗盡所有容器(例如Tomcat)使用者執行緒。
- 減少負載並快速失敗,而不是排隊。
- 在可行的情況下提供備用,以保護使用者免受故障的影響。
- 使用隔離技術(例如隔板,泳道和斷路器模式)來限制任何一種依賴關係的影響。
- 通過近實時指標,監視和警報優化發現時間
- 通過在Hystrix的大多數方面中以低延遲傳播配置更改來優化恢復時間,並支援動態屬性更改,這使您
- 可以通過低延遲反饋迴路進行實時操作修改。
- 防止整個依賴客戶端執行失敗,而不僅僅是在網路傳輸中失敗
5、Hystrix如何實現其目標?
Hystrix通過以下方式做到這一點:
- 將對外部系統(或“依賴關係”)的所有呼叫包裝在通常在單獨執行緒中執行的HystrixCommand或HystrixObservableCommand物件中(這是命令模式的示例)。
- 超時呼叫花費的時間超過您定義的閾值。有一個預設值,但是對於大多數依賴項,您可以通過“屬性”自定義設定這些超時,以使它們略高於針對每個依賴項測得的99.5%的效能。
- 為每個依賴項維護一個小的執行緒池(或訊號燈);如果已滿,發往該依賴項的請求將立即被拒絕,而不是排隊。
- 測量成功,失敗(客戶端丟擲的異常),超時和執行緒拒絕。
如果某個服務的錯誤百分比超過閾值,則使斷路器跳閘,以在一段時間內手動或自動停止所有對特定服務的請求。 - 當請求失敗,被拒絕,超時或短路時執行回退邏輯。
- 幾乎實時監控指標和配置更改。
- 當您使用Hystrix封裝每個基礎依賴項時,如上圖所示的體系結構將更改為類似於下圖。每個依賴項都是相互隔離的,受到延遲時發生飽和的資源的限制,並由後備邏輯覆蓋,該邏輯決定了在依賴項中發生任何型別的故障時做出什麼響應:
相關文章
- 微服務容錯限流Hystrix入門微服務
- 微服務熔斷限流Hystrix之Dashboard微服務
- 微服務熔斷限流Hystrix之流聚合微服務
- SpringCloud+Hystrix服務容錯SpringGCCloud
- Hystrix微服務容錯處理及回撥方法原始碼分析微服務原始碼
- Spring Cloud Hystrix 服務容錯保護SpringCloud
- Spring Cloud Hystrix:服務容錯保護SpringCloud
- Spring Boot整合Hystrix實現服務容錯Spring Boot
- net core 微服務 快速開發框架 Viper 限流微服務框架
- (十三)spring cloud微服務分散式雲架構-服務容錯保護(Hystrix斷路器)SpringCloud微服務分散式架構
- SpringCloud系列之服務容錯保護Netflix HystrixSpringGCCloud
- 《吃透微服務》 - 服務容錯之Sentinel微服務
- Spring Cloud Hystrix 容錯保護SpringCloud
- go-kit微服務:限流Go微服務
- 微服務架構之「 容錯隔離 」微服務架構
- 打不死的小強 .net core 微服務 快速開發框架 Viper 限流微服務框架
- SpringCloudAlibaba 微服務講解(四)Sentinel--服務容錯(二)SpringGCCloud微服務
- SpringCloudAlibaba 微服務講解(四)Sentinel--服務容錯(一)SpringGCCloud微服務
- SpringCloud Alibaba實戰(9:Hystrix容錯保護)SpringGCCloud
- SpringCloud構建微服務架構-Hystrix服務降級SpringGCCloud微服務架構
- 如何設計一個容錯的微服務架構微服務架構
- SpringCloud微服務(基於Eureka+Feign+Hystrix+Zuul)SpringGCCloud微服務Zuul
- 聊聊微服務:Hystrix熔斷機制和原理微服務
- SpringCloud微服務實戰——搭建企業級開發框架(十四):整合Sentinel高可用流量管理框架【限流】SpringGCCloud微服務框架
- Spring Cloud構建微服務架構-Hystrix服務降級SpringCloud微服務架構
- 微服務斷路器模式實現:Istio vs Hystrix微服務模式
- springcloud 微服務配置監控端點 hystrix.streamSpringGCCloud微服務
- 微服務架構 | 5.1 使用 Netflix Hystrix 斷路器微服務架構
- ④SpringCloud 實戰:引入Hystrix元件,分散式系統容錯SpringGCCloud元件分散式
- 微服務元件之限流器與熔斷器微服務元件
- 微服務可用性之隔離限流降級微服務
- 微服務框架-dubbo整合nacos框架微服務框架
- 淺析微服務框架微服務框架
- 一個優秀的分散式springboot/SpringCloudAPI限流框架,特別適合微服務架構分散式Spring BootGCCloudAPI框架微服務架構
- spring cloud微服務分散式雲架構--hystrix的使用SpringCloud微服務分散式架構
- 微服務SpringCloud之熔斷監控Hystrix Dashboard和Turbine微服務SpringGCCloud
- 在低容錯業務場景下落地微服務的實踐經驗微服務
- .Net Core微服務——Ocelot(3):超時、熔斷、限流微服務