Hystrix_hystrix.threadpool 为啥没有提示-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_36331657/article/details/103722728

本文深入解析Hystrix组件，一种由Netflix开源的延迟和容错库，用于处理微服务间的调用，避免级联失败和雪崩效应。文章详细介绍了Hystrix的线程隔离、服务降级、服务熔断和限流机制，以及如何在Spring Cloud项目中配置和使用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1.简介

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

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

主页：https://github.com/Netflix/Hystrix/

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

2.雪崩问题

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

在这里插入图片描述
如图，一次业务请求，需要调用A、P、H、I四个服务，这四个服务又可能调用其它服务。

如果此时，某个服务出现异常：

在这里插入图片描述
例如微服务I发生异常，请求阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞：

在这里插入图片描述
服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，形成雪崩效应。

这就好比，一个汽车生产线，生产不同的汽车，需要使用不同的零件，如果某个零件因为种种原因无法使用，那么就会造成整台车无法装配，陷入等待零件的状态，直到零件到位，才能继续组装。此时如果有很多个车型都需要这个零件，那么整个工厂都将陷入等待的状态，导致所有生产都陷入瘫痪。一个零件的波及范围不断扩大。

Hystix解决雪崩问题的手段有两个：

线程隔离
服务熔断

3.线程隔离，服务降级

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

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

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

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

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

触发Hystix服务降级的情况：

线程池已满
请求超时

降级是作用？
1、可以监听你的请求有没有超时；（默认是1秒，时间可以改）
2、异常或报错了可以快速让请求返回，不会一直等待；（避免线程累积）
3、当的系统马上迎来大量的并发(双十一秒杀这种或者促销活动) 此时如果系统承载不了这么大的并发时，可以考虑先关闭一些不重要的微服务（在降级方法中返回一个比较友好的信息)，把资源让给核心微服务，待高峰流量过去，再开启回来。

4.程序入门

在消费端程序中添加依赖

<!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-netflix-hystrix -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
    <version>2.1.4.RELEASE</version>
</dependency>

在这里插入图片描述
当目标服务的调用出现故障，我们希望快速失败，给用户一个友好提示。因此需要提前编写好失败时的降级处理逻辑，要使用HystixCommond来完成：

在这里插入图片描述
要注意，因为熔断的降级逻辑方法必须跟正常逻辑方法保证：相同的参数列表和返回值声明。失败逻辑中返回User对象没有太大意义，一般会返回友好提示。所以我们把queryById的方法改造为返回String，反正也是Json数据。这样失败逻辑中返回一个错误说明，会比较方便。

当正常提供服务时，访问与以前一致。但是当我们将服务提供方停机时，会发现页面返回了降级处理信息：

在这里插入图片描述

4.1 .默认FallBack

	我们刚才把fallback写在了某个业务方法上，如果这样的方法很多，那岂不是要写很多。所以我们可以把Fallback配置加在类上，实现默认fallback：

在这里插入图片描述

4.2 设置超时

在之前的案例中，请求在超过1秒后都会返回错误信息，这是因为Hystix的默认超时时长为1，我们可以通过配置修改这个值：

我们可以通过hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds来设置Hystrix超时时间。该配置没有提示。
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMilliseconds: 6000 # 设置hystrix的超时时间为6000ms
在这里插入图片描述

5.服务熔断

熔断器，也叫断路器，其英文单词为：Circuit Breaker

在这里插入图片描述

熔断状态机3个状态：

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

为了能够精确控制请求的成功或失败，在consumer的调用业务中加入一段逻辑
这样如果参数是id为1，一定失败，其它情况都成功。

当我们疯狂访问id为1的请求时（超过20次），就会触发熔断。断路器会断开，一切请求都会被降级处理。

此时你访问id为2的请求，会发现返回的也是失败，而且失败时间很短，只有几毫秒左右：

在这里插入图片描述
不过，默认的熔断触发要求较高，休眠时间窗较短，为了测试方便，我们可以通过配置修改熔断策略：

circuitBreaker.requestVolumeThreshold=10
circuitBreaker.sleepWindowInMilliseconds=10000
circuitBreaker.errorThresholdPercentage=50

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

6.限流

hystrix限流就是限制你某个微服务的使用量（可用线程数、信号量）
hystrix通过线程池的方式来管理微服务的调用，它默认是一个线程池（大小10个）管理你的所有微服务，你可以给某个微服务开辟新的线程池：

@RequestMapping("/cloud/goodsHystrix2")
@HystrixCommand(fallbackMethod = "fallback",
                threadPoolKey = "goods",
                threadPoolProperties = {@HystrixProperty(name = "coreSize", value = "2"),
                @HystrixProperty(name = "maxQueueSize", value = "1")})
public ResultObject goodsHystrix2() throws InterruptedException {

threadPoolKey 是线程池唯一标识， hystrix 会使用该标识来计数，看线程占用是否超过了，超过了就会直接降级该次调用；
这里coreSize给他值为2 那么假设你这个方法调用时间是1s执行完，那么在1s内如果有超过2个请求进来的话，剩下的请求则全部降级；
其中maxQueueSize是一个线程队列，里面只能放一个请求线程，本来线程数有2个，队列里面允许放一个，那么总共只能有3个请求线程执行，如果超过了就会限流；