hystrix熔断器（spring cloud）

戎断器需要手动开启

口 什么是Hystrix 。
口 Hystrix 解决了什么问题。
口 Hystrix 的工作原理。
口 如何在RestTemplate 和Ribbon 作为服务消费者时使用Hys衍ix 。
口 如何在Feign 作为服务消费者时使用Hystrix 。
口 如何使用Hystrix Dashboard 监控熔断器的状况。
口 如何使用Turbine 聚合多个Hystrix Dash board 。

2. 什么是Hystrix：

   在分布式系统中，服务与服务之间的依赖错综复杂， 一种不可避免的情况就是某些服务会出现故障，导致依赖于它们的其他服务出现远程调度的线程阻塞。
   Hystrix 是Netflix 公司开源的一个项目，它提供了熔断器功能，能够阻止分布式系统中出现联动故障。Hystrix 是通过隔离服务的访问点阻止联动故障的，
   并提供了故障的解决方案，从而提高了整个分布式系统的弹性。

3. Hystrix解决了什么问题：

   在复杂的分布式系统中，可能有几十个服务相互依赖，这些服务由于某些原因，例如机房的不可靠性、网络服务商的不可靠性等，导致某个服务不可用。
   如果系统不隔离该不可用的服务，可能会导致整个系统不可用。

   例如，对于依赖30 个服务的应用程序，每个服务的正常运行时间为99.99% ，对于单个服务来说， 99.99% 的可用是非常完美的。
   有99.9930 = 99.7% 的可正常运行时间和0.3% 的不可用时间，那么10 亿次请求中有3000000次失败，实际的情况可能比这更糟糕。

   如果不设计整个系统的韧性，即使所有依赖关系表现良好，单个服务只有0.01% 的不可用，由于整个系统的服务相互依赖，最终对整个系统的影响是非常大的。
   在微服务系统中， 一个用户请求可能需要调用几个服务才能完成。如图8-1 所示，在所有的服务都处于可用状态时， 一个用户请求需要调用A 、H 、I 和P 服务。
   当某一个服务，例如服务I，出现网络延迟或者故障时，即使服务A 、H 和P 可用，由于服务I 的不可用，整个用户请求会处于阻塞状态，并等待服务I 的响应。

   在高并发的情况下，单个服务的延迟会导致整个请求都处于延迟状态，可能在几秒钟就使整个服务处于线程负载饱和的状态。
   某个服务的单个点的请求故障会导致用户的请求处于阻塞状态，最终的结果就是整个服务的线程资源消耗殆尽。由于服务的依赖性，
   会导致依赖于该故障服务的其他服务也处于线程阻塞状态，最终导致这些服务的线程资源消耗殆尽， 直到不可用，从而导致整个问服务系统都不
   可用，即雪崩效应。 为了防止雪崩效应，因而产生了熔断器模型。Hystrix 是在业界表现非常好的一个熔断器模型实现的开源组件，它是Spring Cloud 组件不可缺少的一部分。

4. Hystrix的设计原则：

   总的来说， Hystrix 的设计原则如下。
   口防止单个服务的故障耗尽整个服务的Servlet 容器（例如Tomcat ）的线程资源。
   口快速失败机制，如果某个服务出现了故障，则调用该服务的请求快速失败，而不是线程等待。
   口提供回退（ fallback ）方案，在请求发生故障时，提供设定好的回退方案。
   口使用熔断机制，防止故障扩散到其他服务。
   口提供熔断器的监控组件Hystrix Dashboard，可以实时监控熔断器的状态。

5. Hystrix的工作机制：

   首先，当服务的某个API 接口的失败次数在一定时间内小于设定的阀值时，熔断器处于关闭状态，该API 接口正常提供服务。当该API 接口处理请求的失败次数大于设定的阀值时，
   Hystrix 判定该API 接口出现了故障，打开熔断器，这时请求该API 接口会执行快速失败的逻辑（即fallback 回退的逻辑），不执行业务逻辑，请求的线程不会处于阻塞状态。
   处于打开状态的熔断器， 一段时间后会处于半打开状态，并将一定数量的请求执行正常逻辑。剩余的请求会执行快速失败，若执行正常逻辑的请求失败了，则熔断器继续打开；
   若成功了，则将熔断器关闭。这样熔断器就具有了自我修复的能力。