简介
- 前言：分布式系统下，微服务之间不可避免地会发生相互调用，但是没有一个系统能够保证自身运行的绝对正确 。 微服务在调用过程中，很可能会面临依赖服务失效的问题，这些问题的发生有很多原因，有可能是因为微服务之间的网络通信出现较大的延迟，或者是被调用的微服务发生了调用异常，还有可能是因为依赖的微服务负载过大无法及时响应请求等 。 因此希望有一个公共组件能够在服务通过网络请求访问其他微服务时，对延迟和失败提供强大的容错能力，为服务问调用提供保护和控制
Hystrix是Netflix的一个开源项目，它能够在依赖服务失效的情况下，通过隔离系统依赖服务的方式，防止服务级联失败；同时Hystrix提供失败回滚机制，使系统能够更快地从异常中恢复
Hystrix作用
- 在通过第三方客户端访问（通常是通过网络）依赖服务出现高延迟或者失败时，为系统提供保护和控制
- 在复杂的分布式系统中防止级联失败（服务雪崩效应）
- 快速失败（
Fail fast）同时能快速恢复 - 提供失败回滚（
Fallback）和优雅的服务降级机制 - 提供近实时的监控、报警和运维控制手段
Hystrix原理
-
服务雪崩：是一种因服务提供者的不可用导致服务调用者的不可用，并将不可用逐渐放大的过程
-
断路器：当服务提供者不可用时就很有可能发生服务雪崩效应，导致整个系统的不可用 。 所以为了预防这种情况的发生，可以使用断路器模式进行预防
- 三个状态
- 关闭状态:：断路器处于关闭状态，统计调用失败次数，在一段时间内达到－定的阀值后断路器打开
- 打开状态：断路器处于打开状态，对方法调用直接返回失败错误，不发生真正的方法调用 。 设置了一个重置时·间，在重置时间结束后，断路器来到半开状态
- 半开状态：断路器处于半开状态，此时允许进行方法调用，当调用都成功了（或者成功到达一定的比例），关闭断路器，否则认为服务没有恢复，重新打开断路器。断路器的打开能保证服务调用者在调用异常服务时，快速返回结果，避免大量的同步等待，减少服务调用者的资源消耗 。 并且断路器能在打开一段时间后继续侦测请求执行结果，判断断路器是否能关闭，恢复服务的正常调用
- 状态图
- 三个状态
-
服务降级：为了在整体资源不够的时候，适 当放弃部分服务，将 主要 的资源投放到核心服务中，待渡过难关之后，再重启已关闭的服务，保证了系统核心服务的稳定
Hystrix中当服务间调用发生问题时，它将采用备用的Fallback方法代替主方法执行并返回结果，对失败服务进行了服务降级，当调用服务失败次数在一段时间内超过了断路器的阀值时，断路器将打开，不再进行真正的方法调用，而是快速失败 ，直接执行Fallback 逻辑，服务降级，减少服务调用者的资源消耗，保护服务调用者中的线程资源
- 服务降级时序图
-
资源隔离：采用了舱壁模式，将系统中的服务提供者隔离起来， 一个服务提供者延迟升高或者失败，并不会导致整个系统的失败，同时也能够控制调用这些服务的并发度
- 方式一：线程与线程池:
Hystrix通过将调用服务线程与服务访问的执行线程分隔开来，调用线程能够空出来去做其他的工作而不至于因为服务调用的执行阻塞过长时间
- 资源隔离图
注意：在服务提供者的线程池被占满时，对该服务提供者的调用会被
Hystrix直接进入回滚逻辑，快速失败，保护服务调用者的资源稳定
- 方式二：信号量：通过信号量来控制系统负载，将不再允许设置超时控制和异步化调用，这就表示在服务提供者出现高延迟时，其调用线程将会被阻塞，直至服务提供者的网络请求超时
- 方式一：线程与线程池:
-
Hystrix实现思路- 它将所有的远程调用逻辑封装到
HystrixCommand或者HystrixObservableCommand对象中，这些远程调用将会在独立的线程中执行（资源隔离），这里使用了设计模式中的命令模式 Hystrix对访问耗时超过设置 阀值的请求采用自动超时的策略。该策略对所有的命令都有效（如果资源隔离的方式为信号量，该特性将失效），超时的阀值可以通过命令配置进行自定义- 为每一个服务提供者维护一个线程池（或者信号量），当线程池被占满时，对于该服务提供者的请求将会被直接拒绝（快速失败）而不是排队等待，减少系统的资源等待
- 针对请求服务提供者划分出成功、失效、超时和线程池被占满等四种可能出现的情况
- 断路器机制将在请求服务提供者失败次数超过一定阀值后手动或者自动切断服务一段时间
- 当请求服务提供者出现服务拒绝 、 超时和短路（ 多个服务提供者依次顺序请求，前面的服务提供者请求失败，后面的请求将不会发出） 等情况时，执行其
Fallback方法， 服务降级 - 供接近实时的监控和配置变更服务
- 它将所有的远程调用逻辑封装到
-
总结：日常开发中要多挖掘实现原理，方能更好的运用，知道使用场景的同时，也能发现改善的点。
