Spring Cloud - 熔断(Hystrix)

2023-12-22 10:38:50
熔断

小铭同学最近正在学Spring Cloud,最近学到熔断这块的知识点,不是很理解,于是请教了公司的大佬老王。

小铭趁空闲时间找到老王:“王哥,我最近在学习Spring Cloud,看到所有书上都说熔断是微服务必须的,可我不用熔断,系统好像也能正常工作。那为什么说它是必须的呢?”

“正常工作是没问题,那发生异常了呢?某个服务挂了或者网络不通的时候会发生什么?”老王反问小铭。

“让我思考一下,如果一个微服务不可用了,那调用它的微服务这个服务就会抛异常,一直到最上层。可这跟熔断又有什么关系?”小铭心中还是有一些疑惑。

老王笑了笑,解释道:“可不只是抛异常怎么简单。在Java中,每一个HTTP请求都会开启一个新线程。而下游服务挂了或者网络不可达,通常线程会阻塞住,直到Timeout。你想想看,如果并发量多一点,这些阻塞的线程就会占用大量的资源,很有可能把自己本身这个微服务所在的机器资源耗尽,导致自己也挂掉。”

小铭有些明白了,追问道:“那是不是最终所有上游微服务都有可能挂掉?”

“是的,这也是称为‘雪崩效应’。最开始是一个微服务挂掉了。随着时间地推移,可能会导致整个系统都不可用。”老王一边回答,一边快速地在电脑上搜出了下面这个图:
在这里插入图片描述
“那熔断具体是怎么解决这个问题的?”小铭点点头,然后继续追问。

老王见小铭似乎有些明悟,但知识点还没有串联起来,便一步一步地引导他:“那你知道Spring Cloud断路器的三种状态吗?”

似乎终于到了小铭自己比较熟悉的知识点,自信地说到:“这个我知道,Spring Cloud一般使用Hystrix来做断路器。就跟电路上的闸差不多。它有三种状态:关闭,开启和半开。最开始是关闭状态的,这个时候所有请求都可以通过;如果错误请求达到一定的阈值,就会变成开启状态,就会让所有请求短路,直接返回失败的响应;一段时间后,断路器会变成半开状态,如果下一个请求成功了,就关闭断路器,反之就开启断路器。”

“那这个阈值具体是什么?”

“这里主要就要用到三个属性了:”小铭快速答道

  1. hystrix.command.default.circuitBreaker.requestVolumeThreshold(当在配置时间窗口内达到此数量的失败后,进行短路。默认20个)简言之,10s内请求失败数量达到20个,断路器就会变成打开状态。
  2. hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds(短路多久以后开始尝试是否恢复,默认5s)
  3. hystrix.command.default.circuitBreaker.errorThresholdPercentage(出错百分比阈值,当达到此阈值后,开始短路。默认50%)
资源隔离

“非常正确!你知道Hystrix的底层原理吗?”

于是小铭祭出了官方的图:
在这里插入图片描述
Hystrix整个工作流如下:

  1. 构造一个 HystrixCommand或HystrixObservableCommand对象,用于封装请求,并在构造方法 配置请求被执行需要的参数;
  2. 执行命令,Hystrix提供了4种执行命令的方法,后面详述;
  3. 判断是否使用缓存响应请求,若启用了缓存,且缓存可用,直接使用缓存响应请求。Hystrix支持
    请求缓存,但需要用户自定义启动;
  4. 判断熔断器是否打开,如果打开,跳到第8步;
  5. 判断线程池/队列/信号量是否已满,已满则跳到第8步;
  6. 执行HystrixObservableCommand.construct()或HystrixCommand.run(),如果执行失败或者超
    时,跳到第8步;否则,跳到第9步;
  7. 统计熔断器监控指标;
  8. 走Fallback备用逻辑
  9. 返回请求响应
    从流程图上可知道,第5步线程池/队列/信号量已满时,还会执行第7步逻辑,更新熔断器统计信息,而 第6步无论成功与否,都会更新熔断器统计信息。

“Hystrix主要使用的是RxJava来做异步请求,RxJava是一个异步框架,是对观察者模式的一个应用。Hystrix会把对每个微服务的请求放到线程池里面,具体分配到哪个线程池可以使用HystrixThreadPoolKey来指定”:

@HystrixCommand(threadPoolKey = "user-hello")
String getUserHello();
12

老王继续问:“那你知道为什么要有这个key吗?它是用来干嘛的?”小铭摇了摇头,表示自己还不知道。

“你看源码就知道了,Hystrix使用了一个ConcurrentHashMap来保存线程池。”

ConcurrentHashMap<String, HystrixThreadPool> threadPools
1

小铭心中出现了一个新的问题:那为什么我们需要多个线程池呢?

此时老王继续说道:“这个其实叫资源隔离。应用程序会被完全保护起来,即使依赖的一个服务出问题了,也不会影响到应用程序的其他部分。使用多个线程池就是一种资源隔离方式,也是默认的隔离方式。而且Hystrix底层是使用的RxJava,使用线程池可以让你很方便地实现异步操作。”

“那除了线程池隔离,还有其它隔离方式吗?”

“有的,Hystrix提供了两种隔离方式:线程池隔离和信号量(Semaphore)隔离。”

“是的,线程池隔离就是上面说的那样。信号量主要起一个限流的作用。如果信号量耗尽了,它就直接走fallback流程所以也能防止雪崩。但大多数情况,我们更倾向于使用线程池。”

