Hystrix的使用，服务降级，服务熔断原理。。。

2. Hystrix

2.1 Hystrix 是什么?

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

2.2 谈谈我对服务熔断、服务降级的理解

今天先来说说“服务熔断”和“服务降级”。为什么要说这个呢，因为我很长时间里都把这两个概念同质化了，不知道这两个词大家怎么理解，一个意思or有所不同？现在的我是这么来看的：
在股票市场，熔断这个词大家都不陌生，是指当股指波幅达到某个点后，交易所为控制风险采取的暂停交易措施。相应的，服务熔断一般是指软件系统中，由于某些原因使得服务出现了过载现象，为防止造成整个系统故障，从而采用的一种保护措施，所以很多地方把熔断亦称为过载保护。
大家都见过女生旅行吧，大号的旅行箱是必备物，平常走走近处绰绰有余，但一旦出个远门，再大的箱子都白搭了，怎么办呢？常见的情景就是把物品拿出来分分堆，比了又比，最后一些非必需品的就忍痛放下了，等到下次箱子够用了，再带上用一用。而服务降级，就是这么回事，整体资源快不够了，忍痛将某些服务先关掉，待渡过难关，再开启回来。
所以从上述分析来看，两者其实从有些角度看是有一定的类似性的：
目的很一致，都是从可用性可靠性着想，为防止系统的整体缓慢甚至崩溃，采用的技术手段；
最终表现类似，对于两者来说，最终让用户体验到的是某些功能暂时不可达或不可用；
粒度一般都是服务级别，当然，业界也有不少更细粒度的做法，比如做到数据持久层（允许查询，不允许增删改）；
自治性要求很高，熔断模式一般都是服务基于策略的自动触发，降级虽说可人工干预，但在微服务架构下，完全靠人显然不可能，开关预置、配置中心都是必要手段；
而两者的区别也是明显的：
触发原因不太一样，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；
管理目标的层次不太一样，熔断其实是一个框架级的处理，每个微服务都需要（无层级之分），而降级一般需要对业务有层级之分（比如降级一般是从最外围服务开始）
实现方式不太一样，这个区别后面会单独来说；
当然这只是我个人对两者的理解，外面把两者归为完全一致的也不在少数，或者把熔断机制理解为应对降级目标的一种实现也说的过去，可能“一讨论就吵架”也正是这个原因吧！
概念算是说完了，避免空谈，我再总结下对常用的实现方法的理解。对于这两个概念，号称支持的框架可不少，Hystrix当属其中的佼佼者。
先说说最裸的熔断器的设计思路，下面这张图大家应该不陌生（我只是参考着又画了画），简明扼要的给出了好的熔断器实现的三个状态机：

Closed：熔断器关闭状态，调用失败次数积累，到了阈值（或一定比例）则启动熔断机制；
Open：熔断器打开状态，此时对下游的调用都内部直接返回错误，不走网络，但设计了一个时钟选项，默认的时钟达到了一定时间（这个时间一般设置成平均故障处理时间，也就是MTTR），到了这个时间，进入半熔断状态；
Half-Open：半熔断状态，允许定量的服务请求，如果调用都成功（或一定比例）则认为恢复了，关闭熔断器，否则认为还没好，又回到熔断器打开状态；
————————————————
版权声明：本文为优快云博主「guwei9111986」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.youkuaiyun.com/guwei9111986/article/details/51649240

服务不可用了(包括出现异常,超时异常),做服务降级

步骤

1. 主启动类 添加注解 @EnableCircuitBreaker

