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

服務降級:
服務壓力劇增的時候根據當前的業務狀況及流量對一些服務和頁面有策略的降級,以此環節服務器的壓力,以保證核心任務的進行。
同時保證部分甚至大部分任務客戶能獲得正確的相應。也就是當前的請求處理不了了或者出錯了,給一個默認的返回。
服務熔斷:在股票市場,熔斷這個詞你們都不陌生,是指當股指波幅達到某個點後,交易所爲控制風險採起的暫停交易措施。相應的,服務熔斷通常是指軟件系統中,因爲某些緣由使得服務出現了過載現象,爲防止形成整個系統故障,從而採用的一種保護措施,因此不少地方把熔斷亦稱爲過載保護。
 
降級分類
降級按照是否自動化可分爲:自動開關降級和人工開關降級。
降級按照功能可分爲:讀服務降級、寫服務降級。
降級按照處於的系統層次可分爲:多級降級。
 
自動降級分類
(1)、超時降級:主要配置好超時時間和超時重試次數和機制,並使用異步機制探測回覆狀況
(2)、失敗次數降級:主要是一些不穩定的api,當失敗調用次數達到必定閥值自動降級,一樣要使用異步機制探測回覆狀況
(3)、故障降級:好比要調用的遠程服務掛掉了(網絡故障、DNS故障、http服務返回錯誤的狀態碼、rpc服務拋出異常),則能夠直接降級。降級後的處理方案有:默認值(好比庫存服務掛了,返回默認現貨)、兜底數據(好比廣告掛了,返回提早準備好的一些靜態頁面)、緩存(以前暫存的一些緩存數據)
(4)、限流降級
當咱們去秒殺或者搶購一些限購商品時,此時可能會由於訪問量太大而致使系統崩潰,此時開發者會使用限流來進行限制訪問量,當達到限流閥值,後續請求會被降級;降級後的處理方案能夠是:排隊頁面(將用戶導流到排隊頁面等一會重試)、無貨(直接告知用戶沒貨了)、錯誤頁(如活動太火爆了,稍後重試)。
 
服務熔斷和服務降級比較:
二者其實從有些角度看是有必定的相似性的:
  1. 目的很一致,都是從可用性可靠性着想,爲防止系統的總體緩慢甚至崩潰,採用的技術手段;
  2. 最終表現相似,對於二者來講,最終讓用戶體驗到的是某些功能暫時不可達或不可用;
  3. 粒度通常都是服務級別,固然,業界也有很多更細粒度的作法,好比作到數據持久層(容許查詢,不容許增刪改);
  4. 自治性要求很高,熔斷模式通常都是服務基於策略的自動觸發,降級雖然說可人工干預,但在微服務架構下,徹底靠人顯然不可能,開關預置、配置中心都是必要手段;
而二者的區別也是明顯的:
  1. 觸發緣由不太同樣,服務熔斷通常是某個服務(下游服務)故障引發,而服務降級通常是從總體負荷考慮;
  2. 管理目標的層次不太同樣,熔斷實際上是一個框架級的處理,每一個微服務都須要(無層級之分),而降級通常須要對業務有層級之分(好比降級通常是從最外圍服務開始)
  3. 實現方式不太同樣
服務降級要考慮的問題:
 1.核心和非核心服務
2.是否支持降級,降級策略
3.業務放通的場景,策略
 
Hystrix,該庫旨在經過控制那些訪問遠程系統、服務和第三方庫的節點,從而對延遲和故障提供更強大的容錯能力。Hystrix具有擁有回退機制和斷路器功能的線程和信號隔離,請求緩存和請求打包(request collapsing,即自動批處理,譯者注),以及監控和配置等功能。
相關文章
相關標籤/搜索