降级熔断：如何屏蔽非核心系统故障的影响？

た入场券 2024-02-20 09:28 27阅读 0赞

##  ##

**目录**

前言

一、熔断是什么？

二、服务降级

三、雪崩是如何发生的

四、hystrix使用

五、降级机制要如何做

总结

--------------------

## 前言 ##

在“双十一”的巨大流量中，商品促销过程中出现了几次短暂的服务不可用，这给部分用户造成了不好的使用体验。事后，你们进行了细致的复盘，追查出现故障的根本原因，你发现，原因主要可以归结为两大类。

第一类原因是由于依赖的资源或者服务不可用，最终导致整体服务宕机。举例来说，在你的电商系统中就可能由于数据库访问缓慢，导致整体服务不可用。

另一类原因是你们乐观地预估了可能到来的流量，当有超过系统承载能力的流量到来时，系统不堪重负，从而出现拒绝服务的情况。

那么，你要如何避免再次出现这两类问题呢？我建议你采取降级、熔断以及限流的方案。今天这节课，我主要讲一下解决第一类问题的思路：降级和熔断。

限流、熔断和降级都是系统容错的重要设计模式。

--------------------

## **一、****熔断****是什么？** ##

是在流量过大时（或下游服务出现问题时），可以自动断开与下游服务的交互，并可以通过自我诊断下游系统的错误是否已经修正，或上游流量是否减少至正常水平，来自我恢复。熔断更像是自动化补救手段，可能发生在服务无法支撑大量请求或服务发生其他故障时，对请求进行限制处理，同时还可尝试性的进行恢复。

## 二、**服务降级** ##

### `` ###

主要是针对非核心业务功能，而核心业务如果流程超过预估的峰值，就需要进行限流。降级一般考虑的是分布式系统的整体性，从源头上切断流量的来源。降级更像是预估手段，在预计流量峰值前提下，提前通过配置功能降低服务体验，或暂停次要功能，保证系统主要流程功能平稳响应。

## 三、**雪崩是如何发生的** ##

局部故障最终会导致全局故障，这种情况有一个专业的名词儿，叫做“雪崩”。那么，为什么会发生雪崩呢？我们知道，系统在运行的时候是需要消耗一些资源的，包括 CPU、内存等系统资源，也包括执行业务逻辑的时候，需要的线程资源。

举个例子，一般在业务执行的容器内，都会定义一些线程池来分配执行任务的线程，比如在Tomcat 这种 Web 容器的内部，定义了线程池来处理 HTTP 请求；RPC 框架也给 RPC 服务端初始化了线程池来处理 RPC 请求。

这些线程池中的线程资源是有限的，如果这些线程资源被耗尽，那么服务自然也就无法处理新的请求，服务提供方也就宕机了。比如，你的垂直电商系统有四个服务 聚合服务A、商品服务B、促销服务C、评论服务D，A调用 B，B 调用 C 和 D。其中，聚合服务A、商品服务B、促销服务C是系统的核心服务，论服务D 是非核心服务。

所以，一旦作为入口的 A 流量增加，你可能会考虑把 A、B 和 C 服务扩容，忽略 D。那么D 就有可能因为无法承担这么大的流量，导致请求处理缓慢，进一步会让 B 在调用 D 的时候，B 中的请求被阻塞，等待 D 返回响应结果。这样一来，B 服务中被占用的线程资源就不能释放。

久而久之，B 就会因为线程资源被占满，无法处理后续的请求。那么从 A 发往 B 的请求，就会被放入 B 服务线程池的队列中，然后 A 调用 B 响应时间变长，进而拖垮 A 服务。你看，仅仅因为非核心服务 D 的响应时间变长，就可以导致整体服务宕机，这就是我们经常遇到的一种服务雪崩情况。

![87d4e902932d4a928c93dc6222c2ff63.png][]

