服務降級

1 、簡介

2 、使用場景

3 、核心設計

3.1 分布式開關

3.2 自動降級分類

3.3 配置中心

3.4 處理策略?

3.5 降級分類

3.6 服務降級要考慮的問題

4 、高級特性

4.1 分級降級

4.2 降級權值

5 、總結與展望

服務限流

一、為什么要做服務限流設計？

二、服務限流應該怎么做？

三、服務限流的注意事項

服務熔斷

服務熔斷和服務降級比較

熔斷器

雪崩效應

熔斷器（CircuitBreaker）

Hystrix

Hystrix特性

1.斷路器機制

2.Fallback

3.資源隔離

Hystrix能做什么？

Hystrix設計原則？

Hystrix怎樣實現目標？

服務降級

1 、簡介

什么是服務降級？當服務器壓力劇增的情況下，根據實際業務情況及流量，對一些服務和頁面有策略的不處理或換種簡單的方式處理，從而釋放服務器資源以保證核心交易正常運作或高效運作。

如果還是不理解，那么可以舉個例子：假如目前有很多人想要給我付錢，但我的服務器除了正在運行支付的服務之外，還有一些其它的服務在運行，比如搜索、定時任務和詳情等等。然而這些不重要的服務就占用了JVM的不少內存與CPU資源，為了能把錢都收下來（錢才是目標），我設計了一個動態開關，把這些不重要的服務直接在最外層拒掉，這樣處理后的后端處理收錢的服務就有更多的資源來收錢了（收錢速度更快了），這就是一個簡單的服務降級的使用場景。

2 、使用場景

服務降級主要用于什么場景呢？當整個微服務架構整體的負載超出了預設的上限閾值或即將到來的流量預計將會超過預設的閾值時，為了保證重要或基本的服務能正常運行，我們可以將一些?不重要?或?不緊急?的服務或任務進行服務的?延遲使用?或?暫停使用。

3 、核心設計

3.1 分布式開關

根據上述需求，我們可以設置一個分布式開關，用于實現服務的降級，然后集中式管理開關配置信息即可。具體方案如下：

3.2 自動降級分類

超時降級?—— 主要配置好超時時間和超時重試次數和機制，并使用異步機制探測恢復情況
失敗次數降級?—— 主要是一些不穩定的API，當失敗調用次數達到一定閥值自動降級，同樣要使用異步機制探測回復情況
故障降級?—— 如要調用的遠程服務掛掉了（網絡故障、DNS故障、HTTP服務返回錯誤的狀態碼和RPC服務拋出異常），則可以直接降級
限流降級?—— 當觸發了限流超額時，可以使用暫時屏蔽的方式來進行短暫的屏蔽

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

3.3 配置中心

微服務降級的配置信息是集中式的管理，然后通過可視化界面進行友好型的操作。配置中心和應用之間需要網絡通信，因此可能會因網絡閃斷或網絡重啟等因素，導致配置推送信息丟失、重啟或網絡恢復后不能再接受、變更不及時等等情況，因此服務降級的配置中心需要實現以下幾點特性，從而盡可能的保證配置變更即使達到：

啟動主動拉取配置?—— 用于初始化配置（減少第一次定時拉取周期）
發布訂閱配置?—— 用于實現配置及時變更（可以解決90%左右的配置變更）
定時拉取配置?—— 用于解決發布訂閱失效或消失丟失的情況（可以解決9%左右的發布訂閱失效的消息變更）
離線文件緩存配置?—— 用于臨時解決重啟后連接不上配置中心的問題
可編輯式配置文檔?—— 用于直接編輯文檔的方式來實現配置的定義
提供Telnet命令變更配置?—— 用于解決配置中心失效而不能變更配置的常見

3.4 處理策略

當觸發服務降級后，新的交易再次到達時，我們該如何來處理這些請求呢？從微服務架構全局的視角來看，我們通常有以下是幾種常用的降級處理方案：

頁面降級?—— 可視化界面禁用點擊按鈕、調整靜態頁面
延遲服務?—— 如定時任務延遲處理、消息入MQ后延遲處理
寫降級?—— 直接禁止相關寫操作的服務請求
讀降級?—— 直接禁止相關度的服務請求
緩存降級?—— 使用緩存方式來降級部分讀頻繁的服務接口

針對后端代碼層面的降級處理策略，則我們通常使用以下幾種處理措施進行降級處理：

拋異常
返回NULL
調用Mock數據
調用Fallback處理邏輯

