Hystrix断路器

概述

分布式系统面临的问题

复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候不可避免地失败。

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

什么是Hystrix

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

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

服务熔断

什么是服务熔断

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

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

熔断机制的注解是 @HystrixCommand

添加方法

1. 参考provider-8001模块新建provider-hystrix-8001模块

2. 在pom中添加相应依赖Hystrix
   

3. yml文件只需要修改instance中的instance-id（自定义服务名称信息）
   

4. DeptController
   
   HystrixCommand中的fallbackMethod意为：
   如果get方法调用成功，即返回正确内容；
   如果get方法有异常，则调用“processHystrix_Get“方法
   
   一旦调用服务方法失败并抛出了错误信息后，会自动调用@HtstrixCommand标注好的fallbackMethod调用类中的指定方法
   
   （但是这样写，每一个方法都要写一个对应的指定方法，内容太多，耦合度太高；解耦合写法更好——在下一个部分服务降级中详述）

5. 修改主启动类，添加新注解标签@EnableCircuitBreaker，对熔断机制的支持

服务降级

什么是服务降级

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

实现方法

1. 首先将HystricCommand解耦合
   
   解耦合
   
   前往不要忘记添加Component注解
   
   在DeptClientService中重写处理逻辑
   

2. 在api模块，DeptClientService接口在注解@FeignClient中添加fallbackFactory的属性值
   

3. api模块 mvn clean后再mvn install

4. consumer-dept-feign工程修改YML文件，开启feign
   

5. 

服务监控hystrixDashboard

Hystrix提供准实时的调用监控（Hystrix Dashboard），Hystrix会持续地记录所有通过Hystrix发起的请求的执行信息，并以统计报表和图形的形式展示给用户，包括每秒执行多少请求多少成功，多少失败等。
Netflix通过hystrix-metrics-event-stream项目实现了对以上指标的监控。
Spring Cloud也提供了Hystrix Dashboard的整合，对监控内容转化成可视化界面

1. POM中添加新依赖
   

2. YML中只需要写端口号即可
   

3. 主启动类中加入新注解@EnableHystrixDashboard
   

4. 所有provider微服务提供类（8001/02/03）添加监控依赖配置
   

5. 启动dashboard模块