那么我们要如何避免出现上面这种情况呢？从我刚刚的介绍中你可以看到，因为服务调用方等待服务提供方的响应时间过长，它的资源被耗尽，才引发了级联反应，发生雪崩。所以在分布式环境下，系统最怕的反而不是某一个服务或者组件宕机，而是最怕它响应缓慢，因为，某一个服务或者组件宕机也许只会影响系统的部分功能，但它响应一慢，就会出现雪崩拖垮整个系统。

评论服务D做为服务提供者(基础服务)，商品服务B为评论服务D的消费者，聚合服务A为是商品服务B的消费者。当D不可用引起了B不可用，并将不可用像滚雪球一样放大到A，雪崩效应就这样形成。

而我们在部门内部讨论方案的时候，会格外注意这个问题，解决的思路就是在检测到某一个服务的响应时间出现异常时，切断调用它的服务与它之间的联系，让服务的调用快速返回失败，从而释放这次请求持有的资源。这个思路也就是我们经常提到的降级和熔断机制。那么降级和熔断分别是怎么做的呢？它们之间有什么相同点和不同点呢？你在自己的项目中要如何实现熔断降级呢？

## 四、**雪崩的解决方案** ##

解决雪崩效应的方案：使用服务的隔离机制(线程池方式和信号量方式)。

服务隔离：每个服务接口之间互不影响，服务隔离有2种实现方式，线程池方式、信号量。

1.线程池方式：相当于每个接口(服务)都有自己独立的线程池，不同的线程池之间互不影响，能够实现服务接口隔离。缺点：CPU内存开销较大。

2.信号量方式：底层使用原子计数器(atomic)，针对于每个服务都设置自己的独立的限制阈值。比如设置每个服务接口最多同时访问的次数，如果超出缓存队列请求后，自己实现拒绝策略。

服务熔断：在高并发的情况下，如果达到一定的极限(可以自己设置阈值),如果流量超出了设置的阈值，然后拒绝访问，保护当前服务。当服务器达到最大的承受能力的之后，直接拒绝访问服务，然后调用降级方法，返回友好提示。

目的：为了防止服务宕机(保护服务)，会进行熔断处理。

产生的原因：服务请求过多，高并发情况下。可以设置阈值进行限制。超出的请求存放在缓存队列中，如果缓存队列中线程满的话，直接拒绝访问服务，访问不了服务(熔断)。

## 五、Hystrix简介 ##

> Spring Cloud Hystrix是一款优秀的服务容错和保护组件，也是Spring Cloud的重要组件之一。
> 
>     Spring Cloud Hystrix是基于Netfilx公司的开源组件Hystrix实现的。提供熔断器功能，能够有效阻止分布式服务系统中出现联动故障，以提高微服务系统的弹性。Spring Cloud Hystrix具有服务降级，服务熔断，线程隔离，请求缓存，请求合并以及实时故障监控等强大功能。

### Hystrix能做什么 ###

*  保护线程资源:防止单个服务的故障耗尽系统中所有的线程资源。
 *  快速失败机制:当某个服务发生了故障，不让服务调用方一直等待，而直接返回一个可预期的，可处理的降级响应。
 *  提供降级(FallBack)方案:在请求失败后，提供一个设计好的降级方案，当请求失败后调用此方法。
 *  防止故障扩散:使用熔断机制，防止故障扩散到其他服务。
 *  提供熔断器故障监控组件Hystrix Dashboard,随时监控熔断器的状态。

### Hystrix服务熔断 ###

熔断机制是为了应对雪崩效应而出现一种微服务链路保护机制。

当微服务系统的某个微服务不可用或响应时间太长时，为了保护系统的服务整体可用性，熔断器会暂时切断对该服务的请求调用，并快速返回一个友好的错误响应信息。这种熔断状态不是永久的，在经历了一定时间后，熔断器会再次检测该微服务是否恢复正常，若恢复正常则恢复调用链路。  
![422b7955f3fa49bd9b307486ab679ed8.png][]

