Netflix Hystrix断路器简介与工作原理

csdn_life18

已于 2023-04-15 16:45:21 修改

阅读量281

点赞数

分类专栏：微服务框架文章标签：微服务

于 2021-01-17 18:34:45 首次发布

原文链接：https://ken.io/note/netflix-hystrix-intro-principle

版权

微服务框架专栏收录该内容

19 篇文章 0 订阅

订阅专栏

文章目录

一、前言

1、Netflix Hystrix断路器是什么？

Netflix Hystrix是SOA/微服务架构中提供服务隔离、熔断、降级机制的工具/框架。Netflix Hystrix是断路器的一种实现，用于微服务架构的高可用性，是防止服务出现雪崩的利器。

2、为什么需要断路器？

在分布式架构中，一个应用依赖多个服务是非常常见的，如果其中一个依赖由于延迟过高发生阻塞，调用该依赖服务的线程就会阻塞，如果相关业务的QPS较高，就可能产生大量阻塞，从而导致该应用/服务由于服务器资源被耗尽而拖垮。

另外，故障也会在应用之间传递，如果故障服务的上游依赖较多，可能会引起服务的雪崩效应。就跟数据瘫痪，会引起依赖该数据库的应用瘫痪是一样的道理。

当一个应用依赖多个外部服务，一切都正常的情况下，如下图：

如果其中一个依赖发生延迟，当前请求就会被阻塞

出现这种情况后，如果没有应对措施，后续的请求也会被持续阻塞

每个请求都占用了系统的CPU、内存、网络等资源，如果该应用的QPS较高，那么该应用所以的服务资源会被快速消耗完毕，直至应用死掉。如果这个出问题的依赖（Dependency I），不止这一个应用，亦或是受影响的应用上层也有更多的依赖，那就会带来我们前面所提到的服务雪崩效应。

所以，为了应对以上问题，就需要有支持服务隔离、熔断等操作的工具

二、Hystrix 简介

1、Hystrix具备哪些能力/优点？

在通过网络依赖服务出现高延迟或者失败时，为系统提供保护和控制
可以进行快速失败，缩短延迟等待时间和快速恢复：当异常的依赖回复正常后，失败的请求所占用的线程会被快速清理，不需要额外等待
提供失败回退（Fallback）和相对优雅的服务降级机制
提供有效的服务容错监控、报警和运维控制手段

2、Hystrix 如何解决级联故障/防止服务雪崩？

Hystrix将请求的逻辑进行封装，相关逻辑会在独立的线程中执行
Hystrix有自动超时策略，如果外部请求超过阈值，Hystrix会以超时来处理
Hystrix会为每个依赖维护一个线程池，当线程满载，不会进行线程排队，会直接终止操作
Hystrix有熔断机制：在依赖服务失效比例超过阈值时，手动或者自动地切断服务一段时间

所以，当引入了Hystrix之后，当出现某个依赖高延迟的时候：

三、Hystrix 工作原理

1、Hystrix工作流

1、创建HystrixCommand 或者 HystrixObservableCommand 对象
2、执行命令execute()、queue()、observe()、toObservable()
3、如果请求结果缓存这个特性被启用，并且缓存命中，则缓存的回应会立即通过一个Observable对象的形式返回
4、检查熔断器状态，确定请求线路是否是开路，如果请求线路是开路，Hystrix将不会执行这个命令，而是直接执行getFallback
5、如果和当前需要执行的命令相关联的线程池和请求队列，Hystrix将不会执行这个命令，而是直接执行getFallback
6、执行HystrixCommand.run()或HystrixObservableCommand.construct()，如果这两个方法执行超时或者执行失败，则执行getFallback()
7、Hystrix 会将请求成功，失败，被拒绝或超时信息报告给熔断器，熔断器维护一些用于统计数据用的计数器。

这些计数器产生的统计数据使得熔断器在特定的时刻，能短路某个依赖服务的后续请求，直到恢复期结束，若恢复期结束根据统计数据熔断器判定线路仍然未恢复健康，熔断器会再次关闭线路。

2、依赖隔离

Hystrix采用舱壁隔离模式隔离相互之间的依赖关系，并限制对其中任何一个的并发访问。

3、线程&线程池

客户端（通常指Web应用）通过网络请求依赖时，Hystrix会将请求外部依赖的线程与会将App容器(Tomcat/Jetty/…)线程隔离开，以免请求依赖出现延迟时影响请求线程。

Hystrix会为每个依赖维护一个线程池，当线程满载，不会进行线程排队，会Return fallback或者抛出异常

