Netflix | 【翻譯】Hystrix文件-首頁
Hystrix是什麼？
在分散式環境下，系統不可避免地會遇到依賴服務失效的問題，這些問題可能是依賴服務的高延遲，或者依賴服務丟擲異常。使用 Hystrix 增加延遲/失敗容忍邏輯，能幫助你解決這些服務之間互動的問題。Hystrix 能使你的系統在出現依賴服務失效的時候，通過隔離系統所依賴的服務，防止服務級聯失敗，同時提供失敗回退機制，更優雅地應對失效，並使你的系統能更快地從異常中恢復。
Hystrix 的歷史
Hystrix 專案由 Netflix API 組於 2011 年創立，創立之初主要用於應對系統快速恢復的需求。到了 2012 年，Hystrix 專案日益完善和成熟，Netflix 公司內部越來越多的組開始使用它。現在，數以百億計的通過執行緒進行依賴隔離和數以千億計的通過訊號量進行依賴隔離的跨系統請求通過 Hystrix 發出，也正因為此，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
Hystrix 能做什麼？
Hystrix 被設計用來：
- 在通過第三方客戶端訪問（通常是通過網路）依賴服務出現高延遲或者失敗時，為系統提供保護和控制
- 在分散式系統中防止級聯失敗
- 快速失敗（Fail fast）同時能快速恢復
- 提供失敗回退（Fallback）和優雅的服務降級機制
- 提供近實時的監控、報警和運維控制手段
Hystrix 能解決什麼問題？
應用在複雜的分散式結構中，可能會依賴許多其他的服務，並且這些服務都不可避免地有失效的可能。如果一個應用沒有與依賴服務的失效隔離開來，那麼它將有可能因為依賴服務的失效而失效。
例如，一個應用依賴了 30 個服務，並且每個服務能保證 99.99% 的可用率，下面是一些計算結果：
99.9930 = 99.7% 可用率
10億次請求×0.3% = 3,000,000次失效
即使所有依賴的服務都能達到 99.99% 的可用率，這個系統每個月還是會有大於兩小時的不可用時間
而現實更加殘酷，如果你沒有針對整個系統做快速恢復，即使所有依賴只有 0.01% 的不可用率，累積起來每個月給系統帶來的不可用時間也有數小時之多。
當所有依賴都正常，一個請求的拓撲結構如下所示：
當一個後端依賴服務有延遲，它會阻塞整個使用者請求：
在高QPS環境下，一個後端依賴服務的延遲，會導致伺服器上的資源都被阻塞。
應用中每一個網路請求或者間接通過客戶端庫發出的網路請求都是潛在的導致應用失效的原因。更嚴重的是，這些應用可能被其他服務依賴，由於每個服務都有諸如請求佇列，執行緒池，或者其他系統資源等，一旦某個服務失效或者延遲增高，會導致更嚴重的級聯失效。
如果這些網路請求通過第三方客戶端發出，問題會變得更加嚴重，因為這些第三方客戶端對於應用來說相當於『黑盒』——無法瞭解其實現細節，隨時可能發生變更，網路/資源配置隨客戶端的不同而不同，同時又難以監控和修改。同時，應用依賴鏈中的服務可能非常耗時，或者這些可能導致問題的網路請求根本沒有被我們的應用顯式地呼叫！
網路連線可能失敗或者降級、服務或者伺服器可能失效或者變慢、依賴的庫或者部署的服務可能發生行為變更或效能變更，亦或是依賴的服務本身有 bug。
以上種種，都會導致失效或高延遲，為了使我們的系統更加魯棒，不至於因為單個服務出現上述問題而失效，我們需要將這些問題進行隔離。
Hystrix 的設計原則
- 防止單個依賴耗盡容器（例如 Tomcat）內所有使用者執行緒
- 降低系統負載，對無法及時處理的請求快速失敗（fail fast）而不是排隊
- 提供失敗回退，以在必要時讓失效對使用者透明化
- 使用隔離機制（例如『艙壁』/『泳道』模式，熔斷器模式等）降低依賴服務對整個系統的影響
- 針對系統服務的度量、監控和報警，提供優化以滿足近實時性的要求
- 在 Hystrix 絕大部分需要動態調整配置並快速部署到所有應用方面，提供優化以滿足快速恢復的要求
- 能保護應用不受依賴服務的整個執行過程中失敗的影響，而不僅僅是網路請求
Hystrix 如何實現上述功能？
- 將所有請求外部系統（或者叫依賴服務）的邏輯封裝到
HystrixCommand或者HystrixObservableCommand物件中，這些邏輯將會在獨立的執行緒中被執行（利用了設計模式中的 Command模式） - 對那些耗時超過設定的閾值的請求，Hystrix 採取自動超時的策略。該策略預設對所有
Command都有效，當然，你也可以通過設定Command的配置以自定義超時時間，以使你的依賴服務在引入 Hystrix 之後能達到 99.5% 的效能 - 為每一個依賴服務維護一個執行緒池（或者訊號量），當執行緒池佔滿，該依賴服務將會立即拒絕服務而不是排隊等待
- 劃分出成功、失敗（丟擲異常）、超時或者執行緒池佔滿四種請求依賴服務時可能出現的狀態
- 引入『熔斷器』機制，在依賴服務失效比例超過閾值時，手動或者自動地切斷服務一段時間
- 當請求依賴服務時出現拒絕服務、超時或者短路（多個依賴服務順序請求，前面的依賴服務請求失敗，則後面的請求不會發出）時，執行該依賴服務的失敗回退邏輯
- 近實時地提供監控和配置變更
當使用 Hystrix 包裝了你的所有依賴服務的請求後，上面圖中所示的系統拓撲將會變成如下形式：
每個依賴服務都被隔離開來，Hystrix 會嚴格控制其在延遲發生時對資源的佔用，並在任何失效發生時，執行失敗回退邏輯。