*  熔断关闭状态（Closed）：当服务访问正常时，熔断器处于关闭状态，服务调用方可以正常地对服务进行调用。
 *  熔断开启状态（Open）：默认情况下，在固定时间内接口调用出错比率达到一个阈值（例如 50%），熔断器会进入熔断开启状态。进入熔断状态后，后续对该服务的调用都会被切断，熔断器会执行本地的降级（FallBack）方法。
 *  半熔断状态（Half-Open）： 在熔断开启一段时间之后，熔断器会进入半熔断状态。在半熔断状态下，熔断器会尝试恢复服务调用方对服务的调用，允许部分请求调用该服务，并监控其调用成功率。如果成功率达到预期，则说明服务已恢复正常，熔断器进入关闭状态；如果成功率仍旧很低，则重新进入熔断开启状态。

### Hystrix实现熔断机制 ###

在SpringCloud中，熔断机制是通过Hystrix实现的。Hystrix会监控微服务间调用的情况，当失败调用达到一定比例时(例如5秒内失败20次)，就会启动熔断机制。

1.  当服务的调用出错率达到后超过Hystirx规定的出错比率(默认为50%)，熔断器进入熔断开启状态。
2.  熔断器进入熔断开启状态后，Hystrix会启动一个休眠时间窗，在这个时间窗内，该服务的降级逻辑会临时充当业务主逻辑，而原来的业务主逻辑不可用。
3.  当有请求再次调用该服务时，会直接调用降级逻辑快递返回失败效应，以避免系统雪崩。
4.  当休眠时间窗到期后，Hystrix会进入半熔断状态，允许部分请求对由原来的业务主逻辑进行调用，并监控其成功率。
5.  如果调用成功率达到预期，说明服务恢复正常，Hystrix进入熔断关闭状态，服务原来的业务逻辑恢复。否则Hystrix将进入熔断开启状态，休眠时间窗口重新计时。

### Hystrix熔断实现 ###

在pom.xml导入Hystrix依赖

<dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-web</artifactId>
                <version>2.7.12</version>
            </dependency>

WebApplication 启动类 开启Hystrix

@EnableHystrix
    @SpringBootApplication
    public class WebApplication {
    
        public static void main(String[] args) {
            SpringApplication.run(WebApplication.class, args);
        }
    }

### HystrixProperty配置 ###

<table style="width:700px;"> 
 <tbody> 
  <tr> 
   <td>参数</td> 
   <td>描述</td> 
  </tr> 
  <tr> 
   <td>execution.isolation.thread.timeoutInMilliseconds</td> 
   <td>为请求方法设置超时时间，若请求超时则触发全局的回退方法进行处理。可以用在某个特定的服务请求中</td> 
  </tr> 
  <tr> 
   <td>metrics.rollingStats.timeInMilliseconds</td> 
   <td>统计时间窗</td> 
  </tr> 
  <tr> 
   <td>circuitBreaker.sleepWindowInMilliseconds</td> 
   <td>休眠时间窗，熔断开启状态持续一段时间后，熔断器会自动进入半熔断状态，这段时间就被称为休眠窗口期。</td> 
  </tr> 
  <tr> 
   <td>circuitBreaker.requestVolumeThreshold</td> 
   <td>请求总数阀值。在统计时间窗内，请求总数必须到达一定的数量级，Hystrix 才可能会将熔断器打开进入熔断开启转态，而这个请求数量级就是 请求总数阀值。Hystrix 请求总数阈值默认为 20，这就意味着在统计时间窗内，如果服务调用次数不足 20 次，即使所有的请求都调用出错，熔断器也不会打开。</td> 
  </tr> 
  <tr> 
   <td>circuitBreaker.errorThresholdPercentage</td> 
   <td>错误百分比阈值。当请求总数在统计时间窗内超过了请求总数阀值，且请求调用出错率超过一定的比例，熔断器才会打开进入熔断开启转态，而这个比例就是错误百分比阈值。错误百分比阈值设置为 50，就表示错误百分比为 50%，如果服务发生了 30 次调用，其中有 15 次发生了错误，即超过了 50% 的错误百分比，这时候将熔断器就会打开。</td> 
  </tr> 
 </tbody> 
