详解Hystrix
一文讲明白微服务的容错机制,以及hystrix的详细使用。
目录
1.微服务中的容错
1.1.服务雪崩
要说容错的话,肯定是有多种维度的。横向维度上来说,分布式架构,天然就带有分区容错性,多节点部署相同的服务就是为了容错,保证其中某些节点挂掉后,其它节点任然能提供该类服务。微服务种更需要考虑的是纵向维度上的容错机制,防止服务雪崩。
所谓的服务雪崩,指的是服务间存在着纵向的链路式的调用关系:
服务A调用服务B,服务B调用服务C。
当链路上有节点出现错误,无法正常提供服务,无法立即响应请求时,请求会逐步积压在上层服务,逐步打挂整个链路上的服务,就像异常雪崩一样,从一点开始引起全局的一场大崩溃。
1.2.解决办法
预防、解决服务雪崩有三种方法:
- 服务降级
- 服务熔断
- 服务限流
服务降级:
当服务提供方向服务调用方返回一个响应(fallback),而不是长时间等待或者直接抛出无法处理的异常。例如:“服务器忙,请稍后再试!”
服务降级的触发条件可以人为规定,乐意的话想定成什么都可以,一般常见的触发条件如下
- 报异常
- 超时
- 通信线程池被打满
服务熔断:
直接拒绝访问,快速返回一个开发者自定义的“异常信息”。
服务限流:
限制一个时间段内能够通行的请求数量。
降级和熔断的区别:
熔断:
熔断后请求不会再进调用服务的方法体,直接将链路断开,此后的每次请求都会直接被抛给fallback。
降级:
降级后请求依然会进调用服务的方法体,每次请求都会先试图去调用服务,只是服务自己察觉到自己可能出问题了从而拒绝服务,然后再将请求转给fallback。直接转发到即当服务的调用出现超时、异常等情况时,返回一个响应(fallback)。降级可以用在服务调用的全链路上的任意位置,既可以用在服务提供方,也可以用在服务提供方,不过为了使用规范,一般建议用在提供方(让服务自己管好自己)。
2.hystrix
-
2.1.概述
hystrix归属于Netflix版本的spring cloud中,是开源的一款微服务容错组件,提供了开箱即用的服务降级、熔断、监控等能力。由于Netflix将自己版本的spring cloud捐给apache后,后续apache维护的版本只维护了eureka,也就是说交给apache后,更新的spring cloud Netflix中只包含eureka,而不包含其它组件了,所以要用hystrix时,版本一定要选还在Netflix时的版本号,本文选择H版本以及其对应的spring boot 2.2.X为例:
如果对spring cloud版本问题还不是很清楚的同学,推荐去看博主另一篇文章,其中详细清晰快速的理清楚了整个spring cloud杂乱的版本关系:
详解Spring Cloud版本问题__BugMan的博客-CSDN博客
2.2.项目结构及依赖
项目结构:
maven项目,consumer,服务调用者;userService,服务提供者;eureka,注册中心。
依赖:
<properties>
<spring-cloud.version>Hoxton.SR12</spring-cloud.version>
<spring-boot.version>2.2.10.RELEASE</spring-boot.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring-cloud.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>${spring-boot.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
2.3.代码示例
2.3.1.注册中心
依赖:
配置:
启动:
2.3.2.服务调用者
依赖:
配置:
用ribbon来做RPC:
2.3.3.服务提供者
依赖:
配置:
启动:
服务:
开启容错和降级:
2.4.服务降级
2.4.1.单点响应
即每个服务接口单独定义异常响应。
效果:
2.4.2.默认响应
单点响应,每个服务单独对应一个fallback,会造成代码膨胀,高耦合的问题。
可以定义一个默认的全局响应,来统一处理服务降级。
单点响应优先,有单点响应的服务会优先匹配单点响应,没有单点响应的服务匹配全局响应。一般很重要的核心业务的熔断才单独写响应,一般业务用默认响应足以。
这里给一个博主之前写的默认响应的代码示例:
2.4.3.前置响应
无论是单点响应还是默认响应,响应代码和业务代码都耦合在一起,前置响应将响应放在OpenFeign调用侧,使得业务代码和响应代码解耦。
依赖:
OpenFeign的依赖中包含了hystrix,导入OpenFeign后不用单独导入hystrix。
配置:
响应类:
映射:
2.5.服务熔断
2.5.1.概述
hystrix实现了熔断机制,会监控服务间的调用情况,当失败的次数达到一定阈值时(默认是5秒内20次调用失败),就会启动熔断机制。
“断路器”总共有三种状态:
- 1.close,闭合状态,正常工作。
- 2.Open,开启状态,熔断。
- 3.Half Open,半开状态,“我觉得我又行了,我先放过一波请求试试实际行不行?”
-
2.5.2.使用
-
用@HystrixCommand来定制断路器的触发规则。
2.6.hystrix的文档地址
由于交给apache后最新版本的Netflix的spring cloud只包含了eureka,相应的也只包含了eureka的文档,其它组件的文档都不太好找,这里给出hystrix在github上的文档地址:
更多推荐
所有评论(0)