微服务项目之电商--4.Hystrix解决雪崩问题及线程隔离，服务降级，服务熔断处理分析测试

目录

 

一、Hystrix

1、简介

2、雪崩问题

 3、hystrix解决雪崩问题

1）线程隔离，服务降级

2）服务熔断

3）线程隔离，服务降级，服务熔断处理

​

4、服务熔断的深入分析

1）服务熔断测试

---

一、Hystrix

1、简介

hystrix，英文意思是豪猪，全是是刺，一种保护机制。

2、雪崩问题

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

如图，一次业务请求，需要调用A、P、H、I四个服务，这四个服务又可能调用其他服务。如果此时，某个服务出现异常，例如微服务I发送异常，请求阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞。而tomcat的最大连接数不能超过700。

 

 3、hystrix解决雪崩问题

1）线程隔离，服务降级

2）服务熔断

原理图

线程隔离：将服务线程的连接放入到线程池中管理，限制该服务使用的线程数量。实现线程隔离。

服务降级：设置等待阻塞时间，如果在有限时间内还是没有连接上，断开连接，返回用户请求超时。

3）线程隔离，服务降级，服务熔断处理

我们分析出现问题的根源虽然是在服务的提供方那，但是调用的是消费方，我们解决问题的目的是让消费方不会出现线程阻塞而浪费线程资源。所以服务降级应该是在消费方这里进行。

在consumer-demo中引入相关依赖

开启降级熔断处理注解

使用@springcloudapplication涵盖了上面三个重要注解

使用@HystrixCommand实现线程隔离和服务降级

这里一定要注意，在出现线程阻塞的时候通过HystrixCommand注解会自动去回滚调用指定回滚方法“queryByIdFallback”

这两个方法的返回类型、出入参数一定要一模一样

在日常开发过程中需要记录一下日志

现在我们模拟一个延迟，来看一下消费端是否能进行降级熔断处理

运行

 之前我们的降级逻辑都写在方法上，这样的话，如果所有的方法都进行降级处理，其代码冗余度就会增加

在类上添加属性配置注解

由于是默认对所有方法进行回滚调用，所以 为了能够使用任何方法，所以不传入参数

 

运行

 但是问题又来了，不同的业务调用服务的时延是不一样的，所以我们需要根据不同的业务设置不同的超时时间

具体的配置参数去hystrix包下

 

超时时间处理 

 

找到它对应的key

设置2秒的超时时长

 

配置全局的超时时长

 指定对应的服务超时时长（也可以指定方法）

对于线程隔离，其内部已经帮我们实现，我们要做的就是进行服务降级和熔断处理 

 

4、服务熔断的深入分析

上面还是存在问题，虽然设置了超时时间3秒后断开，但是在高并发的情况下，你还是存在很大性能下降。

这时候就需要将对应超时服务断开之后，又连回来的操作

hytrix熔断机制图

 状态机有3个状态：

closed：关闭状态（断路器关闭），所有请求都正常访问。

open：打开状态（断路器打开），所有请求都会被降级。hystrix会对请求情况计数，当一定时间内失败请求百分比达到阈值，则触发熔断，断路器会完全关闭。默认失败比例的阈值是50%，请求次数最少不低于20次。

half open：半开状态，closed状态不是永久的，关闭后会进行休眠时间（默认是5s），随后断路器会自动进入半开状态。此时会释放部分请求通过，若这些请求都是健康的，则会完全打开断路器，否则继续保持关闭，再次进入休眠计时。

 

1）服务熔断测试

通过抛出异常来参数熔断

 修改熔断阈值

关闭睡眠时间

 熔断的百分比

设置熔断器阈值数量 

 另外两个属性同理

首先访问id 1 ，没有问题

 访问多次2，触发熔断机制

 在访问1，说明该服务方法被触发了熔断

 过一会他就又没问题了