前面几篇我们介绍了Eureka服务注册中心、Ribbon客户端负载均衡以及Feign声明式REST服务调用组件，还有它们常见的配置以及问题的解决。
下面我们来逐步学习Spring Cloud的断路器Hystrix，本篇我们先来了解一下超时机制以及断路器相关的介绍。
一、目前的架构存在的问题
我们之前搭建了服务提供者microserver-provider-user微服务，以及服务消费者microserver-consumer-movie微服务，并且都将相关服务注册到Eureka Server注册中心中，各个微服务也使用了Ribbon进行了客户端负载均衡，使用了Feign进行声明式REST服务调用，所以截止到目前，我们搭建的Demo的结构如下模式：
在上面的架构下，在某些场景下，可能会有一些问题出现，例如服务提供响应非常缓慢，那么消费者对提供者的请求就会被强制等待，直到服务返回。在高负载场景下，如果不做任何处理，这种问题很可能造成所有用户请求的线程都被耗竭，而不能响应用户的进一步请求。
严重一些的，会引起所谓的“雪崩效应”。
二、雪崩效应
在微服务架构中通常会有多少个服务层调用，大量的微服务通过网络进行通信，从而支撑起整个系统。各个微服务之间也难免存在大量的依赖关系。然而任何服务都不是100%可用的，网络也往往是脆弱的，所以避免有些请求会失败。基础服务的故障导致级联故障，进而造成了整个系统的不可用，这种现象被称为雪崩式效应。服务雪崩效应描述的是一种因服务提供者的不可用导致服务消费者的不可用，并将不可用逐渐放大的过程。
A作为服务提供者，B为A的服务消费者，C和D是B的服务消费者。A不可用引起了B的不可用，并将不可用像雪球一样放大到C和D时，雪崩效应就形成了。
三、解决方案
1.超时机制
通过网络请求其他服务器时，都必须设置超时。正常情况下，一个远程调用一般在几十毫秒内就返回了。当依赖的服务不可用，或者因为网络问题，响应时间将会变得很长（几十秒）。而通常情况下，一次远程调用对应了一个线程/进程，如果响应太慢，那个线程/进程就会得不到释放。而线程/进程都对应了系统资源，如果大量的线程/进程得不到释放，并且越积越多，服务资源就会被耗尽，从而导致自身服务不可用。
所以必须为每个请求设置超时时间，当请求超过超时时间后，就会自动放弃本次请求，并且反馈请求超时的结果，防止服务器长时间等待，无法释放无效请求资源。
2.断路器模式
试想一下，家庭里如果没有断路器，电流过载了（例如功率过大、短路等），电路不断开，电路就会升温，甚至是烧断电路、起火。有了断路器之后，当电流过载时，会自动切断电路（跳闸），从而保护了整条电路与家庭的安全。当电流过载的问题被解决后，只要关闭断路器，电路又可以工作了。
同样的道理，当依赖的服务有大量超时时，再让新的请求去访问已经没有太大意义，只会无谓的消费现有资源。譬如我们设置了超时时间为1秒，如果短时间内有大量的请求（譬如50个）在1秒内都得不到响应，就往往意味着异常。此时就没有必要让更多的请求去访问这个依赖了，我们应该使用断路器避免资源浪费。
断路器可以实现快速失败，如果它在一段时间内侦测到许多类似的错误（譬如超时），就会强迫其以后的多个调用快速失败，不再请求所依赖的服务，从而防止应用程序不断地尝试执行可能会失败的操作，这样应用程序可以继续执行而不用等待修正错误，或者浪费CPU时间去等待长时间的超时。断路器也可以使应用程序能够诊断错误是否已经修正，如果已经修正，应用程序会再次调用操作。
断路器模式就像是那些容易导致错误的操作的一种代理，这种代理能够记录最近调用发生错误的次数，然后决定是允许操作继续，还是立即返回错误。
一个断路器大概有三种状态：关闭、打开、半开状态，如下图所示：
正常情况下，断路器是关闭的；当请求服务出现异常时，断路器打开，请求该服务时，立即返回错误；当断路器设置的时间窗结束，就会进行请求分流，一部分依然直接返回错误，一部分尝试去重新请求服务，此时为半开状态，当检测到服务的请求通过率正常时（低于开关阈值），就会将断路器半开闭状态修改为关闭状态；当检测到服务的请求通过率依然不行，依然会将断路器全部打开。
以上的解决方案都是理论操作，实现超时机制和断路器模式都是很有挑战和难度的。而在开发界中，Hystrix就是实现了超时机制和断路器模式的服务组件。
Hystrix大致实现了以下功能：
(1)服务监控 总共多少次请求，假设请求失败10%，断路器打开
(2)断路器的状态
(3)分流
(4)自我修复（断路器状态的切换）
下一篇我们就正式来学习Hystrix断路器组件。
参考：《51CTO学院Spring Cloud高级视频》
转载请注明出处：https://blog.csdn.net/acmman/article/details/100151511