目錄
- Hystrix本系列博文
- 依賴失敗的表象
- 依賴失敗觸發回退的表象
- 級聯失敗的表象
- 服務自己失敗而不是依賴失敗的表象
- 聲明
Hystrix本系列博文
以下爲博主寫Hystrix系列的文章列表如下:
點擊查看 Hystrix入門
點擊查看 Hystrix命令執行
點擊查看 Hystrix處理異常機制(降級方法)
點擊查看 Hystrix命令名稱、分組、線程池
點擊查看 Hystrix命令名稱、Hystrix請求處理
點擊查看 Hystrix請求處理
點擊查看 Hystrix常用場景--失敗
點擊查看 Hystrix常用場景--降級(回退)
點擊查看 Hystrix斷路器配置及使用場景
依賴失敗的表象
在分佈式系統中，最典型的失敗類型是單個依賴失敗或休眠，而其他所有的都保持健康。 在這些情況下，度量和指示板非常明顯地顯示正在發生的事情：
上面的截圖顯示了一個帶有20%錯誤率的單電路：高到足以產生影響，但還不足以啓動斷路器。其他三個電路不受影響。
在這個特定的例子中，是實際的錯誤，而不是延遲，這導致了問題——就像紅色數字而不是橙色顯示的那樣。
在同一事件中，捕捉到了以下圖表，以下圖標顯示這條線路的歷史趨勢，以及在故障和降級中是如何急劇上升的。
依賴失敗觸發回退的表象
這個圖表是另一個單電路故障的屏幕截圖，注意有99.5%的延遲非常高。 這是底層工作線程要完成的時間，這將使線程池飽和，並導致調用線程超時。
在集羣中，除了一臺機器之外，所有的機器都有斷路器被熔斷，這就導致了大多數流量被短路（藍色），而在一臺仍然嘗試大多數請求的機器上被超時了（橙色）。
注意，其他的電路是健康的，左邊的線圖顯示的是返回時長500s沒有增加，因爲這個電路正在返回一個回退操作，這樣用戶就會收到一個降級但仍然有用的體驗。
級聯失敗的表象
下面的屏幕截圖代表了一個系統的失敗（高延遲情況），這個系統很大程度上依賴於許多其他系統，因此故障也會在它們之間發生。Netflix的API系統必須能夠抵禦延遲和失敗，不僅僅因爲單一的根本原因，而是所有受到它影響的系統。
下面的截圖顯示了6個電路，代表了三個不同的系統：
在這一事件發生時，Hystrix仍然主要是一個“netflix-api”的東西。隨着Hystrix在越來越多的團隊中運轉，這進一步限制了級聯失敗的影響，如下圖所示：
服務自己失敗而不是依賴失敗的表象
如果所有的電路看起來都很糟糕（儀表板都被點亮了），那麼很有可能問題是自己系統，而不是所有的依賴項同時發生。
導致這種問題的兩個案例如下：
- 系統過載（高負載，CPU使用率等）。
這可能發生的一個例子是，如果自動伸縮策略失敗了，或者在流量激增的情況下無法快速伸縮，機器接收的流量超出了它們的處理能力。
- 內存泄漏最終會導致GC抖動，從而竊取CPU並導致暫停，從而導致電路超時、備份和拒絕
聲明
轉帖請註明原貼地址： https://my.oschina.net/u/2342969/blog/1820306