第九篇：断路器--Hystrix简介

一：雪崩效应

如下图所示：A作为服务提供者，B为A的服务消费者，C和D是B的服务消费者。A不可用引起了B的不可用，并将不可用像滚雪球一样放大到C和D时，导致整个系统瘫痪，雪崩效应就形成了。

 

 

雪崩过程：

1：由于网路或其他原因（硬件故障、程序Bug、用户大量请求）A服务变得不可用，A服务的不可用导致B服务会出现线程的长阻塞,此时如果有大量的请求涌入（用户重试加大流量）,B服务servlet容器线程资源会被消耗完毕。大量请求的积压，直接导致B服务变慢，最终瘫痪

2：B服务瘫痪的瘫痪同理会导致C、D服务的瘫痪，最后导致系统瘫痪

 

二：熔断机制

所谓的熔断机制和日常生活中见到电路保险丝是非常相似的，当出现了问题之后，保险丝会自动烧断，以保护我们的电器，程序中我们也可以借用这个思想，使用Hystrix实现程序的熔断。

 

hystrix对应的中文名字是“豪猪”，豪猪周身长满了刺，能保护自己不受天敌的伤害，代表了一种防御机制，这与hystrix本身的功能不谋而合，因此Netflix团队将该框架命名为Hystrix，并使用了对应的卡通形象做作为logo。

 

三：Hystrix快速体验  服务提供者不动，修改服务消费者即可

 

1：pom依赖（Finchley.SR1版本）

1 2 3 4

<dependency>     <groupId>org.springframework.cloudgroupId>     <artifactId> spring-cloud-starter-netflix-hystrixartifactId> dependency>

 

2：启动类加@EnableCircuitBreaker

1	@EnableCircuitBreaker

3：fallback逻辑

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

package com.wendao.provider.consumer.web;   import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand; import com.wendao.provider.consumer.pojo.User; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.http.ResponseEntity; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; import org.springframework.web.client.RestTemplate;    @RestController public class ConsumerController {          @Autowired     private RestTemplate restTemplate;       @HystrixCommand(fallbackMethod = "fallback")     @RequestMapping("/findOne")     public User findOne(){         User user = restTemplate.getForObject("http://SPRING-CLOUD-SERVICE-PROVIDER/user/1", User.class);           return user;     }       //fallback逻辑     private User fallback(){           //TODO ....         return new User("fallback",12);     }    }

 

 

 

4：测试

关闭服务提供者，测试结果如下：

说明：

1：请求服务提供者失败，怎么样算失败呢？

答：请求超时（默认1秒）算请求失败，不一定是服务提供者没启动，即使服务提供者启动，但是响应慢，超过了超时时间，一样请求失败。

可以通过下面方式设置超时时间

1 2 3

@HystrixCommand(fallbackMethod = "fallback",commandProperties = {     @HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value="5000") })

2：服务提供者请求失败，会调用fallback逻辑，立即给客户端响应，这种情况叫服务降级

 

四：服务熔断

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

@RestController public class ConsumerController {          @Autowired     private RestTemplate restTemplate;       @HystrixCommand(fallbackMethod = "fallback",commandProperties = {         @HystrixProperty(name = "circuitBreaker.enabled",value="true"),         @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold",value="10"),         @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds",value="10000"),         @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage",value="50"),     })     @RequestMapping("/findOne")     public User findOne(){         //如果熔断器开启是不会进入这个方法的，直接调用fallback逻辑         System.out.println("come in");         User user = restTemplate.getForObject("http://SPRING-CLOUD-SERVICE-PROVIDER/user/1", User.class);           return user;     }       //fallback逻辑     private User fallback(){           //TODO ....         return new User("fallback",12);     }    }

 

刚开始你会发现打印come in ，说明主逻辑方法还是执行了，还是发送了请求，只不过请求失败，执行了fallback逻辑，这个时候只是服务降级。

一旦调用失败次数过大就会导致熔断器开启，熔断器如果open，那么就不可能让你继续执行主逻辑方法了，这时候fallback就成了主逻辑方法。

 

 

五：熔断器状态机

其实上面演示的不是熔断，熔断器根本没开启，上面演示的只是服务降级。真正的熔断器开启是要满足一定条件【阈值】，才会开启熔断器。

 

 快照时间窗：断路器确定是否打开需要统计一些请求和错误数据，而统计的时间范围就是快照时间窗，默认为最近的10秒。

 

  请求总数下限：在快照时间窗内，必须满足请求总数下限才有资格根据熔断。默认为20，意味着在10秒内，如果该hystrix命令的调用此时不足20次，即时所有的请求都超时或其他原因失败，断路器都不会打开。

1	circuitBreaker.requestVolumeThreshold

    错误百分比下限：当请求总数在快照时间窗内超过了下限，比如发生了30次调用，如果在这30次调用中，有16次发生了超时异常，也就是超过50%的错误百分比，在默认设定50%下限情况下，这时候就会将断路器打开。

1	circuitBreaker.errorThresholdPercentage

 

当熔断器在10秒内发现请求总数超过20，并且错误百分比超过50%，这个时候熔断器打开。打开之后，再有请求调用的时候，将不会调用主逻辑，而是直接调用降级逻辑，通过断路器，实现了自动地发现错误并将降级逻辑切换为主逻辑，减少响应延迟的效果。

在断路器打开之后，处理逻辑并没有结束，我们的降级逻辑已经被成了主逻辑，那么原来的主逻辑要如何恢复呢？对于这一问题，hystrix也为我们实现了自动恢复功能。当断路器打开，对主逻辑进行熔断之后，hystrix会启动一个休眠时间窗，在这个时间窗内，降级逻辑是临时的成为主逻辑，当休眠时间窗到期，断路器将进入半开状态，释放一次请求到原来的主逻辑上，如果此次请求正常返回，那么断路器将继续闭合，主逻辑恢复，如果这次请求依然有问题，断路器继续进入打开状态，休眠时间窗重新计时。