目錄
- 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