SpringCloudNetflix（Usage of Hystrix）

SpringCloud-Netflix（Usage of Hystrix）

有时候一个前端传递过来的请求，有可能涉及到后端的多个微服务之间的调用，然而，在微服务调用的时候，有可能某个微服务宕机，或者因为网络原因在很长时间无法返回资源，那么整个系统资源将会被快速消耗，甚至是造成整个系统服务雪崩。所以为了解决这些问题，就引入了服务熔断和服务降级

【服务熔断】：如果目标服务调用时间比较慢，或者大量的超时，那后续的请求将不会继续请求目标服务，而是直接返回降级的逻辑。当目标服务恢复后，熔断机制则会自动关闭。

【服务降级】：简而言之，就是，当主方案行不通的时候，我们改用备用方案。比如服务A调用服务B的时候，而B服务宕机了，从而导致了请求失败。那我们就可以返回一个“系统繁忙”或者“服务正在开发中”这样的字样给到用户，这种就数据服务降级。实际上降级，还分为主动降级和被动降级

【主动降级】：当某个服务的并发很大的时候，把一些无关紧要的服务关闭。

【被动降级】：如果服务调用异常，那我们就返回一个备用的数据，就像上面的例子。返回系统繁忙。

为了解决分布式架构下服务熔断问题，SpringCloud Netflix集成了一个hystrix组件，他的作用是，对某个服务的调用在一定时间内，超过一定次数，并且失败率超过一定值，该服务的熔断将会自动打开，并且执行一个由我们自己编写的一个fallback。本篇我会聊它的使用和设计原理，后面聊完Netflix的这一套使用后，则会聊它的源码。

Usage of Hystrix（alone）

我们现在有个统一的api工程，当前端调用api工程的时候，api使用resttemplate远程调用订单的微服务，然后我们在订单的微服务中让线程睡3s（用来模拟服务端返回慢），然后我们设置响应时间为1s，看看加入hystrix后会不会熔断。

统一的api模块中增加hystrix的pom
  <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
        </dependency>
View Code
订单的微服务模块中增加一个接口模拟订单创建，并且在接口中睡3s
@RestController
public class OrderController {

    @GetMapping("orders")
    public String hystrixDemo(){
       try {
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return "success";
    }
}
View Code
在统一的api中远程调用订单模块，并且增加hystrix配置（在5s内，超过20次请求，并且失败率超过50%，则默认触发熔断）
@RestController
public class HystrixController {

    @Autowired
    private RestTemplate restTemplate;

    // HystrixCommandProperties
    @HystrixCommand(commandProperties = {
            //最小请求阈值(当在配置时间窗口内达到此数量的失败后，进行短路)
            @HystrixProperty(name="circuitBreaker.requestVolumeThreshold",value ="10"),
            //睡眠时间窗口（触发熔断后等待的时间）
            @HystrixProperty(name="circuitBreaker.sleepWindowInMilliseconds",value ="5000"),
            //错误百分比
            @HystrixProperty(name="circuitBreaker.errorThresholdPercentage",value ="50")
    },fallbackMethod = "fallback")
    @GetMapping("/hystrix/order/{num}")
    public String hystrix(@PathVariable("num") int num){
        if (num%2==0){
            return "正常访问";
        }
        return  restTemplate.getForObject("http://localhost:9092/orders",String.class);
    }
    //我们在orderService中睡眠了3s，而默认的超时时间是1s,那这个时候就自动触发了服务降级
    public String fallback(int num){
        return "触发了降级";
    }
}
View Code
我们这里用num来控制正常访问，如果输入的num是2则返回正常访问。如果是1的话则会真正调用订单的微服务，而订单的微服务睡了3s所以肯定会对服务进行降级。

当我们连续调用订单模块之后，我们发现，使用num=2进行正常调用，则发现订单模块的微服务已经被熔断了。因为我们上面配置了5s，5s后我们再次请求num=2发现服务又自动恢复了。

Usage of Hystrix（integrate with openfeign）

我们还是使用统一api模块去调用各个微服务。

首先还是在统一的api模块中引入hystrix的pom

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
        </dependency>

View Code

并且在配置文件中加上【feign.hystrix.enabled=true】

新建一个类（实现前面继承商品接口的标注FeignClient注解的类），并且重写方法，用于返回服务降级的信息

//当feign触发了降级之后，他需要返回降级的消息,这个类会在标注了FeignClient的类上作为属性
public class GoodsServiceFallBack implements IGoodsServiceFeignClient {
    @Override
    public String getGoodsById(int id) {
        return "查询商品信息异常，Hystrix触发了降级保护机制";
    }
}

View Code

并且把这个类交给spring进行托管。

@Configuration
public class HystrixConfiguration {
    @Bean
    public GoodsServiceFallBack goodsServiceFallBack() {
        return new GoodsServiceFallBack();
    }
}

View Code

在商品模块中用外面传递的数字模拟控制服务响应慢

    /**
     * 根据ID查询商品信息
     * @return
     */
    @GetMapping("/goods")
    public String getGoodsById(int id){
        log.info("收到请求，端口为：{}",port);
        //这里也是为了模拟服务响应超时
        if (id%2==0){
            try {
                Thread.sleep(3000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }

        return "返回商品信息";
    }

View Code

当我们对一个服务多次访问失败的情况下，这个服务就会自动降级

Principle of Hystrix

Hystrix默认10s内达到20次请求，并且超过50%的请求是失败的，那么就会触发熔断，熔断后，在5s内，请求不会落到目标请求上去，而是直接返回fallback给到客户端。

熔断状态：

Open: 意味着接下来的请求不会发送到服务端，而是直接返回fallback

Closed:服务通信正常

Half-Open:熔断的自动恢复机制

熔断的原理：

当一个请求过来后，判断是否触发了熔断，如果已经触发了熔断，那就返回服务降级的逻辑，如果没有那就对当前时间窗口（底层使用了滑动窗口对数据进行了统计）的健康请求数量进行检查，判断是否大于20次，如果大于20次，那就去汇总总的错误数量，如果大于50%则开启熔断