第九篇：断路器--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版本）

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId> spring-cloud-starter-netflix-hystrix</artifactId>

</dependency>

2：启动类加@EnableCircuitBreaker

1	`@EnableCircuitBreaker`

3：fallback逻辑

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秒）算请求失败，不一定是服务提供者没启动，即使服务提供者启动，但是响应慢，超过了超时时间，一样请求失败。

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

@HystrixCommand(fallbackMethod = "fallback",commandProperties = {

@HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value="5000")

})

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

四：服务熔断

@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会启动一个休眠时间窗，在这个时间窗内，降级逻辑是临时的成为主逻辑，当休眠时间窗到期，断路器将进入半开状态，释放一次请求到原来的主逻辑上，如果此次请求正常返回，那么断路器将继续闭合，主逻辑恢复，如果这次请求依然有问题，断路器继续进入打开状态，休眠时间窗重新计时。

来源：CSDN

作者：sun_TheProgramLife

链接：https://blog.csdn.net/weixin_42107940/article/details/84028767

标签

hystrix

雪崩