微服務hystrix斷路由詳解

Hystrix是什麼

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

Hystrix爲了什麼

Hystrix被設計的目標是：

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

Hystrix解決了什麼問題

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

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

99.9930  =  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