Spring Cloud --组件 -- Hystrix(熔断器)

Hystrix 熔断器

简介

Hystix,中文意思是豪猪,全身是刺,看起来就不好惹,是一种保护机制。

保护的微服务之间的调用

Hystrix也是Netflix公司的一款组件。

主页:https://github.com/Netflix/Hystrix/
在这里插入图片描述

那么Hystix的作用是什么呢?具体要保护什么呢?

Hystix是Netflix开源的一个延迟和容错库,用于隔离访问远程服务、第三方库,防止出现级联失败

雪崩问题

微服务中,服务间调用关系错综复杂,一个请求,可能需要调用多个微服务接口才能实现,会形成非常复杂的调用链路:

如果此时,某个服务出现异常:

在这里插入图片描述

例如微服务I发生异常,请求阻塞,用户不会得到响应,则tomcat的这个线程不会释放,于是越来越多的用户请求到来,越来越多的线程会阻塞:

在这里插入图片描述

服务器支持的线程和并发数有限,请求一直阻塞,会导致服务器资源耗尽,从而导致所有其它服务都不可用,形成雪崩效应。

Hystix解决雪崩问题的手段主要是服务降级和线程隔离

线程隔离,服务降级

原理

线程隔离示意图:
在这里插入图片描述

解读:

Hystrix为每个依赖服务调用分配一个小的线程池,如果线程池已满调用将被立即拒绝,默认不采用排队.加速失败判定时间。

用户的请求将不再直接访问服务,而是通过线程池中的空闲线程来访问服务,如果线程池已满,或者请求超时,则会进行降级处理,什么是服务降级?

服务降级:优先保证核心服务,而非核心服务不可用或弱可用。

用户的请求故障时,不会被阻塞,更不会无休止的等待或者看到系统崩溃,至少可以看到一个执行结果(例如返回友好的提示信息) 。

服务降级虽然会导致请求失败,但是不会导致阻塞,而且最多会影响这个依赖服务对应的线程池中的资源,对其它服务没有响应。

触发Hystix服务降级的情况:

  • 线程池已满
  • 请求超时

服务降级的演示

需求:

当user-service服务异常关闭时,不想让客户在浏览器上看到错误提示,想自定义都能看得懂的提示语句
在这里插入图片描述

第一步:导依赖

在order-service项目中

<dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
 </dependency>

第二步:在引导类上开启Hystrix

在这里插入图片描述

第三步:开发一个方法作为降级的处理方式

要求:方法的参数和返回结果类型要和原方法findById应该一致

在OrderService中添加方法

public String queryOrderByIdFallback(Long orderId) {
    return "服务器太忙,请稍后重试........";
}

第四步:修改原有的方法,在方法上添加注解

注意原方法也改成返回字符串

在这里插入图片描述

全局降级

上面的写法中每个方法都需要一个降级方法,很麻烦,我们可以使用一个全局的降级方案

第一步:可以写一个统一的降级方法

public String allMethodFallBack(){
   return " 服务器太太太忙,请稍后重试....";
 }

第二步:在类上添加一个注解 @DefaultProperties(defaultFallback=“allMethodFallBack”)如图:

在这里插入图片描述

第三步:去除方法上的降级方法,注意@HystrixCommand注意留着

效果演示:

在这里插入图片描述

超时设置

为了触发超时,我们可以在user-service中的UserController方法中休眠2秒:

把user-service服务启动,测试发现,还会进入降级方法中,

这是因为Hystix的默认超时时长为1秒,我们可以通过在order-service配置中修改这个值:(以下书写没有提示,可以直接拷贝测试)

hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 3000

这个配置会作用于全局所有方法。

服务熔断

熔断原理

熔断器,也叫断路器,理解成你们家电路上的保险丝 其英文单词为:Circuit Breaker

Hystix的熔断状态机模型:

在这里插入图片描述

状态机有3个状态:

  • Closed:关闭状态(断路器关闭),所有请求都正常访问。
  • Open:打开状态(断路器打开),所有请求都会被降级。Hystix会对请求情况计数,当一定时间内失败请求百分比达到阈值,则触发熔断,断路器会完全关闭。默认失败比例的阈值是50%,请求次数最少不低于20次。
  • Half Open:半开状态,open状态不是永久的,打开后会进入休眠时间(默认是5S)。随后断路器会自动进入半开状态。此时会释放1次请求通过,若这个请求是健康的,则会关闭断路器,否则继续保持打开,再次进行5秒休眠计时。

动手实践

为了能够精确控制请求的成功或失败,我们在user-service的UserController方法中加入一段逻辑:

@GetMapping("/{id}")
public User queryById(@PathVariable("id") Long id) {
    if(id == 1){
        throw new RuntimeException("太忙了");
    }
    return userService.queryById(id);
}

这样如果参数是id为1,一定失败,其它情况都成功。

我们准备两个请求窗口:

  • 一个请求:http://localhost:8080/order/101,注定失败(这个订单是1号用户)
  • 一个请求:http://localhost:8080/order/102,肯定成功(这个订单是2号用户)

熔断器的默认触发阈值是20次请求,不好触发。休眠时间时5秒,时间太短,不易观察,为了测试方便,我们可以通过配置修改熔断策略:

circuitBreaker:
 requestVolumeThreshold: 10
 sleepWindowInMilliseconds: 10000
 errorThresholdPercentage: 50

解读:

  • requestVolumeThreshold:触发熔断的最小请求次数,默认20
  • sleepWindowInMilliseconds:休眠时长,默认是10000毫秒
  • errorThresholdPercentage:触发熔断的失败请求最小占比,默认50%

当我们疯狂访问id为101的请求时(超过10次),就会触发熔断。断路器会断开,一切请求都会被降级处理。

此时你访问id为102请求,会发现返回的也是失败,然后最多等待10s后你会发现又能访问了。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值