1. 程式人生 > >高並發之服務降級和服務熔斷

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

height 靜態 遠程服務 很多 可用性 場景 模式 quest 部分

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

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