线程池隔离优缺点
  • 优点:
    • 保护应用程序以免受来自依赖故障的影响,指定依赖线程池饱和不会影响应用程序的其余部分。
    • 当引入新客户端lib时,即使发生问题,也是在本lib中,并不会影响到其他内容。
    • 当依赖从故障恢复正常时,应用程序会立即恢复正常的性能。
    • 当应用程序一些配置参数错误时,线程池的运行状况会很快检测到这一点(通过增加错误,延迟, 超时,拒绝等),同时可以通过动态属性进行实时纠正错误的参数配置。
    • 如果服务的性能有变化,需要实时调整,比如增加或者减少超时时间,更改重试次数,可以通过线 程池指标动态属性修改,而且不会影响到其他调用请求。
    • 除了隔离优势外,hystrix拥有专门的线程池可提供内置的并发功能,使得可以在同步调用之上构 建异步门面(外观模式),为异步编程提供了支持(Hystrix引入了Rxjava异步框架)。

注意:尽管线程池提供了线程隔离,我们的客户端底层代码也必须要有超时设置或响应线程中断,不能 无限制的阻塞以致线程池一直饱和。

  • 缺点:
    • 线程池的主要缺点是增加了计算开销。每个命令的执行都在单独的线程完成,增加了排队、调度和上下文切换的开销。因此,要使用Hystrix,就必须接受它带来的开销,以换取它所提供的好处。
    • 通常情况下,线程池引入的开销足够小,不会有重大的成本或性能影响。但对于一些访问延迟极低的服 务,如只依赖内存缓存,线程池引入的开销就比较明显了,这时候使用线程池隔离技术就不适合了,我 们需要考虑更轻量级的方式,如信号量隔离。
fallback

“刚刚你提到了一个词叫‘fallback流程’?”

“是的,fallback翻译过来是‘回退’的意思,有时候我们也会称它‘服务降级’。”

“那什么时候会触发fallback呢?”

“其实你应该已经可以总结出来了,主要这五种情况会触发fallback:”

  • 执行超时
  • 执行过程抛出异常
  • 断路器打开状态
  • 线程池拒绝(池满后的拒绝策略)
  • 信号量拒绝(信号量耗完)

“那触发fallback后会发生什么?”

老王熟练的打开源码,并快速敲下了一个Demo。“这个你得看HystrixCommand这个类的源码和使用方式。”

class AuthCommand extends HystrixCommand<Boolean> {
  public Boolean run() {
    return authService.authenticate(user);
  }
  
  protected Boolean getFallback() {
    return true;
  }
}
123456789

“我们在使用Hystrix的时候,一般是继承HystrixCommand这个类,重写rungetFallback这两个方法。正常情况它是走run方法的。如果发生了fallback,它就会调用getFallback方法。”

小铭看着这段代码,问到:“这看起来有点麻烦,在Spring Cloud中,有更简单的使用方式吗?”

“当然。在Spring Cloud中,Hystrix可以和OpenFeign无缝集成。OpenFeign接口上的每个方法都会被Hystrix断路器包裹(这也是一种典型的AOP实现)。你可以在注解上配置fallback方法:”

@HystrixCommand(fallbackMethod = "getByIdFallback")
public String getById(String id) {...}

private String getByIdFallback(String id) {...}
1234

感觉熔断这一块的知识点差不多理通了,小铭认真道谢,回到自己的位置继续撸代码……

Feign中使用断路器

Feign是自带断路器的,在D版本的Spring Cloud之后,它没有默认打开。需要在配置文件中配置打开它,在配置文件加以下代码:

feign:
    hystrix:
        enabled: true
123

基于service-feign工程进行改造

  • 实现UserClient 接口,并注入到Ioc容器中,代码如下:
@Component
public class UserClientHystrix implements UserClient {

    @Override
    public String sayHello(String name) {
        return "sorry " + name + " 上游服务断开, 服务降级";
    }

    @Override
    public String timeOut() throws InterruptedException {
        return "链接超时,服务降级";
    }

    @Override
    public String exception() throws Exception {
        return "发生异常,服务降级";
    }
}
123456789101112131415161718
  • 在FeignClient的UserClient接口的注解中加上fallback的指定类
@FeignClient(value = "service-client", fallback = UserClientHystrix.class)
public interface UserClient {

    @GetMapping("/client")
    String sayHello(@RequestParam(value = "name") String name);

    @GetMapping("/timeOut")
    String timeOut() throws InterruptedException;

    @GetMapping("/exception")
    String exception() throws Exception;
}
123456789101112
  • 启动eureka-server,然后再启动service-client,最后启动service-feign,在浏览器输入http://localhost:8765/sayHello?name=Beck Wang,会看如下效果
    在这里插入图片描述
  • 接下来我关掉service-client,就会看到如下效果:浏览器上显示了sorry Beck Wang,上游服务断开, 服务降级,就证明我们的熔断器起作用了,否则就会报500。

在这里插入图片描述

  • 比较常见的还有timeout,如果上游服务timeout,hystrix也是可以做出处理,首先要配置超时时间
# 设置超时时间
feign:
    httpclient:
        connection-timeout: 5000
1234

在这里插入图片描述

  • 还有就是上游服务抛出exception,hystrix也是可以处理
    在这里插入图片描述
  • 那么熔断之后,到底要怎么做呢?
    • 检查日志,修好它。
    • fallback就写你业务上可以返回的默认值

源码地址

文章来源:https://blog.csdn.net/qq_43985303/article/details/135125220
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。