教程:一起學習Hystrix--服務(依賴)失敗場景的表象 原

目錄

  • 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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章