3.5 降級分類

降級按照是否自動化可分為：自動開關降級和人工開關降級。
降級按照功能可分為：讀服務降級、寫服務降級。
降級按照處于的系統層次可分為：多級降級。

詳情參考--架構設計 -- 服務降級策略詳解

3.6 服務降級要考慮的問題

核心和非核心服務
是否支持降級，降級策略
業務放通的場景，策略

4 、高級特性

我們已經為每個服務都做好了一個降級開關，也已經在線上驗證通過了，感覺完全沒問題了。

場景一：某一天，運營搞了一次活動，突然跑過來說，現在流量已經快漲到上限了，有沒有批量降級所有不重要服務的方式？開發一臉懵逼的看著，這又不是操作DB，哪里有批量操作呀。

?場景二：某一天，運營又搞事了，說我們等下要搞一個活動，讓我們趕緊提前把不重要的服務都降級了，開發又是一臉懵逼，我怎么知道要降級哪些服務呀。

反思：服務降級的功能雖然是實現了，可是沒有考慮實施時的體驗。服務太多，不知道該降級哪些服務，單個操作降級速度太慢……

4.1 分級降級

當微服務架構發生不同程度的情況時，我們可以根據服務的對比而進行選擇式舍棄（即丟車保帥的原則），從而進一步保障核心的服務的正常運作。

如果等線上服務即將發生故障時，才去逐個選擇哪些服務該降級、哪些服務不能降級，然而線上有成百上千個服務，則肯定是來不及降級就會被拖垮。同時，在大促或秒殺等活動前才去梳理，也是會有不少的工作量，因此建議在開發期就需要架構師或核心開發人員來提前梳理好，是否能降級的初始評估值，即是否能降級的默認值。

為了便于批量操作微服務架構中服務的降級，我們可以從全局的角度來建立服務重要程度的評估模型，如果有條件的話，建議可以使用?層次分析法（The analytic hierarchy process，簡稱AHP）?的數學建模模型（或其它模型）來進行定性和定量的評估（肯定比架構師直接拍腦袋決定是否降級好很多倍，當然難度和復雜度也會高許多，即你需要一個會數學建模人才），而層次分析法的基本思路是人對一個復雜的決策問題的思維和判斷過程大體上是一樣的。

以下是個人給出的最終評價模型，可作為服務降級的評價參考模型進行設計：

我們利用數學建模的方式或架構師直接拍腦袋的方式，結合服務能否降級的優先原則，并根據臺風預警（都屬于風暴預警）的等級進行參考設計，可將微服務架構的所有服務進行故障風暴等級劃分為以下四種：

評估模型：

藍色風暴?—— 表示需要小規模降級非核心服務
黃色風暴?—— 表示需要中等規模降級非核心服務
橙色風暴?—— 表示需要大規模降級非核心服務
紅色風暴?—— 表示必須降級所有非核心服務

設計說明：

故障嚴重程度為：藍色＜黃色＜橙色＜紅色
建議根據二八原則可以將服務劃分為：80%的非核心服務+20%的核心服務

以上模型只是整體微服務架構的服務降級評估模型，具體大促或秒殺活動時，建議以具體主題為中心進行建立（不同主題的活動，因其依賴的服務不同，而使用不同的進行降級更為合理）。當然模型可以使用同一個，但其數據需要有所差異。最好能建立一套模型庫，然后實施時只需要輸入相關服務即可輸出最終降級方案，即輸出本次大促或秒殺時，當發生藍色風暴時需要降級的服務清單、當發生黃色風暴時需要降級的服務清單……

4.2 降級權值

微服務架構中有服務權值的概念，主要用于負載時的權重選擇，同樣服務降級權值也是類似，主要用于服務降級選擇時的細粒度優先級抉擇。所有的服務直接使用以上簡單的四級劃分方式進行統一處理，顯然粒度太粗，或者說出于同一級的多個服務需要降級時的?降級順序?該如何？甚至我想要人工智能化的?自動降級，又該如何更細粒度的控制？

基于上述的這些AI化的需求，我們可以為每一個服務分配一個降級權值，從而便于更加智能化的實現服務治理。而其評估的數值，同樣也可以使用數學模型的方式進行?定性?與?定量?的評估出來，也可以架構師根據經驗直接拍腦袋來確定。

5 、總結與展望

