Hystrix断路器

熔断器的状态

熔断器有三个状态 CLOSED 、 OPEN 、 HALF_OPEN 熔断器默认关闭状态,当触发熔断后状态变更为
OPEN ,在等待到指定的时间,Hystrix会放请求检测服务是否开启,这期间熔断器会变为 HALF_OPEN 半
开启状态,熔断探测服务可用则继续变更为 CLOSED 关闭熔断器。

Hystrix断路器_第1张图片

Closed :关闭状态(断路器关闭),所有请求都正常访问。代理类维护了最近调用失败的次数,
如果某次调用失败,则使失败次数加1。如果最近失败次数超过了在给定时间内允许失败的阈值,
则代理类切换到断开(Open)状态。此时代理开启了一个超时时钟,当该时钟超过了该时间,则切
换到半断开(Half-Open)状态。该超时时间的设定是给了系统一次机会来修正导致调用失败的错
误。

Open :打开状态(断路器打开),所有请求都会被降级。Hystix会对请求情况计数,当一定时间
内失败请求百分比达到阈值,则触发熔断,断路器会完全关闭。默认失败比例的阈值是50%,请求
次数最少不低于20次。

Half Open :半开状态,open状态不是永久的,打开后会进入休眠时间(默认是5S)。随后断路
器会自动进入半开状态。此时会释放1次请求通过,若这个请求是健康的,则会关闭断路器,否则
继续保持打开,再次进行5秒休眠计时。

Hystrix断路器_第2张图片

//由于这是个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断路器_第3张图片

Hystrix断路器_第4张图片

 

 Hystrix断路器_第5张图片

 熔断器的隔离策略

微服务使用Hystrix熔断器实现了服务的自动降级,让微服务具备自我保护的能力,提升了系统的稳定
性,也较好的解决雪崩效应。其使用方式目前支持两种策略:
线程池隔离策略: 使用一个线程池来存储当前的请求,线程池对请求作处理,设置任务返回处理超
时时间,堆积的请求堆积入线程池队列。这种方式需要为每个依赖的服务申请线程池,有一定的资
源消耗,好处是可以应对突发流量(流量洪峰来临时,处理不完可将数据存储到线程池队里慢慢处理)
信号量隔离策略: 使用一个原子计数器(或信号量)来记录当前有多少个线程在运行,请求来先判
断计数器的数值,若超过设置的最大线程个数则丢弃改类型的新请求,若不超过则执行计数操作请
求来计数器+1,请求返回计数器-1。这种方式是严格的控制线程且立即返回模式,无法应对突发
流量(流量洪峰来临时,处理的线程超过数量,其他的请求会直接返回,不继续去请求依赖的服
务)
线程池和型号量两种策略功能支持对比如下:

Hystrix断路器_第6张图片

 

 Hystrix断路器_第7张图片

 

你可能感兴趣的:(Hystrix断路器)