什麼是Hystrix？
在分佈式環境中，不可避免地會有許多服務依賴項失敗。Hystrix是一個庫，通過添加延遲容忍和容錯邏輯，幫助您控制這些分佈式服務之間的交互。Hystrix通過隔離服務之間的訪問點、停止跨服務的級聯故障並提供回退選項來實現這一點，所有這些都可以提高系統的總體彈性。
Hystrix的歷史
Hystrix是從Netflix API團隊2011年開始的彈性工程工作中發展而來的。2012年，Hystrix繼續發展和成熟，Netflix的許多團隊都採用了它。如今，Netflix每天通過Hystrix執行數百億個線程隔離調用和數千億個信號量隔離調用。這在正常運行時間和恢復力方面帶來了顯著的改善。
Hystrix是幹什麼用的?
Hystrix被設計用來做如下事宜：
- 保護和控制通過第三方客戶端庫訪問的依賴(通常是通過網絡)的延遲和失敗。
- 停止複雜分佈式系統中的級聯故障。
- 快速熔斷和迅速恢復
- 回退並儘可能優雅地降級。
- 啓用近實時監視、警報和操作控制。
Hystrix解決了什麼問題?
複雜分佈式體系結構中的應用程序有許多依賴項，每個依賴項都不可避免地會在某個時候失敗。如果主機應用程序不能與這些外部故障隔離，則有可能隨這些故障一起停機。
例如，對於一個依賴於30個服務的應用程序，其中每個服務有99.99%的正常運行時間，以下是您可以預期的情況:
99.9930 = 99.7%正常運行時間
10億請求中的0.3% = 300萬次失敗
2+小時停機/月，即使所有依賴有優秀的正常運行時間。
現實通常更糟。
即使在所有依賴項都表現良好的情況下，如果您不爲彈性設計整個系統，那麼即使0.01%的停機時間對幾十個服務中的每一個服務的總體影響也相當於每月潛在的停機時間數小時。
當一切正常時，請求流可以是這樣的:
當許多後端系統之一成爲潛在的，它可以阻止整個用戶的請求:
在高流量的情況下，單個後端依賴項的潛在影響可能會導致所有服務器上的所有資源在幾秒鐘內飽和。
應用程序中通過網絡或進入客戶端庫可能導致網絡請求的每一點都是潛在故障的根源。比故障更糟糕的是，這些應用程序還會導致服務之間的延遲增加，從而備份隊列、線程和其他系統資源，從而在整個系統中導致更多的級聯故障。
當通過第三方客戶端執行網絡訪問時，這些問題會更加嚴重——這是一個“黑盒”，其中隱藏了實現細節，可以在任何時候更改，並且每個客戶端庫的網絡或資源配置不同，通常很難監控和更改。
更糟糕的是，傳遞依賴項在不被應用程序顯式調用的情況下執行潛在的昂貴或容易出錯的網絡調用。
網絡連接失敗或降級。服務和服務器失敗或變慢。新的庫或服務部署會改變行爲或性能特徵。客戶端庫有bug。
所有這些都表示需要隔離和管理的失敗和延遲，這樣單個失敗依賴項就不能破壞整個應用程序或系統。
Hystrix的設計原則是什麼?
- 防止任何單個依賴項耗盡所有容器(如Tomcat)用戶線程。
- 減少負載和快速失敗，而不是排隊。
- 在可行的情況下提供回退，以保護用戶避免失敗。
- 使用隔離技術(如艙壁、泳道和斷路器模式)來限制任何依賴項的影響。
- 通過接近實時的度量、監視和警報優化發現時間
- 通過配置更改的低延遲傳播和對Hystrix大多數方面的動態屬性更改的支持來優化恢復時間，這允許您使用低延遲反饋循環進行實時操作修改。
- 保護整個依賴客戶端執行中的失敗，而不僅僅是在網絡流量中。
Hystrix是如何實現其目標的?
- 將對外部系統(或“依賴項”)的所有調用包裝在HystrixCommand或HystrixObservableCommand對象中，該對象通常在單獨的線程中執行(這是命令模式的一個示例)。
- 超時調用的時間長於您定義的閾值。有一個默認值，但是對於大多數依賴項，您可以通過“屬性”自定義設置這些超時，以便它們比每個依賴項的99.5%的性能略高。
- 爲每個依賴項維護一個小的線程池(或信號量);如果它已經滿了，針對該依賴項的請求將立即被拒絕，而不是排隊。
- 度量成功、失敗(客戶端拋出的異常)、超時和線程拒絕。
- 斷開斷路器，以在一段時間內停止對特定服務的所有請求，如果服務的錯誤百分比超過閾值，則手動或自動停止。
- 在請求失敗、被拒絕、超時或短路時執行回退邏輯。
- 幾乎實時地監視度量和配置更改。
當您使用Hystrix包裝每個底層依賴項時，上面圖表中所示的體系結構將發生變化，類似於下面的圖表。每個依賴項都是相互隔離的，當延遲發生時，依賴項所佔用的資源受到限制，並且在決定當依賴項中發生任何類型的故障時應作出何種響應的回退邏輯中進行了介紹:
