高并發之服務降級和服務熔斷

服務降級：

服務壓力劇增的時候根據當前的業務情況及流量對一些服務和頁面有策略的降級，以此環節服務器的壓力，以保證核心任務的進行。

同時保證部分甚至大部分任務客戶能得到正確的相應。也就是當前的請求處理不了了或者出錯了，給一個默認的返回。

服務熔斷：在股票市場，熔斷這個詞大家都不陌生，是指當股指波幅達到某個點后，交易所為控制風險采取的暫停交易措施。相應的，服務熔斷一般是指軟件系統中，由于某些原因使得服務出現了過載現象，為防止造成整個系統故障，從而采用的一種保護措施，所以很多地方把熔斷亦稱為過載保護。

降級分類

降級按照是否自動化可分為：自動開關降級和人工開關降級。

降級按照功能可分為：讀服務降級、寫服務降級。

降級按照處于的系統層次可分為：多級降級。

自動降級分類

（1）、超時降級：主要配置好超時時間和超時重試次數和機制，并使用異步機制探測回復情況

（2）、失敗次數降級：主要是一些不穩定的api，當失敗調用次數達到一定閥值自動降級，同樣要使用異步機制探測回復情況

（3）、故障降級：比如要調用的遠程服務掛掉了（網絡故障、DNS故障、http服務返回錯誤的狀態碼、rpc服務拋出異常），則可以直接降級。降級后的處理方案有：默認值（比如庫存服務掛了，返回默認現貨）、兜底數據（比如廣告掛了，返回提前準備好的一些靜態頁面）、緩存（之前暫存的一些緩存數據）

（4）、限流降級

當我們去秒殺或者搶購一些限購商品時，此時可能會因為訪問量太大而導致系統崩潰，此時開發者會使用限流來進行限制訪問量，當達到限流閥值，后續請求會被降級；降級后的處理方案可以是：排隊頁面（將用戶導流到排隊頁面等一會重試）、無貨（直接告知用戶沒貨了）、錯誤頁（如活動太火爆了，稍后重試）。

服務熔斷和服務降級比較：

兩者其實從有些角度看是有一定的類似性的：

目的很一致，都是從可用性可靠性著想，為防止系統的整體緩慢甚至崩潰，采用的技術手段；

最終表現類似，對于兩者來說，最終讓用戶體驗到的是某些功能暫時不可達或不可用；

粒度一般都是服務級別，當然，業界也有不少更細粒度的做法，比如做到數據持久層（允許查詢，不允許增刪改）；

自治性要求很高，熔斷模式一般都是服務基于策略的自動觸發，降級雖說可人工干預，但在微服務架構下，完全靠人顯然不可能，開關預置、配置中心都是必要手段；

而兩者的區別也是明顯的：

觸發原因不太一樣，服務熔斷一般是某個服務（下游服務）故障引起，而服務降級一般是從整體負荷考慮；

管理目標的層次不太一樣，熔斷其實是一個框架級的處理，每個微服務都需要（無層級之分），而降級一般需要對業務有層級之分（比如降級一般是從最外圍服務開始）

實現方式不太一樣

服務降級要考慮的問題：

1.核心和非核心服務

2.是否支持降級，降級策略

3.業務放通的場景，策略

Hystrix，該庫旨在通過控制那些訪問遠程系統、服務和第三方庫的節點，從而對延遲和故障提供更強大的容錯能力。Hystrix具備擁有回退機制和斷路器功能的線程和信號隔離，請求緩存和請求打包（request collapsing，即自動批處理，譯者注），以及監控和配置等功能。

---

---

---

---

---

---

服務降級、熔斷、限流的區別

降級

系統將某些不重要的業務或接口的功能降低，可以只提供部分功能，也可以完全停到所有所有不重要的功能。降級的思想是丟車保帥。

常見降級方式：

• 系統后門降級：系統預留后門用于降級，比如提供一個降級URL，訪問URL時就執行降級指令。缺點：如果服務器數量多，需要一臺一臺去操作，效率低。
• 獨立系統降級：將降級操作獨立到一個單獨的系統中，可以實現復雜的權限管理、批量操作等功能。
  

熔斷

降級是應對系統自身的故障，而熔斷的目的是應對外部系統的故障。比如A服務的X功能依賴B服務的某個接口，當B服務接口響應很慢時，A服務X功能的響應也會被拖慢，進一步導致了A服務的線程都卡在了X功能上，A服務的其它功能也會卡主或拖慢。此時就需要熔斷機制，即A服務不在請求B這個接口，A服務內部發現B接口就直接返回錯誤，從而避免整個A服務被拖慢。

• 實現思路：需要系統有一個統一的API調用層，由API來進行采樣或者統計。

限流

限流：只允許系統能夠承受的訪問量進來，超出的會被丟棄。降級從系統功能優先級角度考慮如何應對故障，而限流則從用戶訪問壓力的角度來考慮如何應對故障。

常見限流方式

• 基于請求限流：指從外部請求的角度考慮限流。
• 基于資源限流：指從系統內部考慮，找到影響性能的關鍵資源，對其使用上限限制。

案例

如果你來設計一個整點限量秒殺系統，包括登錄、搶購、支付（依賴支付寶）等核心功能，你會如何設計接口級的故障應對手段？

思路：

• 降級（丟車保帥）：在秒殺時，通過服務降級把注冊、修改個人信息等非核心功能關閉掉。
• 熔斷：支付依賴第三方服務，要設置熔斷策略，熔斷后要給出友好提示，比如10分鐘后再來支付。
• 限流：搶購下單接口采用限流方式，如搶購1000件商品，則設置2000大小的隊列，請求超過2000后直接拒絕掉。

---

---

---

服務的熔斷和降級的區別

熔斷：

舉個例子解釋，生活中每家每戶都在用電，小明家的電線由于故障致使了小明家停電了。而小李、小張家的電是正常使用的。電力公司沒有由于小明家有故障線路而停掉其余人家的電，同時小明家沒有使用有故障的電路的電。這時即為熔斷。熔斷的目的是當A服務模塊中的某塊程序出現故障后為了避免影響其余客戶端的請求而作出的及時回應。架構

降級：

舉個例子解釋，咱們去銀行排隊辦理業務，大部分的銀行分為普通窗口、特殊窗口（VIP窗口，老年窗口）。某一天銀行大廳排普通窗口的人巨多。這時特殊窗口貼出告示說某時刻以后再開放。那么這時特殊窗口的工做人員就能夠空出來去幫其余窗口辦理業務，提升辦事效率，已達到解決普通窗口排隊的人過的目的。這時即為降級，降級的目的是為了解決總體項目的壓力，而犧牲掉某一服務模塊而采起的措施。微服務

以上為了加深理解分別舉了個例子。有不妥的地方歡迎留言指出。下面是前邊的總結：

二者其實從有些角度看是有必定的相似性的：

目的很一致，都是從可用性可靠性著想，為防止系統的總體緩慢甚至崩潰，采用的技術手段；

最終表現相似，對于二者來講，最終讓用戶體驗到的是某些功能暫時不可達或不可用；

粒度通常都是服務級別，固然，業界也有很多更細粒度的作法，好比作到數據持久層（容許查詢，不容許增刪改）；

自治性要求很高，熔斷模式通常都是服務基于策略的自動觸發，降級雖然說可人工干預，但在微服務架構下，徹底靠人顯然不可能，開關預置、配置中心都是必要手段；

而二者的區別也是明顯的：

觸發緣由不太同樣，服務熔斷通常是某個服務（下游服務）故障引發，而服務降級通常是從總體負荷考慮；

管理目標的層次不太同樣，熔斷實際上是一個框架級的處理，每一個微服務都須要（無層級之分），而降級通常須要對業務有層級之分（好比降級通常是從最外圍服務開始）

總結

以上是生活随笔為你收集整理的高并发之服务降级和服务熔断____服务降级、熔断、限流的区别的全部內容，希望文章能夠幫你解決所遇到的問題。

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