可能会有人有疑问，为什么不依赖于HTTP Client去做容错保护（快速失败、熔断等），而是在访问依赖之外通过线程&线程池隔离的方式做这个断路器（Hystrix）。

主要是以下几个方面：

不同的依赖执行的频率不同，需要分开来对待
不同的依赖可能需要不同的Client的工具/协议来访问，比如我们可能用HTTP Client，可能用Thrift Client。
Client在执行的过程中也可能会出现非网络异常，这些都应该被隔离
Client的变化会引起断路器的变化

所以，Hystrix这样设计的好处是：

断路器功能与不同的Client Library隔离
不同依赖之间的访问互不影响
当发生大量异常时，不会造成App Container的响应线程排队，并且当异常的依赖恢复正常后，失败的请求所占用的线程会被快速清理，不需要额外等待
为不支持异步的依赖提供了异步的可能

这样做的成本是，多了一些线程上的资源消耗（排队，调度和上下文切换），不过从官方给到的数据上可能，这个消耗完全可以接受。目前Netflix每天有100亿+的Hystrix命令执行，平均每个应用实例都有40+个线程池。每个线程池有5-20个线程依然运行良好（不过这里 ken.io 不得不吐槽下，官方没有透露单个实例硬件配置）

官方给了一组测试数据，在单个应用实例60QPS，且每秒钟有350个Hystix子线程（350次Hystrix Command执行）的情况下。Hystrix的线程成本通常为0-3ms，如果CPU使用率超过90%，这个线程成本为有所上升约为9ms。相对于网络请求的时间消耗，这个成本完全可以接受。

4、整体说明

用户发起请求之后首先会进到业务线程池，业务线程池的每个用户线程它走到服务调用之前都会被HystrixCommandAspect进行拦截，之后它会创建如Hystrix的线程池，Metrics以及断路器这些属性。
创建完之后，它就会去判断断路器是否处在一个打开的状态，如果说处在一个打开的状态，它就会走到一个降级方法。如果没有定义降级方法，它就会直接去抛出一个Hystrix自己的异常。
当断路器处在关闭状态的时候，或者说断路器已经经过了一个休眠的时间窗口，那么它就会走到一个Executer，这个Executer就是Hystrix线程池的一个Executer。
当Hystrix线程池的线程数已经全部在运行状态中，而且队列已经满了的时候，就会收到一个线程池拒绝的信号。如果线程池被拒绝了，也同样走到一个降级的方法。
此时HystrixTimer这个线程会对Hystrix这些执行任务做一个超时检测，如果任务执行耗时超过了超时时间，那么就会抛出一个异常。同样在执行降级方法的时候，HystrixTimer也会对降级方法进行超时检测。
当外部发起服务调用的时候，如果说调用失败，比如说服务D是一个僵死的状态，或者说服务D本来就已经宕机了，返回的是一个错误的状态码，这些服务调用失败类结果都会走到一个降级方法。
而这些无论是成功失败，还是线程池拒绝，还是被断路器打开所造成的一个错误，都会去记录到Metrics这个对象中。
Metrics会收集最近10秒钟的一个时间窗口的统计信息，每一表都是有一个桶，这个桶包含success，fail，timeout与reject这些发生的事件的一个计数，如果失败次数占据的总的调用次数的百分比大于50%，就会影响断路器的一个开关，Metrics就会把断路器给打开。
除此之外， Metrics还会维护着线程池的线程数，线程池的队列大小以及QPS响应时间这些信息，包括请求延迟。Hystrix DashBoard会通过暴露出了一个Actuator的接口进行获取，进而展现在Hystrix DashBoard里面。这就是Spring Cloud Hystrix 的工作原理。
在此说明一下，这里的降级方法也可以没有定义，而直接抛出异常，降级方法这里的4个箭头也可以去指定抛出异常的情况。
一般来说降级方法要根据具体的业务场景，如果说当服务调用出错的时候，已经提前定义了一些默认的结果，可以使用降解方法，但是大部分情况下，直接返回null或者说一个空对象，就没有必要定义降级方法。
首先第一方面走到降级方法的时候，日志里面看不到一些异常，会隐藏了一些问题的暴露。另外一方面，当每个方法都定义一个降级方法的时候，会导致dao里面的方法会非常的杂乱，对于维护是有一个成本的。
一般来说，如果说当服务调用出错，需要直接返回null去判断的话，可以在上层方法体里面去做一个try catch。如果try catch比较繁琐的话，可以写一个工具类，遇到异常去使用一个替换值。