以上提供了半實際與半理論的服務降級方案，使用者可以根據其公司的實際情況進行適當的選擇，而完整的方案，筆者目前也沒有發現有實施過的，但可以建議有長遠服務治理規劃的大廠進行完整方案的研究與實施，會對未來人工智能萬物互聯的時代有較好的治理價值存在（個人看法）。而小廠出于成本和其發揮的價值的考慮，不建議使用這么復雜的方案，但可以實現分布式開關和簡單分級降級的功能特性。

本文主要以服務降級為核心進行更加理想的治理微服務架構，其中建議運用數學領域的適當模型來實現?定性?和?定量?的合理分析和治理微服務，為未來?人工智能治理微服務（Artificial Intelligence Governance Micro Service，簡稱AIGMS）提供方案支持。

服務限流

限流可以認為服務降級的一種，限流就是限制系統的輸入和輸出流量已達到保護系統的目的。一般來說系統的吞吐量是可以被測算的，為了保證系統的穩定運行，一旦達到的需要限制的閾值，就需要限制流量并采取一些措施以完成限制流量的目的。比如：延遲處理，拒絕處理，或者部分拒絕處理等等。

在介紹限流概念之前，我們先來聊聊身邊有哪些限流，如果有在帝都的碼農估計對限流是最深有感觸的，帝都但凡開個XXX會議，各大地鐵站都會限流。

每年的雙11都是剁手族的天堂，11月11號0點0幾秒的時候，下面這些場景或許你曾經遇到過。

當然，這幾年雙11各大電商對并發的支持做的越來越好，這里只是借鑒雙11剛推出之際，常常需要應對的一些問題。

通過這兩個場景，基本上服務限流的作用也就明白：

「服務限流」其實是指當系統資源不夠，不足以應對大量請求，即系統資源與訪問量出現矛盾的時候，我們為了保證有限的資源能夠正常服務，因此對系統按照預設的規則進行流量限制或功能限制的一種方法。

一、為什么要做服務限流設計？

再舉一個我們生活中的例子：一些熱門的旅游景點，往往會對每日的旅游參觀人數有嚴格的限制，比如廈門的鼓浪嶼、北京的故宮等，每天只會賣出固定數目的門票，如果你去的晚了，可能當天的票就已經賣完了，當天就無法進去游玩了。

為什么旅游景點要做這樣的限制呢？多賣一些門票多賺一些錢豈不是更好？

其實對于旅游景點而言，她們也很無奈，因為景點的服務資源有限嘛，每日能服務的人數是有限的，一旦放開限制了，景點的工作人員就會不夠用，衛生情況也得不到保障，安全也有隱患，超密集的人群也會嚴重的影響游客的體驗。
但由于景區名氣大，來游玩的旅客絡繹不絕，遠超出了景區的承載能力，因此景區只好做出限制每日人員流量的舉措。

同理，在IT軟件行業中，系統服務也是這樣的。

如果你的系統理論是時間單位內可服務100W用戶，但是今天卻突然來了300W用戶，由于用戶流量的隨機性，如果不加以限流，很有可能這300W用戶一下子就壓垮了系統，導致所有人都得不到服務。

因此為了保證系統至少還能為100W用戶提供正常服務，我們需要對系統進行限流設計。

有的人可能會想，既然會有300W用戶來訪問，那為啥系統不干脆設計成能足以支撐這么大量用戶的集群呢？

這是個好問題。如果系統是長期有300W的用戶來訪問，肯定是要做上述升級的，但是常常面臨的情況是，系統的日常訪問量就是100W，只不過偶爾有一些不可預知的特定原因導致的短時間的流量激增，這個時候，公司往往出于節約成本的考慮，不會為了一個不常見的尖峰來把我們的系統擴容到最大的尺寸。

二、服務限流應該怎么做？

對系統服務進行限流，一般有如下幾個模式：

