5、Hystrix服務熔斷（服務端）與服務降級（客戶端）

Hystrix服務熔斷：

1、服務雪崩

​ 　　多個微服務之間調用的時候，假設微服務A調用微服務B和微服務C，微服務B和微服務C又調用其他的微服務，這就是所謂的“扇出”。

如果扇出的鏈路上某個微服務的調用響應時間過長，或者不可用，對微服務A的調用就會占用越來越多的系統資源，進而引起系統崩潰，所謂的“雪崩效應”。

 

 

　　 對於高流量的應用來說，單一的后端依賴可能會導致所有服務器上的所有資源都在幾十秒內飽和。

比失敗更糟糕的是，這些應用程序還可能導致服務之間的延遲增加，備份隊列，線程和其他系統資源緊張，導致整個系統發生更多的級聯故障。

這些都表示需要對故障和延遲進行隔離和管理，以達到單個依賴關系的失敗而不影響整個應用程序或系統運行

2、什么是Hystrix？

​ 　　Hystrix是一個應用於處理分布式系統的延遲和容錯的開源庫，在分布式系統里，許多依賴不可避免的會調用失敗，比如超時，異常等，

　　Hystrix 能夠保證在一個依賴出問題的情況下，不會導致整個體系服務失敗，避免級聯故障，以提高分布式系統的彈性。

​ “斷路器”本身是一種開關裝置，當某個服務單元發生故障之后，通過斷路器的故障監控 (類似熔斷保險絲) ，向調用方返回一個服務預期的，可處理的備選響應 (FallBack) ，而不是長時間的等待或者拋出調用方法無法處理的異常，這樣就可以保證了服務調用方的線程不會被長時間，不必要的占用，從而避免了故障在分布式系統中的蔓延，乃至雪崩。

3、Hystrix的作用

• 服務降級
• 服務熔斷
• 服務限流
• 接近實時的監控
• …

當一切正常時，請求流可以如下所示：

當許多后端系統中有一個潛在阻塞服務時，它可以阻止整個用戶請求：

隨着大容量通信量的增加，單個后端依賴項的潛在性會導致所有服務器上的所有資源在幾秒鍾內飽和。

應用程序中通過網絡或客戶端庫可能導致網絡請求的每個點都是潛在故障的來源。比失敗更糟糕的是，這些應用程序還可能導致服務之間的延遲增加，從而備份隊列、線程和其他系統資源，從而導致更多跨系統的級聯故障。

當使用Hystrix包裝每個基礎依賴項時，上面的圖表中所示的體系結構會發生類似於以下關系圖的變化。每個依賴項是相互隔離的，限制在延遲發生時它可以填充的資源中，並包含在回退邏輯中，該邏輯決定在依賴項中發生任何類型的故障時要做出什么樣的響應：

官網資料：https://github.com/Netflix/Hystrix/wiki

4、Hystrix簡單實現

1、新建服務創建模塊

創建springcloud-provider-dept-8001-hystrix模塊，只需要將springcloud-provider-dept-8001代碼全部拷貝過來即可~

2、導入依賴

<!--Hystrix熔斷依賴-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-hystrix</artifactId>
    <version>1.4.6.RELEASE</version>
</dependency>

 

3、編寫業務方法

controller/DeptController:

@RestController
public class DeptController {
    @Autowired
    DeptService service;
    // 添加熔斷的后備方法
    @HystrixCommand(fallbackMethod = "hystrixGetDeptById")
    @GetMapping("/dept/query/{id}")
    public Dept getDeptById(@PathVariable("id") Long id) {
        Dept dept = service.queryDeptById(id);
        if (dept == null) {
            throw new RuntimeException("id->" + id + "不存在，或者信息無法找到~");
        }
        return dept;
    }
    // 備選方法
    public Dept hystrixGetDeptById(@PathVariable("id") Long id) {
        return new Dept()
                .setDno(id)
                .setDname("沒有對應的信息！")
                .setDb_source("無法在數據庫中找到");
    }
}

 

4、啟動熔斷器

開啟注冊中心：7001、

開啟服務創建：springcloud-provider-dept-8001-hystrix

開啟客戶端：springcloud-provider-dept-80

訪問:

而不適用熔斷的springcloud-provider-dept–8001模塊訪問相同地址會出現下面狀況:

因此，為了避免因某個微服務后台出現異常或錯誤而導致整個應用或網頁報錯，使用熔斷是必要的

服務降級

什么是服務降級?

​ 服務降級是指 當服務器壓力劇增的情況下，根據實際業務情況及流量，對一些服務和頁面有策略的不處理，或換種簡單的方式處理，從而釋放服務器資源以保證核心業務正常運作或高效運作。說白了，就是盡可能的把系統資源讓給優先級高的服務。

