1 、簡(jiǎn)介

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

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

2 、使用場(chǎng)景

服務(wù)降級(jí)主要用于什么場(chǎng)景呢？當(dāng)整個(gè)微服務(wù)架構(gòu)整體的負(fù)載超出了預(yù)設(shè)的上限閾值或即將到來(lái)的流量預(yù)計(jì)將會(huì)超過(guò)預(yù)設(shè)的閾值時(shí)，為了保證重要或基本的服務(wù)能正常運(yùn)行，我們可以將一些 不重要 或 不緊急 的服務(wù)或任務(wù)進(jìn)行服務(wù)的 延遲使用 或 暫停使用。

3 、核心設(shè)計(jì)

3.1 分布式開(kāi)關(guān)

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

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

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

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

限流降級(jí) —— 當(dāng)觸發(fā)了限流超額時(shí)，可以使用暫時(shí)屏蔽的方式來(lái)進(jìn)行短暫的屏蔽

當(dāng)我們?nèi)ッ霘⒒蛘邠屬?gòu)一些限購(gòu)商品時(shí)，此時(shí)可能會(huì)因?yàn)樵L(fǎng)問(wèn)量太大而導(dǎo)致系統(tǒng)崩潰，此時(shí)開(kāi)發(fā)者會(huì)使用限流來(lái)進(jìn)行限制訪(fǎng)問(wèn)量，當(dāng)達(dá)到限流閥值，后續(xù)請(qǐng)求會(huì)被降級(jí)；降級(jí)后的處理方案可以是：排隊(duì)頁(yè)面（將用戶(hù)導(dǎo)流到排隊(duì)頁(yè)面等一會(huì)重試）、無(wú)貨（直接告知用戶(hù)沒(méi)貨了）、錯(cuò)誤頁(yè)（如活動(dòng)太火爆了，稍后重試）。

3.3 配置中心

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

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

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

3.4 處理策略

當(dāng)觸發(fā)服務(wù)降級(jí)后，新的交易再次到達(dá)時(shí)，我們?cè)撊绾蝸?lái)處理這些請(qǐng)求呢？從微服務(wù)架構(gòu)全局的視角來(lái)看，我們通常有以下是幾種常用的降級(jí)處理方案：

• 頁(yè)面降級(jí) —— 可視化界面禁用點(diǎn)擊按鈕、調(diào)整靜態(tài)頁(yè)面
• 延遲服務(wù) —— 如定時(shí)任務(wù)延遲處理、消息入MQ后延遲處理
• 寫(xiě)降級(jí) —— 直接禁止相關(guān)寫(xiě)操作的服務(wù)請(qǐng)求
• 讀降級(jí) —— 直接禁止相關(guān)度的服務(wù)請(qǐng)求
• 緩存降級(jí) —— 使用緩存方式來(lái)降級(jí)部分讀頻繁的服務(wù)接口

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

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

4 、高級(jí)特性

我們已經(jīng)為每個(gè)服務(wù)都做好了一個(gè)降級(jí)開(kāi)關(guān)，也已經(jīng)在線(xiàn)上驗(yàn)證通過(guò)了，感覺(jué)完全沒(méi)問(wèn)題了。

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

 場(chǎng)景二：某一天，運(yùn)營(yíng)又搞事了，說(shuō)我們等下要搞一個(gè)活動(dòng)，讓我們趕緊提前把不重要的服務(wù)都降級(jí)了，開(kāi)發(fā)又是一臉懵逼，我怎么知道要降級(jí)哪些服務(wù)呀。

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

4.1 分級(jí)降級(jí)

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

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

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

以下是個(gè)人給出的最終評(píng)價(jià)模型，可作為服務(wù)降級(jí)的評(píng)價(jià)參考模型進(jìn)行設(shè)計(jì)：

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

評(píng)估模型：

• 藍(lán)色風(fēng)暴 —— 表示需要小規(guī)模降級(jí)非核心服務(wù)
• 黃色風(fēng)暴 —— 表示需要中等規(guī)模降級(jí)非核心服務(wù)
• 橙色風(fēng)暴 —— 表示需要大規(guī)模降級(jí)非核心服務(wù)
• 紅色風(fēng)暴 —— 表示必須降級(jí)所有非核心服務(wù)

設(shè)計(jì)說(shuō)明：

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

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

4.2 降級(jí)權(quán)值

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

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

5 、總結(jié)與展望

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

本文主要以服務(wù)降級(jí)為核心進(jìn)行更加理想的治理微服務(wù)架構(gòu)，其中建議運(yùn)用數(shù)學(xué)領(lǐng)域的適當(dāng)模型來(lái)實(shí)現(xiàn) 定性 和 定量 的合理分析和治理微服務(wù)，為未來(lái) 人工智能治理微服務(wù)（Artificial Intelligence Governance Micro Service，簡(jiǎn)稱(chēng)AIGMS）提供方案支持。

 下面舉個(gè)簡(jiǎn)單大代碼示例：

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

這里我們那get方法舉一個(gè)例子

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接口
新建
一個(gè)實(shí)現(xiàn)了FallbackFactory接口的類(lèi)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 + "沒(méi)有沒(méi)有對(duì)應(yīng)的信息,Consumer客戶(hù)端提供的降級(jí)信息,此刻服務(wù)Provider已經(jīng)關(guān)閉")
   .setDb_source("no this database in MySQL");
  }
  @Override
  public List<Dept> list() {
  return null;
  }
  @Override
  public boolean add(Dept dept) {
  return false;
  }
 };
 }
}

 最后注意不能忘記在類(lèi)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/ #單機(jī)版
 defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/

SpringAop思想加入(服務(wù)降級(jí))：

重新啟動(dòng)正常訪(fǎng)問(wèn)

降服務(wù)提供者（microservicecloud-provider-dept-8001）關(guān)閉

由返回可知服務(wù)起到了降級(jí)作用

重新啟動(dòng)微服務(wù)再次正常

到此這篇關(guān)于springcloud 服務(wù)降級(jí)的實(shí)現(xiàn)方法的文章就介紹到這了,更多相關(guān)springcloud 服務(wù)降級(jí)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論