微服务SpringCloud组件的断路器Hystrix的介绍

1、Spring Cloud Hystrix 简介

Spring Cloud hystrix通过服务隔离、熔断(也可以称为断路)、降级等手段控制依赖服务的延迟与失败。

  1.1 Hystrix 概述

在大型分布式系统中，通常系统有很多依赖(数据库、Redis、第三方系统等)；

在高并发访问下,这些依赖的稳定性与否对系统的影响非常大，当依赖阻塞时,大多数服务器的线程池就出现阻塞(BLOCK),影响整个线上服务的稳定性.

  1.2 Hystrix 的功能与作用

1、断路器机制

断路器很好理解, 当HystrixCommand请求后端服务失败数量超过一定比例(默认50%),断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED),否则重新切换到开路状态(OPEN). Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力。

2、Fallback

Fallback相当于是降级操作.对于查询操作,我们可以实现一个fallback方法, 当请求后端服务出现异常的时候, 可以使用fallback方法返回的值.fallback方法的返回值一般是设置的默认值或者来自缓存。

3、资源隔离

在Hystrix中, 主要通过线程池来实现资源隔离. 通常在使用的时候我们会根据调用的远程服务划分出多个线程池. 例如调用产品服务的Command放入A线程池, 调用账户服务的Command放入B线程池. 这样做的主要优点是运行环境被隔离开了. 这样就算调用服务的代码存在bug或者由于其他原因导致自己所在线程池被耗尽时, 不会对系统的其他服务造成影响. 但是带来的代价就是维护多个线程池会对系统带来额外的性能开销. 如果是对性能有严格要求而且确信自己调用服务的客户端代码不会出问题的话, 可以使用Hystrix的信号模式(Semaphores)来隔离资源。

2、Hystrix 的设计

1.      构建Hystrix的Command对象, 调用执行方法。

2.      Hystrix检查当前服务的熔断器开关是否开启,若开启, 则执行降级服务getFallback方法。

3.      若熔断器开关关闭,则Hystrix检查当前服务的线程池是否能接收新的请求, 若超过线程池已满, 则执行降级服务getFallback方法。

4.      若线程池接受请求,则Hystrix开始执行服务调用具体逻辑run方法。

5.      若服务执行失败,则执行降级服务getFallback方法, 并将执行结果上报Metrics更新服务健康状况。

6.      若服务执行超时,则执行降级服务getFallback方法, 并将执行结果上报Metrics更新服务健康状况。

7.      若服务执行成功,返回正常结果。

8.      若服务降级方法getFallback执行成功, 则返回降级结果。

9.      若服务降级方法getFallback执行失败, 则抛出异常。

3、Hystrix 实施部署

1.1  实施方案

使用Hystrix很简单，只需要添加相应依赖即可，以Maven为例：

(1)、pom中添加依赖

<dependency>

      <groupId>org.springframework.cloud</groupId>

      <artifactId>spring-cloud-starter-hystrix</artifactId>

</dependency>

<!--hystrix-dashboard监控-->

<dependency>

     <groupId>org.springframework.cloud</groupId>

     <artifactId>spring-cloud-starter-hystrix-dashboard</artifactId>

</dependency>

4、总结

总结一下，在大型的分布式架构中，当调用链路过长时，系统的可用性是很大的挑战。Spring Cloud框架的Hystrix提供了熔断机制，当调用链路出现问题时可以快速进行服务降级处理，为我们提高服务的可用性提供了很大的帮助。它可以很好的防止因为服务不可用时，大量线程阻塞导致的无法访问、宕机等问题。