0%

Hystrix简介

Hystrix简介

多个微服务之间调用的时候,微服务A调用微服务B,微服务B调用微服务C,如果微服务C出现问题或者响应时间过长,就会导致微服务A占用越来越多的系统资源,进而导致系统崩溃,称为服务雪崩,其是由于提供者不可用导致消费者不可用,并将不可用逐渐放大的过程

如何防止雪崩呢?

  • 为网络请求设置超时
  • 使用断路器模式

Hystrix是什么

Hystrix是由Netflix开源的一个用于处理分布式系统的延迟和容错的开源库,在分布式系统,许多依赖不可避免的会调用失败,比如超时、异常等,Hystrix能够保证在一个依赖出问题的情况下,不会导致整体服务失败,避免级联故障,以提高分布式系统的弹性,”断路器”本身是一种开关装置,当某个服务单元发生故障之后,通过断路器的故障监控,向调用方返回一个符合预期的、可处理的备选响应(FallBack),而不是长时间等待或抛出调用方无法处理的异常,保证了调用方的线程不会被长时间的占用,从而避免了故障在分布式系统中的蔓延,乃至雪崩

Hystrix基于命令模式,Command是在Receiver和Invoker之间添加的中间层,Command实现了对Receiver的封装,通过继承HystrixCommand来封装

1
2
3
4
5
6
7
8
9
public abstract class HystrixCommand<R> extends AbstractCommand<R> implements HystrixExecutable<R>, HystrixInvokableInfo<R>, HystrixObservable<R>
// 重写run方法,用于执行业务逻辑
protected abstract R run() throws Exception;
// 一般还需要重写getFallback 用于降级
protected R getFallback() {
throw new UnsupportedOperationException("No fallback available.");
}

}

一个HystrixCommand实例只能调用一次

如何做到的容错?

  • 包裹请求 使用HystrixCommand包裹对外部依赖的调用逻辑,每个命令在独立的线程/信号量中执行
  • 跳闸机制 当某服务的错误率超过一定阈值时,Hystrix可以自动或手动跳闸,停止请求该服务一段时间
  • 资源隔离 Hystrix为每个依赖都维护了一个小型的线程池(或信号量),如果该线程池已满,发往该依赖的请求就被立即拒绝,不进行排队等候,从而加速失败判定。防止一个依赖耗尽所有的线程资源
  • 监控 Hystrix可以近乎实时地监控运行指标和配置的变化
  • 回退机制 当请求失败、超时、被拒,或断路器打开时,执行fallback回退逻辑
  • 自我修复 断路器打开一段时间后,会进入半开状态

作用

  • 服务熔断 当下游的服务因为某种原因不可用,上游服务为了保证自己整体服务可用,不再继续调用目标服务,直接返回,快速释放资源,类似于保险丝,当某个异常条件被触发时,直接熔断整个服务,而不是一直等到此服务超时,用于应对雪崩效应的一种保护机制,注解是@HystrixCommand,失败次数达到一定阈值,就会启动熔断,当检测到该服务响应正常后,则恢复调用 熔断是解决服务雪崩的一种方案。与服务降级配合使用
  • 服务降级 当下游的服务因为某种原因不可用,上游服务主动调用本地的一些降级逻辑fallBack方法,快速返回给用户,防止卡顿使得用户一直等待,熔断会导致服务降级,从而调用fallback,返回一个缺省值,虽然服务水平下降,但是不会导致整体挂掉。
  • 服务隔离 再不使用Hystrix的默认情况下,只有一个线程池维护所有的服务接口。如果大量的请求访问同一个接口,达到tomcat线程池的默认最大值,会导致其他接口也无法访问。为了解决该问题,hystrix使用了线程池/信号量隔离,为不同的接口提供独立的线程池,使得各大线程池之间不互相影响。
  • 服务限流 防止高并发情况下所有请求一窝蜂地全部打到服务上,导致服务崩溃

依赖

1
2
3
4
5
<!-- hystrix -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>

如果是F版及以上的话,需要使用该依赖

1
2
3
4
5
<!-- 新版hystrix -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

服务端使用hystrix

启动Hystrix

1
2
3
4
5
6
7
8
9
@SpringBootApplication
@EnableEurekaClient // 服务启动后注册到Eureka Server注册中心中
@EnableHystrix // 启动对于Hystrix的支持
public class HystrixProviderApp {

public static void main(String[] args) {
SpringApplication.run(HystrixProviderApp.class,args);
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
@RequestMapping(value = "/dept/get/{id}", method = RequestMethod.GET)
@HystrixCommand(fallbackMethod = "fallback_get") // 熔断配置,出现熔断则调用fallbackMethod中配置的方法
public Dept get(@PathVariable("id") Long id) {
Dept dept = deptService.get(id);
if(dept == null){
throw new RuntimeException("部门信息不存在");
}
return dept;
}

// 回调方法
public Dept fallback_get(@PathVariable("id") Long id){
Dept dept = new Dept();
dept.setDeptNo(id);
dept.setdName("信息不存在@HystrixCommand");
return dept;
}

由于每个方法上都要配置fallback方法,导致了代码的过度膨胀,可以在接口类上配置一个全局的默认fallback

1
@DefaultProperties(defaultFallback="defaultFallback")

如果方法上有fallback,走方法上的;如果方法上没有,则走类上的全局默认fallback

客户端使用hystrix

由于服务端的降级需要对每个方法进行@HystrixCommand配置,并且声明一个fallback回调方法,过于耦合,所以可以使用客户端来进行解耦

使用feign搭配hystrix来进行服务降级

1
2
3
4
5
6
7
// feign接口配置回调工厂
@FeignClient(value = "MICRO-SERVICE-DEPT-PROVIDER",fallbackFactory = DeptClientFallBackFactory.class)
public interface DeptClient {

@RequestMapping(value = "/dept/get/{id}",method = RequestMethod.GET)
Dept get(@PathVariable("id") long id);
}

回调工厂当出现错误时,会执行对应的方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
@Component
public class DeptClientFallBackFactory implements FallbackFactory<DeptClient> {

@Override
public DeptClient create(Throwable throwable) {
return new DeptClient() {
@Override
public Dept get(long id) {
Dept dept = new Dept();
dept.setDeptNo(id);
dept.setdName("信息不存在fallback");
return dept;
}
};
}
}

配置

feign启用hystrix

1
2
3
feign:
hystrix:
enabled: true

欢迎关注我的其它发布渠道