1、什麼是 Hystrix?
在分佈式環境中，許多服務依賴項不可避免地將會失敗。Hystrix是一個通過添加延遲容忍和容錯邏輯來幫助您控制這些分佈式服務之間的交互的庫。Hystrix通過隔離服務之間的訪問點來實現這一點，停止跨級的級聯故障，並提供備用選項，所有這些都可以提高系統的整體彈性。
Hystrix 的歷史
Hystrix是由Netflix的API團隊在2011年開始的彈性工程工作演變而來的。2012年，Hystrix繼續發展和成熟，Netflix的許多團隊都採用了它。如今，在Netflix上，每天都有數百億的線程被隔離，以及數以千億計的信號隔離電話。這導致了正常運行時間和彈性的顯著改善。
下面的鏈接提供了關於Hystrix的更多上下文以及它試圖解決的挑戰：
- “Making Netflix API More Resilient”
- “Fault Tolerance in a High Volume, Distributed System”
- “Performance and Fault Tolerance for the Netflix API”
- “Application Resilience in a Service-oriented Architecture”
- “Application Resilience Engineering & Operations at Netflix”
2、Hystrix 設計目的
Hystrix的設計目的是：
- 通過第三方客戶端庫，對訪問（通常是通過網絡）的依賴項進行保護，並控制延遲和失敗。
- 在一個複雜的分佈式系統中停止級聯故障。
- 快速失敗，迅速恢復。
- 在可能的情況下，後退並優雅地降級。
- 啓用近實時監控、警報和操作控制。
3、Hystrix 解決的問題
在複雜的分佈式體系結構中，應用程序有幾十個依賴項，每一個都將不可避免地在某一時刻失敗。如果主機應用程序沒有從這些外部故障中分離出來，那麼它就有可能被它們佔用。
例如，對於一個依賴於30個服務的應用程序，每個服務都有99。99%的正常運行時間，這是您可以期望的：
99.99^30 = 99.7% uptime
10億個請求中的 0.3% = 3,000,000 次失敗
即使所有的依賴關係都有很好的正常運行時間，每個月也有 2+ 小時的downtime
現實通常是更糟。
即使所有的依賴關係都很好地執行，即使是在每幾十個服務中，即使是 0.01% 的停機時間，也會導致一個月的停機時間，如果你不設計整個系統來恢復彈性的話。
當一切都很健康時，請求流可以是這樣的：
當後面的一個依賴有問題時，就會阻塞用戶請求。
在高容量的流量中，一個後端依賴的潛在依賴會導致所有資源在所有服務器上的秒內變得飽和。
在應用程序中，通過網絡或可能導致網絡請求的客戶機庫中的每一點都是潛在故障的根源。比失敗更糟糕的是，這些應用程序還可能導致服務之間的延遲，從而支持隊列、線程和其他系統資源，從而導致系統中出現更多的級聯故障。
當通過第三方客戶端進行網絡訪問時，這些問題會變得更加嚴重——一個“黑盒”，其中的實現細節是隱藏的，並且可以隨時更改，並且每個客戶機庫的網絡或資源配置都是不同的，並且常常難以監控和更改。
更糟糕的是傳遞依賴關係，它們執行潛在的昂貴或容易出錯的網絡調用，而不需要被應用程序顯式地調用。
網絡連接失敗或降級。服務和服務器失敗或變得緩慢。新的庫或服務部署會改變行爲或性能特徵。客戶端庫有 bug 。
所有這些都代表了需要隔離和管理的失敗和延遲，這樣一來，一個失敗的依賴就不能拖垮整個應用程序或系統。
Hystrix的設計原則是什麼？
- 防止任何單個依賴項耗盡所有容器（如Tomcat）用戶線程。
- 甩掉負載和快速失敗而不是排隊。
- 在可行的情況下提供支持，以保護用戶不受故障的影響。
- 使用隔離技術（如艙壁、泳道和斷路器模式）來限制任何一個依賴項的影響。
- 通過接近實時的指標、監控和警報來優化發現時間
- 通過對配置更改的低延遲傳播和對Hystrix的大多數方面的動態屬性更改的支持來- - 優化時間恢復，這允許您使用低延遲反饋循環進行實時操作修改。
- 保護整個依賴客戶端執行的失敗，而不僅僅是在網絡流量中。
4、Hystrix是如何實現它的目標的？
Hystrix 通過:
- 將所有調用封裝到一個HystrixCommand或hystrix觀察者的對象中，通常在一個單獨的線程中執行（這是命令模式的一個例子）。
- 時間的調用比你定義的閾值要長。有一個默認值，但是對於大多數依賴項，您可以通過“屬性”來定製這些超時，這樣它們就會比每個依賴項的99.5%的性能稍微高一些。
- 維護每個依賴項的一個小線程池（或信號量）;如果它變得滿了，那麼就會立即拒絕請求這個依賴項的請求，而不是排隊。
- 測量成功、失敗（客戶端拋出的異常）、超時和線程拒絕。
- 在一段時間內，如果服務的錯誤百分比超過了一個閾值，就會觸發一個斷路器來停止對特定服務的所有請求，無論是手動的還是自動的。
- 當一個請求失敗時執行回退邏輯，被拒絕，超時，或短路。
- 監控指標和配置在接近實時的情況下發生變化。
當您使用 Hystrix 來包裝每個潛在的依賴項時，上面的圖表所示的體系結構將類似於下面的圖表。每一個依賴關係都是相互隔離的，在延遲發生時，它可以被限制在資源中，並且包含在回退邏輯中，該邏輯決定了在依賴項中出現任何類型的故障時要做出什麼響應：
原文地址：https://github.com/Netflix/Hystrix/wiki