</table>

HystrixController 代码

@EnableCircuitBreaker
    @RestController
    public class HystrixController {
    
        @HystrixCommand(fallbackMethod = "fallback", commandProperties =
                {
    
                        @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "100"),//指定多久超时，单位毫秒。超时进fallback
                        @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"),//判断熔断的最少请求数，默认是10；只有在一个统计窗口内处理的请求数量达到这个阈值，才会进行熔断与否的判断
                        @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "10"),//判断熔断的阈值，默认值50，表示在一个统计窗口内有50%的请求处理失败，会触发熔断
                })
        @RequestMapping("/test/{id}")
        public String test(@PathVariable("id") Integer id) throws Exception {
            Thread.sleep(1000);
            return "ok";
        }
    
        public String fallback(@PathVariable("id") Integer id) {
            return "fallback";
        }
    }

启动测试

![35d73f61ee5e45d2972316b776a27f82.png][]

## 六、降级机制要如何做 ##

除了熔断之外，我们在听业内分享的时候，听到最多的服务容错方式就是降级，那么降级又是怎么做的呢？它和熔断有什么关系呢？其实在我看来，相比熔断来说，降级是一个更大的概念。因为它是站在整体系统负载的角度上，放弃部分非核心功能或者服务，保证整体的可用性的方法，是一种有损的系统容错方式。这样看来，熔断也是降级的一种，除此之外还有限流降级、开关降级等等（限流降级我会在下一节课中提到，这节课主要讲一下开关降级）。

开关降级指的是在代码中预先埋设一些“开关”，用来控制服务调用的返回值。比方说，开关关闭的时候正常调用远程服务，开关打开时则执行降级的策略。这些开关的值可以存储在配置中心中，当系统出现问题需要降级时，只需要通过配置中心动态更改开关的值，就可以实现不重启服务快速地降级远程服务了。还是以电商系统为例，你的电商系统在商品详情页面除了展示商品数据以外，还需要展示评论的数据，但是主体还是商品数据，在必要时可以降级评论数据。所以，你可以定义这个开关为“degrade.comment”，写入到配置中心中，具体的代码也比较简单，就像下面这样：

boolean switcherValue = getFromConfigCenter("degrade.comment"); // 从配置中心获取
     if (!switcherValue) { 
    	List<Comment> comments = getCommentList(); // 开关关闭则获取评论数据
     } else {  
    	List<Comment> comments = new ArrayList(); // 开关打开，则直接返回空评论数据
     }

当然了，我们在设计开关降级预案的时候，首先要区分哪些是核心服务，哪些是非核心服务。因为我们只能针对非核心服务来做降级处理，然后就可以针对具体的业务，制定不同的降级策略了。我给你列举一些常见场景下的降级策略，你在实际的工作中可以参考借鉴。针对读取数据的场景，我们一般采用的策略是直接返回降级数据。比如，如果数据库的压力比较大，我们在降级的时候，可以考虑只读取缓存的数据，而不再读取数据库中的数据；如果非核心接口出现问题，可以直接返回服务繁忙或者返回固定的降级数据。对于一些轮询查询数据的场景，比如每隔 30 秒轮询获取未读数，可以降低获取数据的频率（将获取频率下降到 10 分钟一次）。

而对于写数据的场景，一般会考虑把同步写转换成异步写，这样可以牺牲一些数据一致性和实效性来保证系统的可用性。

[87d4e902932d4a928c93dc6222c2ff63.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/ba4a26fa070a4715a39074f3425d160c.png
[422b7955f3fa49bd9b307486ab679ed8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/32527415b21a4efea3727d5e843e6c00.png
[35d73f61ee5e45d2972316b776a27f82.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/20/a1397a6df65949b9a54874e521798040.png