SpringCloud---熔斷降級理解、Hystrix實戰(五)

SpringCloud---熔斷降級理解、Hystrix實戰(五)

http://www.javashuo.com/article/p-azcpnxjz-dn.html

http://www.javashuo.com/article/p-shppoguv-gk.html

1、概念

   一、爲何須要熔斷降級

（1）需求背景

   它是系統負載太高，突發流量或者網絡等各類異常狀況介紹，經常使用的解決方案。

   在一個分佈式系統裏，一個服務依賴多個服務，可能存在某個服務調用失敗，好比超時、異常等，如何可以保證在一個依賴出問題的狀況下，不會致使總體服務失敗。

   好比：某微服務業務邏輯複雜，在高負載狀況下出現超時狀況。

  內部條件：程序bug致使死循環、存在慢查詢、程序邏輯不對致使耗盡內存

  外部條件：黑客攻擊、促銷、第三方系統響應緩慢。

（2）解決思路

   解決接口級故障的核心思想是優先保障核心業務和優先保障絕大部分用戶。好比登陸功能很重要，當訪問量太高時，停掉註冊功能，爲登陸騰出資源。

（3）解決策略

  熔斷，降級，限流，排隊。

    二、什麼是熔斷

     通常是某個服務故障或者是異常引發的，相似現實世界中的‘保險絲’，當某個異常條件被觸發，直接熔斷整個服務，而不是一直等到此服務超時，爲了防止防止整個系統的故障，

而採用了一些保護措施。過載保護。好比A服務的X功能依賴B服務的某個接口，當B服務接口響應很慢時，A服務X功能的響應也會被拖慢，進一步致使了A服務的線程都卡在了X功能

上，A服務的其它功能也會卡主或拖慢。此時就須要熔斷機制，即A服務不在請求B這個接口，而能夠直接進行降級處理。

   三、什麼是降級

      服務器當壓力劇增的時候，根據當前業務狀況及流量，對一些服務和頁面進行有策略的降級。以此緩解服務器資源的的壓力，以保證核心業務的正常運行，同時也保持了客戶和

大部分客戶的獲得正確的相應。

自動降級：超時、失敗次數、故障、限流

 （1）配置好超時時間(異步機制探測回覆狀況)；

 （2）不穩的的api調用次數達到必定數量進行降級(異步機制探測回覆狀況)；

 （3）調用的遠程服務出現故障(dns、http服務錯誤狀態碼、網絡故障、Rpc服務異常)，直接進行降級。

人工降級：秒殺、雙十一大促降級非重要的服務。

  四、熔斷和降級異同

相同點：

   1）從可用性和可靠性觸發，爲了防止系統崩潰

   2）最終讓用戶體驗到的是某些功能暫時不能用

不一樣點：

    1）服務熔斷通常是下游服務故障致使的，而服務降級通常是從總體系統負荷考慮，由調用方控制

   2）觸發緣由不一樣，上面顏色字體已解釋

五、熔斷到降級的流程講解

Hystrix提供了以下的幾個關鍵參數，來對一個熔斷器進行配置：

circuitBreaker.requestVolumeThreshold    //滑動窗口的大小，默認爲20 
circuitBreaker.sleepWindowInMilliseconds //過多長時間，熔斷器再次檢測是否開啓，默認爲5000，即5s鍾 
circuitBreaker.errorThresholdPercentage  //錯誤率，默認50%

3個參數放在一塊兒，所表達的意思就是：

    每當20個請求中，有50%失敗時，熔斷器就會打開，此時再調用此服務，將會直接返回失敗，再也不調遠程服務。直到5s鍾以後，從新檢測該觸發條件，判斷是否把熔斷器關閉，或者繼續打開。

這裏面有個很關鍵點，達到熔斷以後，那麼後面它就直接不去調該微服務。那麼既然不去調該微服務或者調的時候出現異常，出現這種狀況首先不可能直接把錯誤信息傳給用戶，因此針對熔斷

咱們能夠考慮採起降級策略。所謂降級，就是當某個服務熔斷以後，服務器將再也不被調用，此時客戶端能夠本身準備一個本地的fallback回調，返回一個缺省值。 

這樣作，雖然服務水平降低，但好歹可用，比直接掛掉要強，固然這也要看適合的業務場景。

2、Hystrix實戰

使用到的組件包括：Eureka、Feign包括如下三個項目：

    （1）Eureka-server：   8081   註冊中心

    （2）product-server ：8001   商品微服務

    （3）order-server ：   9001   訂單微服務

 

註冊中心、商品微服務、在以前博客都已搭建，這裏就不重複寫。這裏只寫order-server微服務。

建立：

https://github.com/cwn132/service-consumer

 

3、結合redis模擬熔斷降級服務異常報警通知實戰