# 熔断器：Hystrix
# 1. 容错
微服务架构的系统通常会包含多个微服务，各个微服务可能部署在不同的机器上并通过网络进行通信，那么就不可避免会遇到 网络请求超时、微服务不可用 等问题，这就会进一步引起依赖它的微服务不可用，这样不断引发服务故障的现象称为『雪崩效应』，最终的结果是整个应用系统瘫痪。
针对上述问题，处理容错有以下常用手段：
超时重试
在 HTTP 请求中通常会设置请求的超时时间，超过一定时间后我们（主调方）就会断开连接（不再等待被调方的响应）。
在设置『超时』的同时，一般会配合设置请求『重试』，也就是在请求失败时再次自动发起请求，但要注意重试次数不能设置太多。
具体的超时时间和重试次数需要结合具体的业务来指定。
熔断器
使用熔断器模式，如果请求出现异常，所有请求都会直接返回，而不会等待或阻塞，这样可以减少资源的浪费。
熔断器所造成的这种现象也叫『快速失败』。
熔断器还有一种半开的状态，当熔断器发现异常后会进入半开状态，此时它会『放行一个请求』来检测被调系统是否已经恢复，如果请求调用成功，则代表被调系统已经恢复正常，那么就会关掉熔断器，否则继续打开。
限流
由于被调系统处理能力时有限，如果请求方访问量过大会导致被调系统不可用。除了可以增加机器的物理配置，也可以对系统进行限流。常见的限流措施有控制并发数量。
# 2. 关于 Hystrix
Hystrix 是 Netflix 公司推出的一款针对分布式系统延迟和容错的开源库，其设计目的是通过添加延迟容忍和容错逻辑，从而控制分布式服务之间的交互。
Hystrix 封装了微服务调用过程中的每一个依赖，使每个依赖彼此隔离，当延迟情况发生时，它会被限制在资源中，并包含回退（fallback）逻辑，该逻辑决定在依赖发生任何类型故障时应做出何种响应。
Hystrix 的目标是阻止级联故障，对通过第三方客户端访问的依赖的延迟和故障进行保护和访问。Hystrix 实现这一目标的大致思路如下：
将外部依赖的访问请求封装在独立的线程中，进行资源隔离。
对于超出设定阈值的服务调用，直接进行超时处理，不允许其消耗过长时间而导致线程阻塞。
每个依赖服务维护一个独立的线程池，一旦线程池满了，直接拒绝服务调用。
统计依赖服务调用的成功次数、失败次数、拒绝次数、超时次数等结果。
在一段时间内，如果服务调用的异常次数超过一定的阈值，就会触发熔断器，停止对特定服务的所有请求。在一定时间内对服务降级，一段时间之后自动尝试恢复。
如果某个服务出现调用失败、被拒绝、超时等异常情况，就会自动调用 fallback 降级机制。
提示
Hystrix 是使用在服务调用者，即，服务消费者一方的。也就是使用 RestTemplate / OpenFeign 的那方。
# 3. 关于 Hystrix 的 “后浪”
由于 Hystrix 官方已经停止开发了，所以 Spring Cloud 社区又推出了一款新的熔断器：Resilience4j 。Hystrix 官方也是推荐使用 Resilience4j 来代替自己。但是截止到目前为止，Resilience4j 并没有表现出要全面替代 Hystrix 的态势，市场占有率始终上升缓慢。
除了国外的 Resilience4j ，国内的 Alibaba 也开源了它的熔断器 Sentinel 并在其中加入了限流的功能，在国内使用广泛。