熔斷：
這個模式是需要系統在設計之初，就要把熔斷措施考慮進去。當系統出現問題時，如果短時間內無法修復，系統要自動做出判斷，開啟熔斷開關，拒絕流量訪問，避免大流量對后端的過載請求。系統也應該能夠動態監測后端程序的修復情況，當程序已恢復穩定時，可以關閉熔斷開關，恢復正常服務。
服務降級：
將系統的所有功能服務進行一個分級，當系統出現問題，需要緊急限流時，可將不是那么重要的功能進行降級處理，停止服務，這樣可以釋放出更多的資源供給核心功能的去用。
例如在電商平臺中，如果突發流量激增，可臨時將商品評論、積分等非核心功能進行降級，停止這些服務，釋放出機器和CPU等資源來保障用戶正常下單，而這些降級的功能服務可以等整個系統恢復正常后，再來啟動，進行補單/補償處理。
除了功能降級以外，還可以采用不直接操作數據庫，而全部讀緩存、寫緩存的方式作為臨時降級方案。
延遲處理：
這個模式需要在系統的前端設置一個流量緩沖池，將所有的請求全部緩沖進這個池子，不立即處理。然后后端真正的業務處理程序從這個池子中取出請求依次處理，常見的可以用隊列模式來實現。這就相當于用異步的方式去減少了后端的處理壓力，但是當流量較大時，后端的處理能力有限，緩沖池里的請求可能處理不及時，會有一定程度延遲。
特權處理：
這個模式需要將用戶進行分類，通過預設的分類，讓系統優先處理需要高保障的用戶群體，其它用戶群的請求就會延遲處理或者直接不處理。

那在實際項目中，對訪問流量的限制，可采用如下幾種技術方法：

熔斷技術
熔斷的技術可以重點參考Netflix的開源組件hystrix的做法，主要有三個模塊：熔斷請求判斷算法、熔斷恢復機制、熔斷報警。

計數器方法
系統維護一個計數器，來一個請求就加1，請求處理完成就減1，當計數器大于指定的閾值，就拒絕新的請求。
基于這個簡單的方法，可以再延伸出一些高級功能，比如閾值可以不是固定值，是動態調整的。另外，還可以有多組計數器分別管理不同的服務，以保證互不影響等。
隊列方法
就是基于FIFO隊列，所有請求都進入隊列，后端程序從隊列中取出待處理的請求依次處理。
基于隊列的方法，也可以延伸出更多的玩法來，比如可以設置多個隊列以配置不同的優先級。
令牌桶方法
首先還是要基于一個隊列，請求放到隊列里面。但除了隊列以外，還要設置一個令牌桶，另外有一個腳本以持續恒定的速度往令牌桶里面放令牌，后端處理程序每處理一個請求就必須從桶里拿出一個令牌，如果令牌拿完了，那就不能處理請求了。我們可以控制腳本放令牌的速度來達到控制后端處理的速度，以實現動態流控。

三、服務限流的注意事項

我們在做服務限流的時候，還是有一些原則和事項需要注意的：

實時監控：系統必須要做好全鏈路的實時監控，才能保證限流的及時檢測和處理。
手動開關：除系統自動限流以外，還需要有能手動控制的開關，以保證隨時都可以人工介入。
限流的性能：限流的功能理論上是會在一定程度影響到業務正常性能的，因此需要做到限流的性能優化和控制。

系統故障常常都是不可預測且難以避免的，因此作為系統設計師的我們，必須要提前預設各種措施，以應對隨時可能的系統風險。

服務熔斷

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

服務熔斷和服務降級比較

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

目的很一致，都是從可用性可靠性著想，為防止系統的整體緩慢甚至崩潰，采用的技術手段；
最終表現類似，對于兩者來說，最終讓用戶體驗到的是某些功能暫時不可達或不可用；
粒度一般都是服務級別，當然，業界也有不少更細粒度的做法，比如做到數據持久層（允許查詢，不允許增刪改）；
自治性要求很高，熔斷模式一般都是服務基于策略的自動觸發，降級雖說可人工干預，但在微服務架構下，完全靠人顯然不可能，開關預置、配置中心都是必要手段；

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

觸發原因不太一樣，服務熔斷一般是某個服務（下游服務）故障引起，而服務降級一般是從整體負荷考慮；
管理目標的層次不太一樣，熔斷其實是一個框架級的處理，每個微服務都需要（無層級之分），而降級一般需要對業務有層級之分（比如降級一般是從最外圍服務開始）
實現方式不太一樣

熔斷器

雪崩效應

在微服務架構中通常會有多個服務層調用，基礎服務的故障可能會導致級聯故障，進而造成整個系統不可用的情況，這種現象被稱為服務雪崩效應。

服務雪崩效應是一種因“服務提供者”的不可用導致“服務消費者”的不可用,并將不可用逐漸放大的過程。

如果下圖所示：A作為服務提供者，B為A的服務消費者，C和D是B的服務消費者。A不可用引起了B的不可用，并將不可用像滾雪球一樣放大到C和D時，雪崩效應就形成了。

熔斷器（CircuitBreaker）

