高併發處理思路與手段(六) 服務降級與服務熔斷

2022-09-22 20:47:58 字數 2296 閱讀 2716

服務壓力劇增的時候根據當前的業務情況及流量對一些服務和頁面有策略的降級,以此緩解伺服器的壓力,以保證核心任務的進行。同時保證部分甚至大部分任務客戶能得到正確的響應。也就是當前的請求處理不了了或者出錯了,給一個預設的返回。

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

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

降級按照功能可分為:讀服務降級寫服務降級

降級按照處於的系統層次可分為:多級降級

(1)超時降級:主要配置好超時時間和超時重試次數和機制,並使用非同步機制探測回覆情況

(2)失敗次數降級:主要是一些不穩定的api,當失敗呼叫次數達到一定閥值自動降級,同樣要使用非同步機制探測回覆情況

(3)故障降級:比如要呼叫的遠端服務掛掉了(網路故障、dns故障、http服務返回錯誤的狀態碼、rpc服務丟擲異常),則可以直接降級。降級後的處理方案有:預設值(比如庫存服務掛了,返回預設現貨)、兜底資料(比如廣告掛了,返回提前準備好的一些靜態頁面)、快取(之前暫存的一些快取資料)

(4)限流降級

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

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

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

最終表現類似,對於兩者來說,最終讓使用者體驗到的是某些功能暫時不可達或不可用;

粒度一般都是服務級別,當然,業界也有不少更細粒度的做法,比如做到資料持久層(允許查詢,不允許增刪改);

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

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

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

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

實現方式不太一樣

1.核心和非核心服務

2.是否支援降級,降級策略

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

hystrix,該庫旨在通過控制那些訪問遠端系統、服務和第三方庫的節點,從而對延遲和故障提供更強大的容錯能力。hystrix具備擁有回退機制和斷路器功能的執行緒和訊號隔離,請求快取和請求打包(request collapsing,即自動批處理,譯者注),以及監控和配置等功能。

在通過第三方客戶端訪問(通常是通過網路)依賴服務出現高延遲或者失敗時,為系統提供保護和控制

在分散式系統中防止級聯失敗

快速失敗(fail fast)同時能快速恢復

提供失敗回退(fallback)和優雅的服務降級機制

提供近實時的監控、報警和運維控制手段

防止單個依賴耗盡容器(例如 tomcat)內所有使用者執行緒

降低系統負載,對無法及時處理的請求快速失敗(fail fast)而不是排隊

提供失敗回退,以在必要時讓失效對使用者透明化

使用隔離機制(例如『艙壁』/『泳道』模式,熔斷器模式等)降低依賴服務對整個系統的影響

針對系統服務的度量、監控和報警,提供優化以滿足近實時性的要求

在 hystrix 絕大部分需要動態調整配置並快速部署到所有應用方面,提供優化以滿足快速恢復的要求

能保護應用不受依賴服務的整個執行過程中失敗的影響,而不僅僅是網路請求

在一個單獨的執行緒中通過 hystrixcommand 或 hystrixobservablecommand 物件包裝所有外部系統(或依賴)的呼叫。

呼叫超時比設定的閾值更長。雖然有預設值,但是大多數依賴自己配置的這些超時“屬性”,所以每個依賴都略高於實測效能的99.5%。

為每個依賴保持一個小的執行緒池;如果執行緒池滿了,新來的請求會立即拒絕掉,而不是排隊等候。

測試成功、失敗(客戶端丟擲異常)、超時和執行緒拒絕。

當請求失敗、被拒、超時或者短路時的效能反饋邏輯。

準實時的監控指標和配置改變。