Hystrix介紹

Hystrix是什麼

在分佈式環境中，許多服務依賴項中的一些必然會失敗。Hystrix是一個庫，經過添加延遲容忍和容錯邏輯，幫助你控制這些分佈式服務之間的交互。Hystrix經過隔離服務之間的訪問點、中止級聯失敗和提供回退選項來實現這一點，全部這些均可以提升系統的總體彈性。

Hystrix爲了什麼

Hystrix被設計的目標是：

1. 對經過第三方客戶端庫訪問的依賴項（一般是經過網絡）的延遲和故障進行保護和控制。
2. 在複雜的分佈式系統中阻止級聯故障。
3. 快速失敗，快速恢復。
4. 回退，儘量優雅地降級。
5. 啓用近實時監控、警報和操做控制。

Hystrix解決了什麼問題

複雜分佈式體系結構中的應用程序有許多依賴項，每一個依賴項在某些時候都不可避免地會失敗。若是主機應用程序沒有與這些外部故障隔離，那麼它有可能被他們拖垮。

例如，對於一個依賴於30個服務的應用程序，每一個服務都有99.99%的正常運行時間，你能夠指望以下：

99.99³⁰  =  99.7% 可用

也就是說一億個請求的0.03% = 3000000 會失敗

若是一切正常，那麼每月有2個小時服務是不可用的

現實一般是更糟糕 

---

當一切正常時，請求看起來是這樣的：

當其中有一個系統有延遲時，它可能阻塞整個用戶請求：

在高流量的狀況下，一個後端依賴項的延遲可能致使全部服務器上的全部資源在數秒內飽和（PS：意味着後續再有請求將沒法當即提供服務）

Hystrix設計原則是什麼

• 防止任何單個依賴項耗盡全部容器（如Tomcat）用戶線程。
• 甩掉包袱，快速失敗而不是排隊。
• 在任何可行的地方提供回退，以保護用戶不受失敗的影響。
• 使用隔離技術（如隔離板、泳道和斷路器模式）來限制任何一個依賴項的影響。
• 經過近實時的度量、監視和警報來優化發現時間。
• 經過配置的低延遲傳播來優化恢復時間。
• 支持對Hystrix的大多數方面的動態屬性更改，容許使用低延遲反饋循環進行實時操做修改。
• 避免在整個依賴客戶端執行中出現故障，而不單單是在網絡流量中。

Hystrix是如何實現它的目標的

1. 用一個HystrixCommand 或者 HystrixObservableCommand （這是命令模式的一個例子）包裝全部的對外部系統（或者依賴）的調用，典型地它們在一個單獨的線程中執行
2. 調用超時時間比你本身定義的閾值要長。有一個默認值，對於大多數的依賴項你是能夠自定義超時時間的。
3. 爲每一個依賴項維護一個小的線程池(或信號量)；若是線程池滿了，那麼該依賴性將會當即拒絕請求，而不是排隊。
4. 調用的結果有這麼幾種：成功、失敗（客戶端拋出異常）、超時、拒絕。
5. 在一段時間內，若是服務的錯誤百分比超過了一個閾值，就會觸發一個斷路器來中止對特定服務的全部請求，不管是手動的仍是自動的。
6. 當請求失敗、被拒絕、超時或短路時，執行回退邏輯。
7. 近實時監控指標和配置變化。

當你使用Hystrix來包裝每一個依賴項時，上圖中所示的架構會發生變化，以下圖所示：

每一個依賴項相互隔離，當延遲發生時，它會被限制在資源中，幷包含回退邏輯，該邏輯決定在依賴項中發生任何類型的故障時應做出何種響應：

https://github.com/Netflix/Hystrix/wiki