什麼是 Hystrix？
在分布式環境中，許多服務之間相關互相依賴，在這種複雜環境中總不可避免地會失敗。Hystrix 就是解決這類問題的一個容錯治理架構，它通過添加延遲容錯和容錯邏輯來幫助您控制在這種環境中分布式服務之間的互動。Hystrix 通過隔離服務之間的通路點、阻止它們之間的級聯故障并提供回退選項來實作這一點，所有這些都為了提高系統的整體彈性。
Hystrix 的曆史
Hystrix 由 Netflix API 團隊于 2011 年開始的彈性工程工作演變而來。 2012 年，Hystrix 不斷發展和成熟，Netflix 内部的許多團隊都采用了它。如今，Netflix 每天通過 Hystrix 執行數百億個線程隔離和數千億個信号量隔離調用。保障了正常運作時間和彈性的顯着改善。
Hystrix 有什麼用？
Hystrix 旨在執行以下操作：
- 通過第三方用戶端庫通路的依賴項（通常通過網絡）提供延遲和故障的保護和控制。
- 停止複雜分布式系統中的級聯故障。
- 快速失敗并快速恢複。
- 在可能的情況下回退并優雅地降級。
- 實作近乎實時的監控、警報和操作控制。
Hystrix 解決了什麼問題？
複雜分布式架構中的應用程式通常有成千上萬個依賴項，每個依賴項可能會在某個時刻不可避免地失敗。如果主機應用程式沒有與這些外部故障隔離開來，它就有可能被它們拖垮。
例如，對于依賴 30 個服務的應用程式，其中每個服務的正常運作時間為 99.99%，您可以期待以下内容：
99.99 30 = 99.7% 的正常運作時間
10 億次請求的 0.3% = 3,000,000 次故障
每月停機時間超過 2小時，即使所有依賴項都具有出色的正常運作時間。
但現實情況通常更糟。即使所有依賴項都表現良好，如果您不設計整個系統以實作彈性，即使是 0.01% 的停機時間對數十個服務中的每一個的總體影響也等同于每月潛在的幾個小時停機時間。
當一切正常時，請求流可能如下所示：
（圖一）
當後端系統中從多依賴服務中某個依賴項目不穩定（産生故障）時，它可以阻止整個使用者請求：
（圖二）
在面對大量流量沖擊情景中，某個後端微服務的依賴變得不穩定時可能導緻其所在伺服器上的所有資源在短短數秒鐘内變得飽和。
應用程式中通過網絡或用戶端庫通路可能導緻網絡請求的每個點都是潛在故障的來源。比故障更糟糕的是，這些應用程式還可能導緻服務之間的延遲增加，耗盡級聯系統中所有相關隊列、線程和其他系統資源，進而導緻整個系統出現大崩潰故障。
（圖四）
當通過第三方用戶端執行網絡通路時，這些問題會更加嚴重——一個“黑匣子”，其中隐藏了實作細節并且可以随時更改，每個用戶端庫的網絡或資源配置都不同，通常難以監控和改變。更糟糕的是傳遞依賴，它們執行潛在的昂貴或容易出錯的網絡調用，而沒有被應用程式顯式調用。網絡連接配接失敗或降級，服務和伺服器出現故障或變慢；所有這些都代表需要隔離和管理的故障和延遲，以便單個失敗的依賴項無法關閉整個應用程式或系統。
Hystrix 背後的設計原則是什麼？
設計目标是什麼？
- 防止任何單個依賴項耗盡所有容器（例如 Tomcat）使用者線程。
- 減輕負載和快速失敗而不是排隊。
- 在可行的情況下提供回退以保護使用者免于失敗。
- 使用隔離技術（例如隔闆、泳道和斷路器模式）來限制任何一種依賴性的影響。
- 通過近乎實時的名額、監控和警報優化發現時間
- 通過配置更改的低延遲傳播和支援 Hystrix 大部分方面的動态屬性更改來優化恢複時間，這允許您使用低延遲回報循環進行實時操作修改。
- 防止整個依賴用戶端執行中的故障，而不僅僅是網絡流量。
Hystrix 如何實作其目标？
Hystrix 通過以下方式執行此操作：
- 将所有對外部系統（或“依賴項”）的調用包裝在一個
HystrixCommand或
HystrixObservableCommand
- 逾時調用時間超過您定義的門檻值。有一個預設值，但對于大多數依賴項，您可以通過“屬性”自定義設定這些逾時，以便它們略高于每個依賴項的測量的 99.5 th百分位性能。
- 為每個依賴項維護一個小的線程池（或信号量）；如果它已滿，則發往該依賴項的請求将立即被拒絕，而不是排隊。
- 計算統計一定時間視窗内成功、失敗（用戶端抛出的異常）、逾時和線程拒絕的資料。
- 如果服務的錯誤百分比超過門檻值，則手動或自動觸發斷路器以在一段時間内停止對特定服務的所有請求。
- 當請求失敗、被拒絕、逾時或短路時執行回退邏輯。
- 近乎實時地監控名額和配置更改。
（圖五）
斷路器的開關控制邏輯如下：
- 在一個統計時間視窗（HYST rixCommandProperties.metricsRollingStatisticalWindowInMilliseconds()）内，處理的請求數達到設定的最小門檻值（HYST）rixCommandProperties.circuitBreakerRequestVolumeThreshold（）），錯誤百分比超過設定的最大門檻值（HYST）rixCommandProperties.circuitBreakerThreshold（） ) )此時斷路器分閘，斷路器狀态由合閘切換為分閘。
- 當斷路器斷開時，它将直接融合所有請求（快速失敗）并經過回退邏輯。
- 經過一個休眠視窗時間（HYST rixCommandProperties.circuitBreakerSleepWindowInMilliseconds()），Hystrix會釋放一個進行後續服務并将斷路器開關切換到半開（half OPEN）。如果請求失敗，斷路器将熔斷開關切換到OPEN狀态，繼續熔斷所有請求，直到下一個休眠時間視窗到來；如果請求成功，斷路器将切換到 CLOSED 狀态，此時允許所有請求通過，直到發生一步，斷路器開關才會切換到 OPEN 狀态。
Hystrix 簡介-spring cloud 入門教程 （圖六）
當您使用 Hystrix 包裝每個底層依賴項時，如圖四所示的架構将更改為類似于下圖。每個依賴項間彼此隔離，限制在發生延遲時，降低資源飽和度，并覆寫在回退邏輯中，該邏輯決定在依賴項中發生任何類型的故障時做出什麼響應：
（圖七）
使用 Zuul、Ribbon、Feign、Eureka 和 Sleuth、Zipkin 建立簡單spring cloud微服務用例-spring cloud 入門教程
微服務內建SPRING CLOUD SLEUTH、ELK 和 ZIPKIN 進行監控-spring cloud 入門教程
使用Hystrix 、Feign 和 Ribbon建構微服務-spring cloud 入門教程
使用 Spring Boot Admin 監控微服務-spring cloud 入門教程
基于Redis做Spring Cloud Gateway 中的速率限制實踐-spring cloud 入門教程
內建SWAGGER2服務-spring cloud 入門教程
Hystrix 簡介-spring cloud 入門教程
Hystrix 原理深入分析-spring cloud 入門教程
使用Apache Camel建構微服務-spring cloud 入門教程
內建 Kubernetes 來建構微服務-spring cloud 入門教程
內建SPRINGDOC OPENAPI 的微服務實踐-spring cloud 入門教程
SPRING CLOUD 微服務快速指南-spring cloud 入門教程
基于GraphQL的微服務實踐-spring cloud 入門教程
最火的Spring Cloud Gateway 為經過身份驗證的使用者啟用速率限制實踐-spring cloud 入門教程