服务雪崩、Hystrix以及服务熔断

一、服务雪崩
多个服务之间调用的时候，假设服务A调用微服务B和微服务C，微服务B和微服务C又调用其他的微服务，这就是所谓的“扇出”，如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统的崩溃，这就是所谓的“雪崩效应”。
对于高流量的应用来说，单一的后端依赖可能会导致所有的服务器上的所有资源都在几秒内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整合系统发生更多大的级联故障，这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。
因此，我们需要弃车保帅！

二、Hystrix
Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在每个依赖出现问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。
“断路器”本身就是一种开关装置，当某个服务单元发生故障的之后，通过断路器的故障监控（类似熔断保险丝），向调用方法返回一个服务预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方法无法处理的异常，这样就可以保证了服务调用方的线程不会被长时间、不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

三、服务熔断
熔断机制是应对雪崩效应的一种微服务链路保护机制
当扇出链路的某个微服务不可用或者响应时间太长，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现，Hystrix会监控微服务间的调用状况，当失败的调用到一定的阈值，缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand

使用Hystrix（Spring集成）

一、导入依赖

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-hystrix</artifactId>
    <version>1.4.6.RELEASE</version>
</dependency>
<!-- eureka-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka</artifactId>
    <version>1.4.6.RELEASE</version>
</dependency>

二、在业务代码中编写备选方案，并指定出现问题执行哪一个备选方案，用到注解@HystrixCommand

三、在该模块的主启动类上增加对熔断支持
用到注解@Enablehystrix

四、启动测试
当我们执行业务中存在的代码，或者是查询数据库中存在的数据，是可以正常获取到数据，但是当我们查询数据库中不存在的数据，系统不会报错，不会走抛出的异常，直接会执行我们编写的备选方案，这样系统会更加富有弹性！

服务降级

一、服务降级的理解
服务降级是从整体的网站请求负载考虑，集群中存在多个服务器节点，如果某一台服务器的并发访问量相比于其他的服务器多很多，那么我们可以通过暂时关闭其他的服务器来扩大这个服务器的处理能力，这就叫做服务降级

二、服务降级方法
1、编写一个针对某个service接口的降级类

2、在service接口上增加注解，并且配置属性FallbackFactory属性，绑定这个降级的类

3、在application.yaml中配置开启降级服务

三、总结
服务降级是从客户端起，当客户端访问某个服务，但是当这个服务出现熔断或者关闭的情况，该服务将不再被调用，此时在客户端我们可以准备一个FallBackFactory，返回一个缺省的信息（确保我们整体的服务能用，而不是直接崩掉）

Dashboard流监控

使用方法
1、导入依赖

2、编写application.yaml配置文件
配置一些接端口的信息

3、在主启动类中开启监控支持@EnablehystrixDashboard        

4、访问http://localhost:9001/hystrix就i可以进入到监控的页面了

至此，关于服务降级和服务熔断的机制你已经掌握了，欢迎持续关注，还会继续更新！