2. @HystrixCommand(fallbackMethod = "兜底方法名称", commandProperties = {
           @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1000")})
          
   

3. 声明兜底方法

2.3 服务降级导致代码膨胀

如果我们为每一个业务方法都添加@HystrixCommand(fallbackMethod = "兜底方法名称")注解的话,那么就会导致代码膨胀,且会和异常处理的方法混合,导致耦合度特别的低.对此,我们可以为个别重要核心业务有专属的兜底方法,其他普通的可以通过@DefaultProperties(defaultFallback = "")的方式统一跳转到统一处理结果页面.

我们将通同和独享的各自分开,能够有效的避免代码膨胀,合理减少代码量.

步骤：

1. 在类上添加注解@DefaultProperties(defaultFallback = "payment_Global_FallbackMethod")
2. 在方法上添加注解@HystrixCommand 开启服务降级，只要时添加了@HystrixCommand 的都会使用 @DefaultProperties的默认方法。
3. 除了使用默认的方法外，我们还可以对特殊的业务进行定制， 此时我们只需要对@HystrixCommand(fallbackMethod = "兜底方法") 加入fallback属性，声明兜底方法即可。

2.4 统配服务降级

我们除了可以使用 HystrixCommand 进行服务降级（往往配置在客户端的controller层），我们还可以通过 @FeignClient 进行统配服务降级，我们可以对 @FeignClient添加fallback属性，如 我们对 PaymentHystrixService接口 进行服务降级，那么我们就需要定义一个类PaymentFallbackService来实现 PaymentHystrixService 接口中的所有方法.

步骤：

1. PaymentHystrixService 接口上添加注解

@FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT", fallback = PaymentFallbackService.class)

2. PaymentFallbackService 实现 PaymentHystrixService 接口

   public class PaymentFallbackService implements PaymentHystrixService
   

3. 关闭 CLOUD-PROVIDER-HYSTRIX-PAYMENT 微服务模块，即服务端模块。此时如果没有对服务降级的话，都是会报错的，因为做了服务降级，那么对应的方法不能解决时，都会在 PaymentFallbackService 实现类中查找对应的方法进行解决，并返回结果。

4. 如果 PaymentFallbackService 实现类 的方法也不能解决时，就会 使用 @HystrixCommand(fallbackMethod = "兜底方法") 的方式进行解决，即抛出错误给controller解决。

2.5 什么是熔断机制

熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务出错不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。

在Spring Cloud框架里，熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，例如：缺省是5秒内20次调用失败，就会启动熔断机制。熔断机制的注解是@HystrixCommand.

步骤：

1. 在 服务器端 service 接口加入 @HystrixCommand 注解，该注解即是服务熔断的入口，也是服务降级的入口。服务熔断的前提就是服务降级。

@HystrixCommand(fallbackMethod = "paymentCircuitBreaker_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 = "60"),// 失败率达到多少后跳闸
    })

2. 多次错误，再来次正确，但错误得显示。重点测试 - 多次错误，然后慢慢正确，发现刚开始不满足条件，就算是正确的访问地址也不能进行

2.5.1 熔断类型

• 熔断打开：请求不再进行调用当前服务，内部设置时钟一般为MTTR(平均故障处理时间)，当打开时长达到所设时钟则进入半熔断状态。
• 熔断关闭：熔断关闭不会对服务进行熔断。
• 熔断半开：部分请求根据规则调用当前服务，如果请求成功且符合规则则认为当前服务恢复正常，关闭熔断。

2.5.2 断路器在什么情况下开始起作用

涉及到断路器的三个重要参数：

快照时间窗（sleepWindowInMilliseconds）：断路器确定是否打开需要统计一些请求和错误数据，而统计的时间范围就是快照时间窗，默认为最近的10秒。

请求总数阀值（requestVolumeThreshold）：在快照时间窗内，必须满足请求总数阀值才有资格熔断。默认为20，意味着在10秒内，如果该hystrix命令的调用次数不足20次7,即使所有的请求都超时或其他原因失败，断路器都不会打开。

错误百分比阀值（errorThresholdPercentage）：当请求总数在快照时间窗内超过了阀值，比如发生了30次调用，如果在这30次调用中，有15次发生了超时异常，也就是超过50%的错误百分比，在默认设定50%阀值情况下，这时候就会将断路器打开。

休眠时间窗（sleepWindowinMilliseconds）： 该属性用来设置当断路器打开之后的。 休眠时间窗结束之后，会将断路器置为 “半开” 状态，尝试熔断的请求命令，如果依然失败就将断路器继续设置为 “打开” 状态，如果成功就设置为 “关闭” 状态。

————————————————

2.5.3断路器开启或者关闭的条件

到达以下阀值，断路器将会开启：

当满足一定的阀值的时候（默认10秒内超过20个请求次数)
当失败率达到一定的时候（默认10秒内超过50%的请求失败)
当开启的时候，所有请求都不会进行转发

一段时间之后（默认是5秒)，这个时候断路器是半开状态，会让其中一个请求进行转发。如果成功，断路器会关闭，若失败，继续开启。
————————————————

2.5.4断路器打开之后

1：再有请求调用的时候，将不会调用主逻辑，而是直接调用降级fallback。通过断路器，实现了自动地发现错误并将降级逻辑切换为主逻辑，减少响应延迟的效果。

2：原来的主逻辑要如何恢复呢？

对于这一问题，hystrix也为我们实现了自动恢复功能。

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

借鉴文章 https://blog.youkuaiyun.com/u011863024/article/details/114298282