SpringCloud---熔斷降級理解、Hystrix實戰(五)
SpringCloud---熔斷降級理解、Hystrix實戰(五)
https://www.cnblogs.com/qdhxhz/p/9581440.html
一、概念
1、為什麽需要熔斷降級
（1）需求背景
它是系統負載過高，突發流量或者網絡等各種異常情況介紹，常用的解決方案。
在一個分布式系統裏，一個服務依賴多個服務，可能存在某個服務調用失敗，比如超時、異常等，如何能夠保證在一個依賴出問題的情況下，不會導致整體服務失敗。
比如：某微服務業務邏輯復雜，在高負載情況下出現超時情況。
內部條件：程序bug導致死循環、存在慢查詢、程序邏輯不對導致耗盡內存
外部條件：黑客攻擊、促銷、第三方系統響應緩慢。
（2）解決思路
解決接口級故障的核心思想是優先保障核心業務和優先保障絕大部分用戶。比如登錄功能很重要，當訪問量過高時，停掉註冊功能，為登錄騰出資源。
（3）解決策略
熔斷，降級，限流，排隊。
2、什麽是熔斷
一般是某個服務故障或者是異常引起的，類似現實世界中的‘保險絲’，當某個異常條件被觸發，直接熔斷整個服務，而不是一直等到此服務超時，為了防止防止整個系統的故障，
而采用了一些保護措施。過載保護。比如A服務的X功能依賴B服務的某個接口，當B服務接口響應很慢時，A服務X功能的響應也會被拖慢，進一步導致了A服務的線程都卡在了X功能
上，A服務的其它功能也會卡主或拖慢。此時就需要熔斷機制，即A服務不在請求B這個接口，而可以直接進行降級處理。
3、什麽是降級
服務器當壓力劇增的時候，根據當前業務情況及流量，對一些服務和頁面進行有策略的降級。以此緩解服務器資源的的壓力，以保證核心業務的正常運行，同時也保持了客戶和
大部分客戶的得到正確的相應。
自動降級：超時、失敗次數、故障、限流
（1）配置好超時時間(異步機制探測回復情況)；
（2）不穩的的api調用次數達到一定數量進行降級(異步機制探測回復情況)；
（3）調用的遠程服務出現故障(dns、http服務錯誤狀態碼、網絡故障、Rpc服務異常)，直接進行降級。
人工降級：秒殺、雙十一大促降級非重要的服務。
4、熔斷和降級異同
相同點：
1）從可用性和可靠性觸發，為了防止系統崩潰
2）最終讓用戶體驗到的是某些功能暫時不能用
不同點：
1）服務熔斷一般是下遊服務故障導致的，而服務降級一般是從整體系統負荷考慮，由調用方控制
2）觸發原因不同，上面顏色字體已解釋
5、熔斷到降級的流程講解
Hystrix提供了如下的幾個關鍵參數，來對一個熔斷器進行配置：
circuitBreaker.requestVolumeThreshold //滑動窗口的大小，默認為20 circuitBreaker.sleepWindowInMilliseconds //過多長時間，熔斷器再次檢測是否開啟，默認為5000，即5s鐘 circuitBreaker.errorThresholdPercentage //錯誤率，默認50%
3個參數放在一起，所表達的意思就是：
每當20個請求中，有50%失敗時，熔斷器就會打開，此時再調用此服務，將會直接返回失敗，不再調遠程服務。直到5s鐘之後，重新檢測該觸發條件，判斷是否把熔斷器關閉，或者繼續打開。
這裏面有個很關鍵點，達到熔斷之後，那麽後面它就直接不去調該微服務。那麽既然不去調該微服務或者調的時候出現異常，出現這種情況首先不可能直接把錯誤信息傳給用戶，所以針對熔斷
我們可以考慮采取降級策略。所謂降級，就是當某個服務熔斷之後，服務器將不再被調用，此時客戶端可以自己準備一個本地的fallback回調，返回一個缺省值。
這樣做，雖然服務水平下降，但好歹可用，比直接掛掉要強，當然這也要看適合的業務場景。
二、Hystrix實戰
使用到的組件包括：Eureka、Feign包括以下三個項目：
（1）Eureka-server： 8081 註冊中心
（2）product-server ：8001 商品微服務
（3）order-server ： 9001 訂單微服務
註冊中心、商品微服務、在之前博客都已搭建，這裏就不重復寫。這裏只寫order-server微服務。
創建：
https://github.com/cwn132/service-consumer
三、結合redis模擬熔斷降級服務異常報警通知實戰
SpringCloud---熔斷降級理解、Hystrix實戰(五)