springCloud篇章整体栏目:
搭建SpringCloud项目五(Hystix)并使用自定义配置
搭建SpringCloud项目六(Config)配置中心动态刷新
从前面几章开始从0搭建SpringCloud项目,再逐步进行优化,加入其它组件。
上一章加入了ribbon组件,这次讲解一下我对Hystix的认识,hystix又叫熔断器,用来当作一种保护机制,例如:消费服务访问提供者服务时,提供者服务端宕机了,访问该服务肯定会失败,若正常情况,后面的每次请求都会在此处失败,并且消费服务将都会等待或者出现故障,如果后续连锁反应越来越多,请求数量大了可能会导致服务瘫痪。加入熔断器后,第一次发现调用的提供者服务宕机,后面每次就会在此处快速处理,直接拒绝,不再访问,并返回一个自定义的结果,直至提供者服务恢复(熔断器能够诊断错误是否已经修正)。
本章是接着上一章进行的,现结构如下:
第一步:添加依赖
在消费者服务添加熔断器依赖(测试用product服务调用account服务接口,在product服务添加)
<!--添加Hystrix依赖-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
<version>2.0.2.RELEASE</version>
</dependency>
第二步:新增测试接口
如上图,testRibbon是调用account服务的接口, hystrixReturn方法是自定义的一个熔断器处理返回的方法,HystrixCommand就是熔断器处理注解,fallbackMethod即是出现错误调用哪个自定义方法进行处理。里面有很多处理方法,可以去慢慢看。
第三步:开启Hystrix
第四步:测试
使用postman进行测试
启动eureka和gateway,account,product服务(同上一章)
正常启动
假若account服务错误(关闭该服务)
当访问出现错误时,会返回自定义的方法返回的结果。
第五步:测试默认配置
熔断器的默认配置是1000ms,若请求时间超过1000ms,熔断器就会认为这是一个出错,就会执行配置的自定义方法。
进行一下测试:
如下是提供者服务(account)的接口:
做一个线程睡眠处理,睡眠500ms(没有超过熔断器的默认认定的超时时间1000ms),重启account服务,再次请求:
结果:正常调用。
若睡眠1500ms,超过1000ms。
重启account服务,再次请求。
结果:返回自定义方法处理结果。
第六步:使用Feign开启熔断器
1、不用再启动类加Hystrix启动注解了,在yml配置文件加上
即可开启。
2、修改feign调用接口,如下,在feignClient注解上新增fallback注解,值为具体处理类
注意使用Component注解将其注入Spring容器。
在Controller层的方法里实例一个FeignClient对象,调用方法即可。
第七步:修改自定义配置(重点)
默认的熔断时间是1000ms,太短了。很多业务都不止1000ms,所以必须重写配置,不然还没有正常返回数据就被熔断了,在网上找了很多配置写在yml文件里面都没有效果,后面在网上看到一个大佬写的方式,重写一个配置类,给FeignClient注解使用(FeignClient注解,没有重新配置超时时间的方式,所以使用下面方式),如果使用@HystrixCommand注解的话,可以直接在注解里面重新配置超时时间。下面举例Feign方式使用熔断器时,重新配置熔断器的超时时间。
1、在消费服务(调用者服务)新增一个配置类
此处我写死了,你也可以在yml配置里面写参数,再通过Value注解方式获取。
2、修改FeignClient注解的configuration参数的值,值为刚才新建的配置类的类型
3、修改yml文件(重点)
新增如上配置,必须设置,且大于自定义配置设置的超时时间,这里的值默认也是1000ms,百度得知两处的配置都会生效且使用最小的一个值,所以若此处不配置,则默认使用1000ms为超时时间,上面写的配置类也不会生效。
4、测试
如下是服务提供者的方法,睡眠3000ms,模拟需要3000ms。
第二步里面可见重写的配置是4000ms,默认的是1000ms,调用服务需要3000ms,所以,若配置使用成功则不会熔断,若没有成功则会熔断。
5、测试
调用测试接口,耗时3000ms的数据能访问到,没有熔断。
若修改熔断超时时间为2000ms,结果如下显示:
若有问题,感谢指出。