07.服务雪崩、熔断与降级

刺骨的言语ヽ痛彻心扉 2022-10-06 00:52 126阅读 0赞

### 服务雪崩、熔断与降级 ###

*   *  前言
     *  服务雪崩
     *   *  概念
         *  原因
     *  服务熔断
     *   *  概念
         *  熔断过程
     *  服务降级
     *   *  概念
     *  服务熔断和降级总结
     *   *  1.共同点
         *  2.不同点
         *  3.总结

## 前言 ##

前面我们已经学习了**Eureka**、**consul**、**Ribbon**与**OpenFeign**，后面我们要学习服务熔断利器**Hystrix**。学习Hystrix之前我们首先要明确三个概念：**服务雪崩**、**服务熔断**、**服务降级**

## 服务雪崩 ##

### 概念 ###

在微服务之间进行服务调用时由于某一个服务故障，导致级联服务故障的现象，称为雪崩效应。雪崩效应描述的是提供方不可用，导致消费方不可用并将不可用逐渐放大的过程。

### 原因 ###

假如存在以下调用链路：ServiceA调用serviceB，serviceB调用ServiceC

![在这里插入图片描述][20210610142645440.png]

ServiceA的流量波动很大，流量经常会突然性增加！那么在这种情况下，就算ServiceA能扛得住请求，ServiceB和ServiceC未必能扛得住这突发的请求。如果此时ServiceC因为抗不住请求，变得不可用。那么Service B的请求也会阻塞，慢慢耗尽ServiceB的线程资源，ServiceB就会变得不可用。紧接着，ServiceA也会不可用

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JieHlscWYxMjZjb20_size_16_color_FFFFFF_t_70]

> 服务雪崩出现的根本原因：在调用链路中某一服务因为执行业务时间过长、或者是大规模出现异常导致自身服务不可用并把这种不可用放大的情况
> 
> 线程资源耗尽是怎么回事呢？我们知道springboot是内嵌tomcat的，tomcat替我们处理请求都是一个个的线程。这个线程的多少不是无上线的而是跟操作系统有关。所以tomcat默认的线程数是150个。当大批量的请求瞬间涌进来，但是服务处理能力跟不上就会耗尽线程资源

## 服务熔断 ##

上面我们说了微服务系统可能存在服务雪崩的现象，那么如何解决呢？接下来我们来看下服务熔断

### 概念 ###

“熔断器”本身是一种开关装置，通过断路器(**Hystrix**)的故障监控，当某个异常条件被触发时直接熔断整个服务。向调用方法返回一个符合预期的、可处理的备选响应(**FallBack**)，而不是长时间的等待或者抛出调用方法无法处理的异常，就保证了服务调用方的线程不会被长时间占用，避免故障在分布式系统中蔓延，乃至雪崩。

如果目标服务情况好转则恢复调用。`服务熔断是解决服务雪崩的重要手段`。

### 熔断过程 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JieHlscWYxMjZjb20_size_16_color_FFFFFF_t_70 1]

所有微服务中必须引入Hystrix组件，上面我们说了Hystrix相当于断路器。我们举一个例子：

现在的房子装修在设计电路的时候我们会将照明，空调或者其他的电器专门使用一个线路，所有的线路最终在入户电路处归为一路；夏天来临后，所有房间的空调同时开启导致空调线路负载过大。于是空调线路的保险开关跳闸，此时我们需要关闭部分空调重新拉起电闸就可以再次开启空调；

那么Hystrix就相当于空调线路保险开关处的保险丝，起到线路保护的作用。当空调线路负载导致跳闸时不至于引起照明和其他电器不可用；同样的其他电器线路的负载过大也不至于导致空调不可用；

上面提到的入户电路就相当于我们的服务注册中心，每一个线路就相当于我们的微服务，每条线路上的开关（保险）就是我们的断路器Hystrix。

> 现在好多人可能不了解以前农村的情况，那个时候每家每户只在入户线路哪里接一个保险开关，这个保险开关控制着家里所有的电器。每当夏季的时候多开几个电器家里就会跳闸，那个时候的跳闸就是保险丝烧了，需要换上新的铜线细丝拧成的保险丝换上去重新推起电闸才可以

## 服务降级 ##

### 概念 ###

服务压力剧增的时候根据当前的业务情况及流量`对一些服务和页面有策略的降级`，以此缓解服务器的压力，以保证核心任务的进行。同时保证部分甚至大部分任务客户能得到正确的响应。也就是当前的请求处理不了了或者出错了，给一个默认的返回。

也就是说：关闭微服务系统中某些边缘服务以保证系统核心服务正常运行

![在这里插入图片描述][20210610142724836.png]

## 服务熔断和降级总结 ##

### 1.共同点 ###

*  目的很一致，都是从可用性可靠性着想，为防止系统的整体缓慢甚至崩溃，采用的技术手段；
 *  最终表现类似，对于两者来说，最终让用户体验到的是某些功能暂时不可达或不可用；
 *  粒度一般都是服务级别，当然，业界也有不少更细粒度的做法，比如做到数据持久层（允许查询，不允许增删改）；
 *  自治性要求很高，熔断模式一般都是服务基于策略的自动触发，降级虽说可人工干预，但在微服务架构下，完全靠人显然不可能，开关预置、配置中心都是必要手段；sentinel

### 2.不同点 ###

*  触发原因不太一样，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；
 *  管理目标的层次不太一样，熔断其实是一个框架级的处理，每个微服务都需要（无层级之分），而降级一般需要对业务有层级之分（比如降级一般是从最外围服务边缘服务开始）

### 3.总结 ###

*  熔断必会触发降级,所以熔断也是降级一种,区别在于熔断是对调用链路的保护,而降级是对系统过载的一种保护处理

[20210610142645440.png]: /images/20221005/8ce7df438ffc485d9044867506f8defd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JieHlscWYxMjZjb20_size_16_color_FFFFFF_t_70]: /images/20221005/305d8996f3e04dc0a3aa058d69cc8151.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JieHlscWYxMjZjb20_size_16_color_FFFFFF_t_70 1]: /images/20221005/52002d3e6a494bb3a96806da77fe2e78.png
[20210610142724836.png]: /images/20221005/b669a9d9616b435590eaa32cc938dcda.png