一、背景
雪崩效应
在微服务架构中通常会有多个服务层调用,基础服务的故障可能会导致级联故障,进而造成整个系统不可用的情况,这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。
二、简介
hystrix通过服务隔离、熔断(也可以称为断路)、降级等手段控制依赖服务的延迟与失败。
三、Hystrix特性(熔断只是作用在服务调用这一端)
1.断路器机制
当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力.
2.Fallback
Fallback相当于是降级操作. 对于查询操作, 我们可以实现一个fallback方法, 当请求后端服务出现异常的时候, 可以使用fallback方法返回的值. fallback方法的返回值一般是设置的默认值或者来自缓存.
3.资源隔离
在Hystrix中, 主要通过线程池来实现资源隔离. 通常在使用的时候我们会根据调用的远程服务划分出多个线程池. 例如调用产品服务的Command放入A线程池, 调用账户服务的Command放入B线程池. 这样做的主要优点是运行环境被隔离开了. 这样就算调用服务的代码存在bug或者由于其他原因导致自己所在线程池被耗尽时, 不会对系统的其他服务造成影响. 但是带来的代价就是维护多个线程池会对系统带来额外的性能开销. 如果是对性能有严格要求而且确信自己调用服务的客户端代码不会出问题的话, 可以使用Hystrix的信号模式(Semaphores)来隔离资源.
四、Feign Hystrix
pom中:Feign中已经依赖了Hystrix
1、配置文件
feign.hystrix.enabled=true
2、创建回调类
创建HelloRemoteHystrix类继承与HelloRemote实现回调的方法
@Component public class HelloRemoteHystrix implements HelloRemote{ @Override public String hello(@RequestParam(value = "name") String name) { return "hello" +name+", this messge send failed "; } }
3、添加fallback属性
在HelloRemote
类添加指定fallback类,在服务熔断的时候返回fallback类中的内容。
@FeignClient(name= "spring-cloud-producer",fallback = HelloRemoteHystrix.class) public interface HelloRemote { @RequestMapping(value = "/hello") public String hello(@RequestParam(value = "name") String name); }
熔断相关信息后,不影响正常的访问
成功返回HelloRemoteHystrix的返回值,如果提供者挂掉,就会返回fallback的返回值。
参考:http://www.ityouknow.com/springcloud/2017/05/16/springcloud-hystrix.html
五、熔断监控工具
Hystrix Dashboard:直观地看到各Hystrix Command的请求响应时间, 请求成功率等数据
Turbine:汇总系统内多个服务的数据并显示到Hystrix Dashboard上
链接:http://www.ityouknow.com/springcloud/2017/05/18/hystrix-dashboard-turbine.html
@EnableCircuitBreaker原理介绍
@EnableCircuitBreaker :启动断路器
链接:https://blog.csdn.net/hry2015/article/details/78577695?utm_medium=referral