熔断器的状态
熔断器有三个状态 CLOSED 、 OPEN 、 HALF_OPEN 熔断器默认关闭状态,当触发熔断后状态变更为
OPEN ,在等待到指定的时间,Hystrix会放请求检测服务是否开启,这期间熔断器会变为 HALF_OPEN 半
开启状态,熔断探测服务可用则继续变更为 CLOSED 关闭熔断器。
Closed :关闭状态(断路器关闭),所有请求都正常访问。代理类维护了最近调用失败的次数,
如果某次调用失败,则使失败次数加1。如果最近失败次数超过了在给定时间内允许失败的阈值,
则代理类切换到断开(Open)状态。此时代理开启了一个超时时钟,当该时钟超过了该时间,则切
换到半断开(Half-Open)状态。该超时时间的设定是给了系统一次机会来修正导致调用失败的错
误。
Open :打开状态(断路器打开),所有请求都会被降级。Hystix会对请求情况计数,当一定时间
内失败请求百分比达到阈值,则触发熔断,断路器会完全关闭。默认失败比例的阈值是50%,请求
次数最少不低于20次。
Half Open :半开状态,open状态不是永久的,打开后会进入休眠时间(默认是5S)。随后断路
器会自动进入半开状态。此时会释放1次请求通过,若这个请求是健康的,则会关闭断路器,否则
继续保持打开,再次进行5秒休眠计时。
//由于这是个Fegin所以会超时 @HystrixCommand(fallbackMethod = "buyCallBack") @RequestMapping(value = "/buy/{id}",method = RequestMethod.GET) public Product findById(@PathVariable Long id) { Product product = null; if(id !=1 ) { throw new RuntimeException("太忙了"); } //product = restTemplate.getForObject("http://service-product/product/1",Product.class); product = productFeignClient.findById(id); return product; }
熔断器的默认触发阈值是20次请求,不好触发。休眠时间时5秒,时间太短,不易观察,为了测试方
便,我们可以通过配置修改熔断策略:
hystrix: command: default: execution: isolation: thread: timeoutInMilliseconds: 6000 #默认的连接超时时间1秒,若1秒没有返回数据,自动的触发降级逻辑 circuitBreaker: enabled: true requestVolumeThreshold: 5 errorThresholdPercentage: 10 sleepWindowInMilliseconds: 10000
我们疯狂访问id为1的请求时(超过10次),就会触发熔断。断路器会端口,一切请求都会被降级处理。
此时你访问id为2的请求,会发现返回的也是失败,而且失败时间很短,只有20毫秒左右:
注:方法上一定要有降级的方法,不然监控不到。而且假如是HystrixCommand这个注解都支持,假如是
和Fegin结合的话,报错的地方交互的后面,前面是没有用的
熔断器的隔离策略
微服务使用Hystrix熔断器实现了服务的自动降级,让微服务具备自我保护的能力,提升了系统的稳定
性,也较好的解决雪崩效应。其使用方式目前支持两种策略:
线程池隔离策略: 使用一个线程池来存储当前的请求,线程池对请求作处理,设置任务返回处理超
时时间,堆积的请求堆积入线程池队列。这种方式需要为每个依赖的服务申请线程池,有一定的资
源消耗,好处是可以应对突发流量(流量洪峰来临时,处理不完可将数据存储到线程池队里慢慢处理)
信号量隔离策略: 使用一个原子计数器(或信号量)来记录当前有多少个线程在运行,请求来先判
断计数器的数值,若超过设置的最大线程个数则丢弃改类型的新请求,若不超过则执行计数操作请
求来计数器+1,请求返回计数器-1。这种方式是严格的控制线程且立即返回模式,无法应对突发
流量(流量洪峰来临时,处理的线程超过数量,其他的请求会直接返回,不继续去请求依赖的服
务)
线程池和型号量两种策略功能支持对比如下: