介紹一下降級和熔斷的概念

什么是降級呢? 降級意味著多種方案，當系統出現問題的時候，你有一個備選方案可以馬上切換，比如有一個接口的功能是實時預測未來一個月某個商品的采購數量，突然間依賴的上游系統出現問題了，那么我們的接口就完全不可用了嗎？顯然這是不應該的，這時我接口就可以降級，返回昨天實時計算出來的結果，雖然準確性可能差一點，但系統能夠正常運轉，降級也分為自動降級和手動降級，前者是系統自動檢測到問題時自動切換，后者是系統檢測到問題報警，人為的切換，降級代表著系統相比降級之前其功能表現不如之前的完美（這個具體體現在功能準確性，可用性上等,如上面接口的例子）
什么是熔斷呢? 通俗來講，熔斷指的是遇到危險了，必須馬上停掉，比如生活中的電流過大，必須馬上切斷，否則就發生了火災了，熔斷之后就會導致斷電，完全不可用，在一個系統中，假設一個接口部署了10臺機器（分布式），突然某一臺機器的接口調用情況正確率降到90%，那么這臺機器肯定出現問題了，這個時候就需要熔斷這臺機器，把這臺機器從整個集群中摘掉，從而保證用戶的請求100%的正確，再比如，一個系統中有很多功能，這些功能有些是核心功能，有些是非核心功能，那么在一些大促中，我們可能熔斷掉一些非核心功能，從而保證核心功能的流轉（登錄和注冊，登錄屬于核心，注冊是屬于非核心）

為什么需要降級和熔斷

不管是降級還是熔斷，都是為了保證了系統的穩定性，可用性。降級往往代表系統功能部分不可用，熔斷代表的是完全不可用，再舉一個簡單例子，注冊功能，降級可能出現的情況是手機號可以正常，郵箱不能注冊，而熔斷出現的情況是注冊功能完全不可用，所以說有時候熔斷是一種特殊的降級。這在整個系統設計編碼中都需要考慮到。

常用的降級和熔斷策略

在業務系統時，降級在編碼時需要考慮好備選方案，和業務確認方案的合理性，熔斷在編碼時需要分離核心功能和非核心功能，梳理上下游依賴關系，防止強依賴引起的系統的雪崩，這些是業務系統功能設計時需要經?？紤]的。

所有業務系統都需要考慮的東西，就意味著可以優化，可以剝離，抽象出來，做成公共組件，中間件，形成通用性。

上面有提到，降級和熔斷的最終目的都是保證系統的穩定性，可靠性，保證核心服務可用，那么在形成中間件時具體措施是什么呢？

降級

超時降級（調用服務時超時返回默認值或者其它處理辦法）
失敗次數降級（服務可用率下降時降級）
限流也是降級的一種辦法
故障降級（依賴的外系統發生故障時降級）
拒絕服務降級

熔斷

系統攻擊熔斷（當某個服務遭遇流量攻擊時，可以熔斷這個服務）
涉及核心功能運行時的熔斷（下單和評論功能，關鍵時刻可以熔斷評論功能）

不管降級還是熔斷，在設計時都要考慮：降級熔斷算法，恢復機制，報警。這些是必備的，不能系統降級了或者熔斷了就無法回復之前的情況，也不能不報警，要不然開發人員都不知道，這還得了。

熔斷和降級的異樣性

兩者的目的相當
兩者的最終的表現的相同
粒度一樣，大多數都是服務級別的粒度，也有可能是方法級別的
自治性要求比較高（盡可能的智能化）
降級一般是客戶端處理，熔斷是在服務端處理的

設計方案

介紹一種的常見的方案，服務碼+配置中心，調用任何服務時都傳入必要參數服務碼和開關，默認關閉，當觸發某種條件時可打開開關，或者通過配置中心手動推送開關新的值，從而保護系統不被單個服務壓垮，別看這個簡單，很多系統都是這么做的。

func  DowngradeAndFuse (ctx context.Context){
    //業務碼
    bizValue := ctx.Value("bizCode")
    //熔斷降級標識
    flag := ctx.Value("flag")
   
    if bizValue == "指定業務" && flag {
       //降級或者熔斷
       return
    }
}

Hystrix的原理

Hystrix有Java和Go版本的，Java版本的是Netflix公司開發并開源的，Go版本的是由afex(個人)創建的，代碼庫地址如下:

https://github.com/Netflix/Hystrix
https://github.com/afex/hystrix-go

Hystrix引入以下手段來保護系統：

資源隔離（線程池和信號量兩種手段的隔離）
限流
降級
熔斷（斷路器）

Hystrix如何設計實現這些手段呢？

使用命令模式將所有對外部服務（或依賴關系）的調用包裝在HystrixCommand或HystrixObservableCommand對象中，并將該對象放在單獨的線程中執行
每一個依賴都有自己對應的線程池或者信號量，線程池耗盡時，拒絕請求
維護請求的各種狀態（成功，失敗，超時的次數）
當錯誤率到達一定閾值時，進行熔斷，過一定的時間后又恢復
提供降級，失敗，成功，熔斷后的回調邏輯
實時的監控指標和配置信息的修改

用代碼實現一個hystrix-go的Demo，第一步寫在init初始化中，配置hystrix的一些參數，如果不配置的話，也會有默認參數。

 func init() {
   hystrix.ConfigureCommand("my_command", hystrix.CommandConfig{
      //多長時間 超時
      Timeout: 5000,
      //最大并發數
      MaxConcurrentRequests: 1,
      //錯誤百分比,錯誤率達到這個數值開啟熔斷
      ErrorPercentThreshold: 25,
      //當熔斷器被打開后，SleepWindow的時間就是控制過多久后去嘗試服務是否可用了(毫秒)
      SleepWindow: 10,
      //最小請求數，只有到達這個數量后才判斷是否開啟熔斷
      RequestVolumeThreshold: 10,
   })
}

如何使用hystrix熔斷呢，總的來說分為4個步驟：
第一步：定義你調用的外部系統的服務
第二步：設置回調函數(當超時或者熔斷了會調用回調函數)
第三步：使用hystrix的api調用第一步定義好的服務
第四步：獲取最終結果(結果可能時正確的，也可能是一個err)

//異步調用
func HystrixAsyStudy() {
   //第一步：
   result := make(chan string, 1)
   //定義依賴外部系統的函數
   f1 := func() error {
      // 處理業務系統（調用外部服務）
      fmt.Println("處理業務邏輯")
      result <- "處理結果"
      return nil
   }
   //第二步：
   //回調函數，只有 err不為空，才會執行回調函數(如果發生了超時，熔斷，
   //限流，超時之后也會回調)
   fallBack1 := func(err error) error {
      fmt.Println("回調函數")
      return err
   }
   //第三步：
   errors := hystrix.Go("my_command", f1, fallBack1)
   //第四步：
   select {
   case r := <-result:
      fmt.Println(r)
   case e := <-errors:
      fmt.Println(e)
   }
}

Hystrix更加詳細的文檔參考如下地址：

//Java版本的
https://github.com/Netflix/Hystrix/wiki/How-To-Use#Common-Patterns-FailFast
//Go版本的
https://github.com/afex/hystrix-go

總結

以上是生活随笔為你收集整理的微服务-高并发情况下接口降级和熔断策略的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。