教程:一塊兒學習Hystrix--Hystrix斷路器配置及使用場景

目錄

• Hystrix本系列博文
• 如何配置以及調整斷路器
• 預料中的抖動和失敗
• 潛在風險
• 聲明

Hystrix本系列博文

    如下爲博主寫Hystrix系列的文章列表以下:

     點擊查看 Hystrix入門

    點擊查看 Hystrix命令執行

    點擊查看 Hystrix處理異常機制(降級方法)

    點擊查看 Hystrix命令名稱、分組、線程池

    點擊查看 Hystrix命令名稱、Hystrix請求處理

    點擊查看 Hystrix請求處理

    點擊查看 Hystrix經常使用場景--失敗

    點擊查看 Hystrix經常使用場景--降級(回退)

配置以及調整斷路器

     配置一個新電路的典型方法是使用自由配置(超時/線程數/信號量)發佈到生產中，而後觀察系統一個週期的峯值後，調整到一個更精準的配置。

    在實踐中典型的作法以下：

1. 默認的超時時間爲 1000ms ，若是確認系統超時時間高於這個值，則能夠根據實際狀況調整它。
2. 默認的線程數爲10，若是確認系統線程數高於這個值，則能夠根據實際狀況調整它
3. 部署一個 canary ，一切順利的話， 在整個系統運行24小時
4. 經過標準的報警和監控捕獲任何問題
5. 24小時後，使用延遲百分比和流量來計算最低配置值，對斷路器來講是有意義的。
6. 在生產過程當中動態更改值，並使用實時指示板監視它們，直到確信爲止。
7. 若是斷路器的行爲或性能特徵發生變化，而且經過警報和（或）儀表盤監控引發警戒時，纔會再次查看該斷路器的配置。

下面的圖表明瞭一個典型的思考過程，它展現瞭如何選擇線程池、隊列和執行超時(或信號量大小)的大小

（來自官網）

    對於大多數斷路器，應該儘可能將它們的超時世間設置爲接近正常健康系統的99.5% ，這樣將隔離很差的請求，不讓他們佔用系統資源或影響用戶體驗。

     必須對線程池和隊列進行大小調整，讓它們是整個應用程序資源的一小部分，不然它們將沒法防止依賴於飽和的可用資源。

    配置和調優斷路器重要的事情以下：

• 應該在生產中基於實際的流量模式進行調優。
• 能夠輕鬆地實時調整設置，同時監視不一樣設置對系統的影響。

預料中的抖動和失敗

    hystrix使用的是毫秒粒度的策略和報表度量， 「抖動」——被視爲一陣陣的超時、線程池拒絕、系統緩慢等其餘相似的事情。在一個大集羣系統中對於一個高容量斷路器，一般這些狀況發生在任何特殊時刻。 這些被Hystrix捕獲的度量粒度是許多軟件系統沒有的，所以這些報表可能會引發沒必要要的擔心。

    在這個生產中監視Hystrix命令的Netflix API儀表板的屏幕截圖中，能夠看到在243個服務器統計窗口中顯示了中10秒內超時和線程池拒絕的橙色和紫色數字。

    

    大多數系統是基於至關高的水平標準測量的——即便是每分鐘完成的百分比。並且，一般是爲整個應用程序請求迴路所作的，並非與之交互的單個依賴項。在Hystrix中，能夠看到一個關於正在發生的事情的更精確的視圖。一旦有了能夠查看每一個依賴項正在發生什麼的放大鏡，就不須要驚訝之前可能看不到的抖動。

    一些案例以下：

• 客戶端機器垃圾收集（機器在請求的中間進行垃圾收集）
• 服務機器垃圾收集（遠程服務器在請求的中間執行垃圾收集）
• 網絡問題（抖動）
• 不一樣請求參數的不一樣負載大小
• 緩存未命中
• 突發性調用狀況
• 新機器啓動（部署，自動伸縮事件）和「熱身」

潛在風險

     若是注意到超時，不要以從新配置去解決這個問題。若是一個Hystrix命令正在脫離負載，那麼它就會作應該作的事情（假設在健康的時候正確地配置（請參閱上面的內容）了它）。

    在早期在Netflix 採用Hystrix,一個斷路器成爲潛在的動態更改增長線程池,隊列、超時等等屬性,試着「給它一些喘息的空間「並讓它再次工做。但這與應該作的偏偏相反。若是正確地爲一個健康的系統配置了命令，如今出現拒絕、超時和/或短路，應該集中精力修復潛在的根本緣由。

     不要犯經過給命令提供更多可用的資源的錯誤。（在極端狀況下，若是這樣作的話，能夠經過增長線程池、隊列、超時、信號量等來對本身進行DDOS攻擊）。

     例如，假設有一個100臺服務器集羣，每一個服務器有10個併發鏈接到一個服務，那就是：可能有1000個併發鏈接。健康的時候一般在任什麼時候候使用200-300個。若是發生延遲並將它們所有備份，那麼如今使用的是1000個鏈接。每一個服務器10個對於客戶端不算多，因此咱們試着增長到20？最有可能的是，若是10個飽和，20個也會飽和。如今有2000個鏈接在後端，讓事情變得更糟。

     這就是斷路器存在的緣由之一——在底層系統上「釋放壓力」讓它們恢復，而不是重試循環、掛起鏈接等方面對服務器進行更多的請求。

     例如，這裏有一個例子，一個依賴項經歷延遲致使超時，超時時長高到斷路器在大約三分之一的集羣上發生故障。它是系統中惟一存在健康問題的，Hystrix則阻止它在有延遲問題的狀況下獲取其餘資源。

    簡而言之，讓系統擺脫負載、短路、超時和拒絕，直到底層系統恢復健康，hystrix層將自行恢復到健康狀態。Hystrix正好是爲這個場景設計的，關鍵是要減小潛在系統的資源利用率，這樣能夠經過將大部分資源隔離起來以及遠離那些掛在潛在鏈接上的資源，從而快速地恢復。

聲明

    轉帖請註明原貼地址： https://my.oschina.net/u/2342969/blog/1820133