腳本之家服務器常用軟件

快捷導航

springcloud 服務降級的實現(xiàn)方法

更新時間：2020年12月03日 09:29:59 作者：ywl470812087

這篇文章主要介紹了springcloud 服務降級的實現(xiàn)方法,本文給大家介紹的非常詳細，對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下

1 、簡介

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

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

2 、使用場景

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

3 、核心設計

3.1 分布式開關

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

640?wx_fmt=png

超時降級 —— 主要配置好超時時間和超時重試次數(shù)和機制，并使用異步機制探測恢復情況

失敗次數(shù)降級 —— 主要是一些不穩(wěn)定的API，當失敗調(diào)用次數(shù)達到一定閥值自動降級，同樣要使用異步機制探測回復情況

故障降級 —— 如要調(diào)用的遠程服務掛掉了（網(wǎng)絡故障、DNS故障、HTTP服務返回錯誤的狀態(tài)碼和RPC服務拋出異常），則可以直接降級

限流降級 —— 當觸發(fā)了限流超額時，可以使用暫時屏蔽的方式來進行短暫的屏蔽

當我們?nèi)ッ霘⒒蛘邠屬徱恍┫拶徤唐窌r，此時可能會因為訪問量太大而導致系統(tǒng)崩潰，此時開發(fā)者會使用限流來進行限制訪問量，當達到限流閥值，后續(xù)請求會被降級；降級后的處理方案可以是：排隊頁面（將用戶導流到排隊頁面等一會重試）、無貨（直接告知用戶沒貨了）、錯誤頁（如活動太火爆了，稍后重試）。

3.3 配置中心

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

640?wx_fmt=png

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

提供Telnet命令變更配置 —— 用于解決配置中心失效而不能變更配置的常見

3.4 處理策略

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

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

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

拋異常
返回NULL
調(diào)用Mock數(shù)據(jù)
調(diào)用Fallback處理邏輯

4 、高級特性

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

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

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

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

4.1 分級降級

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

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

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

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

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

評估模型：

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

設計說明：

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

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

4.2 降級權值

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

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

5 、總結與展望

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

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

下面舉個簡單大代碼示例：

640?wx_fmt=png

/**
 * @Description: 修改microservicecloud-api工程，根據(jù)已經(jīng)有的DeptClientService接口
新建
一個實現(xiàn)了FallbackFactory接口的類DeptClientServiceFallbackFactory
 * @author zzyy
 * @date 2020年2月17日
 */

這里我們那get方法舉一個例子

package com.atguigu.springcloud.service;
import com.atguigu.springcloud.entities.Dept;
import feign.hystrix.FallbackFactory;
import java.util.List;
 
/**
 * @Description: 修改microservicecloud-api工程，根據(jù)已經(jīng)有的DeptClientService接口
新建
一個實現(xiàn)了FallbackFactory接口的類DeptClientServiceFallbackFactory
 * @author zzyy
 * @date 2018年4月21日
 */
public class DeptClientServiceFallbackFactory implements FallbackFactory<DeptClientService> {
 
 @Override
 public DeptClientService create(Throwable throwable) {
 return new DeptClientService(){
  @Override
  public Dept get(long id) {
  return new Dept().setDeptno(id).setDname("該ID：" + id + "沒有沒有對應的信息,Consumer客戶端提供的降級信息,此刻服務Provider已經(jīng)關閉")
   .setDb_source("no this database in MySQL");
  }
  @Override
  public List<Dept> list() {
  return null;
  }
  @Override
  public boolean add(Dept dept) {
  return false;
  }
 };
 }
}

最后注意不能忘記在類DeptClientServiceFallbackFactory加上注解@Component

修改完成之后我們還需要講Api重新編譯打包 rebuild module "microservicecloud-api"

修改microservicecloud-consumer-dept-feign的yml文件

server:
 port: 80
 
 
eureka:
 client:
 register-with-eureka: false
 service-url:
 #defaultZone: http://localhost:7001/eureka/ #單機版
 defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/

SpringAop思想加入(服務降級)：