spring-cloud

发布日期: 2022-05-04

服务容错保护Spring Cloud Hystrix实现了断路器、线程隔离等一系列服务保护功能。它也是基于Netflix 的开源框架 Hystrix实现的，该框架的目标在于通过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。Hystrix具备服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等强大功能。

Spring Cloud Hystrix

雪崩效应

微服务架构的应用系统通常包含多个服务层。微服务之间通过网络进行通信，从而支撑起整个应用系统，因此，微服务之间难免存在依赖关系。我们知道，任何微服务都并非100%可用,网络往往也很脆弱，因此难免有些请求会失败。
我们常把“基础服务故障”导致“级联故障”的现象称为雪崩效应。雪崩效应描述的是提供者不可用导致消费者不可用，并将不可用逐渐放大的过程。

雪崩效应形成过程

可以看到, 当 C 服务挂掉时, B 服务还在不断地调用 C 服务期望获得结果, 结果在 B 服务内部产生了大量的调用等待和重试调用的线程, 随着新的请求不断地往这条调用链路上跑, 那么 B 服务的资源就会被这些线程耗尽, 从而导致 B 服务也不可用。同理, 当 B 服务也挂掉时, A 服务挂掉也只是时间的问题了。

在一个复杂的分布式系统中通常会有很多的依赖，如果我们不能对来自依赖的故障进行隔离，那么应用本身就会处于分险之中。在一个高流量的网站中，某一后端出现延迟，将会在数秒之内导致所有资源耗尽。

如何容错

要想防止雪崩效应，必须有一个强大的容错机制。该容错机制需实现以下两点。

必须为网络请求设置超时
正常情况下，一个远程调用一般在几十毫秒内就能得到响应了。如果依赖的服务不可用或者网络有问题，那么响应时间就会变得很长（几十秒)。而一次远程调用对应着一个线程/进程。如果响应太慢，这个线程/进程就得不到释放。而线程/进程又对应着系统资源，如果得不到释放的线程/进程越积越多，资源就会逐渐被耗尽，最终导致服务的不可用。
因此，必须为每个网络请求设置超时，让资源尽快释放。

使用断路器模式
如果对某个微服务的请求有大量超时（常常说明该微服务不可用)，再去让新的请求访问该服务已经没有任何意义，只会消耗资源。例加设詈了超时时间为1秒，如果短时间内有大量的请求无法在1秒内得到响应，就没有必要再去请求依赖的服务了。

断路器可理解为对容易导致错误的操作的代理。这种代理能够统计一段时间内调用失败的次数，并决定是正常请求依赖的服务还是直接返回。断路器可以实现快速失败,如果它在一段时间内检测到许多类似的错误（例如超时)，就会在之后的一段时间内，强迫对该服务的调用快速失败，即不再请求所依赖的服务。这样，应用程序就无须再浪费CPU时间去等待长时间的超时
断路器也可自动诊断依赖的服务是否已经恢复正常。如果发现依赖的服务已经恢复正常，那么就会恢复请求该服务。使用这种方式，就可以实现微服务的“自我修复”——当依赖的服务不正常时打开断路器时快速失败，从而防止雪崩效应;当发现依赖的服务恢复正常时,又会恢复请求。
断路器状态转换图

初探Hystrix

Hystrix官方代码托管在：https:github.com/Netflix/Hystrix。

Hystrix是由Netflix开源的一个延迟和容错库，旨在隔离远程系统、服务和第三方库，阻止级联故障，从而提升系统的可用性与容错性。Hystrix主要通过以下几点实现延迟和容错。

包裹请求:

使用HystrixCommand (或HystrixObservableCommand)包裹对依赖的调用逻辑，每个命令在独立线程中执行。这使用到了设计模式中的“命令模式”。。跳闸机制:当某服务的错误率超过一定阈值时，Hystrix可以自动或者手动跳闸，停止请求该服务一段时间。
资源隔离:

Hystrix为每个依赖都维护了一个小型的线程池（或者信号量)。如果该线程池已满，发往该依赖的请求就被立即拒绝，而不是排队等候，从而加速失败判定。

。监控:Hystrix可以近乎实时地监控运行指标和配置的变化，例如成功、失败、超时、以及被拒绝的请求等。
。回退机制:当请求失败、超时、被拒绝，或当断路器打开时，执行回退逻辑。回退逻辑可由开发人员自行提供，例如返回一个缺省值。
。自我修复:断路器打开一段时间后，会自动进入“半开”状态。断路器打开、关闭、半开的逻辑转换，前面已经详细探讨过了，本节不再赘述。