熔斷器的原理很簡單，如同電力過載保護器。它可以實現快速失敗，如果它在一段時間內偵測到許多類似的錯誤，會強迫其以后的多個調用快速失敗，不再訪問遠程服務器，從而防止應用程序不斷地嘗試執行可能會失敗的操作，使得應用程序繼續執行而不用等待修正錯誤，或者浪費CPU時間去等到長時間的超時產生。熔斷器也可以使應用程序能夠診斷錯誤是否已經修正，如果已經修正，應用程序會再次嘗試調用操作。

熔斷器模式就像是那些容易導致錯誤的操作的一種代理。這種代理能夠記錄最近調用發生錯誤的次數，然后決定使用允許操作繼續，或者立即返回錯誤。?

熔斷器開關相互轉換的邏輯如下圖：

熔斷器就是保護服務高可用的最后一道防線。

Hystrix

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

Hystrix特性

1.斷路器機制

斷路器很好理解，當Hystrix Command請求后端服務失敗數量超過一定比例(默認50%)，斷路器會切換到開路狀態(Open)，這時所有請求會直接失敗而不會發送到后端服務，斷路器保持在開路狀態一段時間后(默認5秒)，自動切換到半開路狀態(HALF-OPEN)，這時會判斷下一次請求的返回情況，如果請求成功，斷路器切回閉路狀態(CLOSED)，否則重新切換到開路狀態(OPEN)。Hystrix的斷路器就像我們家庭電路中的保險絲，一旦后端服務不可用，斷路器會直接切斷請求鏈, 避免發送大量無效請求影響系統吞吐量，并且斷路器有自我檢測并恢復的能力。

2.Fallback

Fallback相當于是降級操作，對于查詢操作，我們可以實現一個fallback方法，當請求后端服務出現異常的時候，可以使用fallback方法返回的值，fallback方法的返回值一般是設置的默認值或者來自緩存。

3.資源隔離

在Hystrix中, 主要通過線程池來實現資源隔離，通常在使用的時候我們會根據調用的遠程服務劃分出多個線程池，例如調用產品服務的Command放入A線程池，調用賬戶服務的Command放入B線程池，這樣做的主要優點是運行環境被隔離開了，這樣就算調用服務的代碼存在bug或者由于其他原因導致自己所在線程池被耗盡時, 不會對系統的其他服務造成影響。但是帶來的代價就是維護多個線程池會對系統帶來額外的性能開銷，如果是對性能有嚴格要求而且確信自己調用服務的客戶端代碼不會出問題的話, 可以使用Hystrix的信號模式(Semaphores)來隔離資源。

Hystrix能做什么？

在通過第三方客戶端訪問（通常是通過網絡）依賴服務出現高延遲或者失敗時，為系統提供保護和控制
在分布式系統中防止級聯失敗
快速失敗（Fail fast）同時能快速恢復
提供失敗回退（Fallback）和優雅的服務降級機制
提供近實時的監控、報警和運維控制手段

Hystrix設計原則？

防止單個依賴耗盡容器（例如 Tomcat）內所有用戶線程
降低系統負載，對無法及時處理的請求快速失敗（fail fast）而不是排隊
提供失敗回退，以在必要時讓失效對用戶透明化
使用隔離機制（例如『艙壁』/『泳道』模式，熔斷器模式等）降低依賴服務對整個系統的影響
針對系統服務的度量、監控和報警，提供優化以滿足近實時性的要求
在 Hystrix 絕大部分需要動態調整配置并快速部署到所有應用方面，提供優化以滿足快速恢復的要求
能保護應用不受依賴服務的整個執行過程中失敗的影響，而不僅僅是網絡請求

Hystrix怎樣實現目標？

在一個單獨的線程中通過 HystrixCommand 或 HystrixObservableCommand 對象包裝所有外部系統（或依賴）的調用。
調用超時比設置的閾值更長。雖然有默認值，但是大多數依賴自己配置的這些超時“屬性”，所以每個依賴都略高于實測性能的99.5%。
為每個依賴保持一個小的線程池；如果線程池滿了，新來的請求會立即拒絕掉，而不是排隊等候。
測試成功、失敗（客戶端拋出異常）、超時和線程拒絕。
當請求失敗、被拒、超時或者短路時的性能反饋邏輯。
準實時的監控指標和配置改變。

---------------------
作者：Bolon0708
來源：CSDN
原文：https://blog.csdn.net/l18848956739/article/details/100132409
版權聲明：本文為作者原創文章，轉載請附上博文鏈接！
內容解析By：CSDN,CNBLOG博客文章一鍵轉載插件