資源有限，而請求是無限的。如果在並發高峰期，不做服務降級處理，一方面肯定會影響整體服務的性能，嚴重的話可能會導致宕機某些重要的服務不可用。所以，一般在高峰期，為了保證核心功能服務的可用性，都要對某些服務降級處理。比如當雙11活動時，把交易無關的服務統統降級，如查看螞蟻深林，查看歷史訂單等等。

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

降級的方式可以根據業務來，可以延遲服務，比如延遲給用戶增加積分，只是放到一個緩存中，等服務平穩之后再執行 ；或者在粒度范圍內關閉服務，比如關閉相關文章的推薦。

由上圖可得，當某一時間內服務A的訪問量暴增，而B和C的訪問量較少，為了緩解A服務的壓力，這時候需要B和C暫時關閉一些服務功能，去承擔A的部分服務，從而為A分擔壓力，叫做服務降級。

服務降級需要考慮的問題

• 1）那些服務是核心服務，哪些服務是非核心服務
• 2）那些服務可以支持降級，那些服務不能支持降級，降級策略是什么
• 3）除服務降級之外是否存在更復雜的業務放通場景，策略是什么？

自動降級分類

1）超時降級：主要配置好超時時間和超時重試次數和機制，並使用異步機制探測回復情況

2）失敗次數降級：主要是一些不穩定的api，當失敗調用次數達到一定閥值自動降級，同樣要使用異步機制探測回復情況

3）故障降級：比如要調用的遠程服務掛掉了（網絡故障、DNS故障、http服務返回錯誤的狀態碼、rpc服務拋出異常），則可以直接降級。降級后的處理方案有：默認值（比如庫存服務掛了，返回默認現貨）、兜底數據（比如廣告掛了，返回提前准備好的一些靜態頁面）、緩存（之前暫存的一些緩存數據）

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

入門案例

在springcloud-api模塊下的service包中新建降級配置類DeptClientServiceFallBackFactory.java

/**
 * @Auther: csp1999
 * @Date: 2020/05/20/9:18
 * @Description: Hystrix服務降級 ~
 */
@Component
public class DeptClientServiceFallBackFactory implements FallbackFactory {

    @Override
    public DeptClientService create(Throwable cause) {
        return new DeptClientService() {
            @Override
            public Dept queryById(Long id) {
                return new Dept()
                        .setDeptno(id)
                        .setDname("id=>" + id + "沒有對應的信息，客戶端提供了降級的信息，這個服務現在已經被關閉")
                        .setDb_source("沒有數據~");
            }
            @Override
            public List<Dept> queryAll() {
                return null;
            }

            @Override
            public Boolean addDept(Dept dept) {
                return false;
            }
        };
    }
}

在DeptClientService中指定降級配置類DeptClientServiceFallBackFactory

@Component //注冊到spring容器中
//@FeignClient:微服務客戶端注解,value:指定微服務的名字,這樣就可以使Feign客戶端直接找到對應的微服務
@FeignClient(value = "SPRINGCLOUD-PROVIDER-DEPT",fallbackFactory = DeptClientServiceFallBackFactory.class)//fallbackFactory指定降級配置類
public interface DeptClientService {

    @GetMapping("/dept/get/{id}")
    public Dept queryById(@PathVariable("id") Long id);

    @GetMapping("/dept/list")
    public List<Dept> queryAll();

    @GetMapping("/dept/add")
    public Boolean addDept(Dept dept);
}

在springcloud-consumer-dept-feign模塊中開啟降級：

server:
  port: 80

# Eureka配置
eureka:
  client:
    register-with-eureka: false # 不向 Eureka注冊自己
    service-url: # 從三個注冊中心中隨機取一個去訪問
      defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/

# 開啟降級feign.hystrix
feign:
  hystrix:
    enabled: true

服務熔斷和降級的區別

• 服務熔斷—>服務端：某個服務超時或異常，引起熔斷~，類似於保險絲(自我熔斷)
• 服務降級—>客戶端：從整體網站請求負載考慮，當某個服務熔斷或者關閉之后，服務將不再被調用，此時在客戶端，我們可以准備一個 FallBackFactory ，返回一個默認的值(缺省值)。會導致整體的服務下降，但是好歹能用，比直接掛掉強。
• 觸發原因不太一樣，服務熔斷一般是某個服務（下游服務）故障引起，而服務降級一般是從整體負荷考慮；管理目標的層次不太一樣，熔斷其實是一個框架級的處理，每個微服務都需要（無層級之分），而降級一般需要對業務有層級之分（比如降級一般是從最外圍服務開始）
• 實現方式不太一樣，服務降級具有代碼侵入性(由控制器完成/或自動降級)，熔斷一般稱為自我熔斷。

熔斷，降級，限流：

限流：限制並發的請求訪問量，超過閾值則拒絕；

降級：服務分優先級，犧牲非核心服務（不可用），保證核心服務穩定；從整體負荷考慮；

熔斷：依賴的下游服務故障觸發熔斷，避免引發本系統崩潰；系統自動執行和恢復