Hystrix 断流器

一、分布式系统面临的问题

服务雪崩

　　多个服务之间调用的时候，假设微服务 A 调用微服务 B 和微服务 C，，微服务 B 和微服务 C 又调用其他的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务 A 的调用就会占用越来越多的系统资源，进而引起系统崩溃，这就是所谓的“雪崩效应”

　　对于流量高的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更加糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟隔离和管理，以便单个依赖关系的失败不能取消整个应用程序或系统

二、概述

　　Hystrix 是一个用于处理分布式系统的 延迟 和 容错 的开源库，在分布式系统里，许多依赖会不可避免的调用失败，比如超时，异常， Hystrix 能够保证在一个依赖出现问题的情况下，不会导致整体服务的失败，避免级联故障，以提高分布式系统的弹性。

　　“短路由“本身是一种开关装置，当某个服务单元发生故障之后，通过断路由的故障监控（类似熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应。而不是长时间的等待或者抛出异常，这样就保证了服务调用方的线程不会被长时间、不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

　　熔断机制是应对雪崩效应的一种微服务链路的保护机制。

　　当“扇出”链路的某个微服务调用响应时间太长是，会进行服务的降级，进而熔断该节点微服务的调用，快速返回“错误”的响应信息。当检测到该节点微服务调用响应正常恢复调用链路。在 Spring Cloud 框架里熔断机制通过 Hystrix 实现。Hystrix 会监控微服务间调用状况，当失败的调用到一定的阈值，缺省值是 5s 内 20 次调用失败就会启动熔断机制。熔断机制的注解是 @HystrixCommand。　　

三、服务熔断

provider 代码

@RestController
public class DeptController
{
    @Autowired
    private DeptService service = null;

    @RequestMapping(value = "/dept/get/{id}", method = RequestMethod.GET)
    //一旦调用服务方法失败并抛出了错误信息后，会自动调用@HystrixCommand标注好的fallbackMethod调用类中的指定方法
    @HystrixCommand(fallbackMethod = "processHystrix_Get")
    public Dept get(@PathVariable("id") Long id)
    {

        Dept dept = this.service.get(id);

        if (null == dept) {
            throw new RuntimeException("该ID：" + id + "没有没有对应的信息");//当这个地方抛出异常，就会触发 @HystrixCommand
        }

        return dept;
    }

    public Dept processHystrix_Get(@PathVariable("id") Long id)
    {
        return new Dept().setDeptno(id).setDname("该ID：" + id + "没有没有对应的信息,null--@HystrixCommand")
                .setDb_source("no this database in MySQL");
    }
}

四、服务降级

　　 整体资源快不够用了，忍痛将某些服务先关掉，待度过难关，再开启回来

　　 服务降级处理是在客户端实现完成的，与服务端没有关系

五、小结

　　服务熔断：

　　　　一般是某个服务故障或者异常引起，类似现实中的“保险丝”，当某个异常条件被触发，直接熔断整个服务，而不是一直等到此服务超时

　　服务降级

　　　　所谓降级，一般是从整体负荷考虑。就是当某个服务熔断之后，服务器将不再被调用，此时客户可以准备一个本地的 fallback 回调，返回一个缺省值。这样做，虽然服务水平下降，但是好歹可以用，比直接挂掉要强。