MySQL, Oracle, Linux, 软件架构及大数据技术知识分享平台

网站首页 > 精选文章 / 正文

SpringCloud-Hystrix原理

2025-02-10 12:40 huorong 精选文章 5 ℃ 0 评论

原文地址:
http://www.uml.org.cn/wfw/201906063.asp?artid=22057

一、Hystrix原理

1. Hystrix能做什么

通过Hystrix可以解决雪崩效应问题,它提供了资源隔离、降级机制、熔断、缓存等功能。

  • 资源隔离:包括线程池隔离和信号量隔离,限制调用分布式服务的资源使用,某一个调用的服务出现问题不会影响其他服务调用。
  • 降级机制:超时降级、资源不足时(线程或信号量)降级,降级后可以配合降级接口返回兜底数据。
  • 熔断:当失败率达到阈值自动触发降级(如因网络故障/超时造成的失败率高),熔断器触发的快速失败会进行快速恢复。
  • 缓存:返回结果缓存,后续请求可以直接走缓存。
  • 请求合并:可以实现将一段时间内的请求(一般是对同一个接口的请求)合并,然后只对提供者发送一次请求。

2. 隔离模式

Hystrix提供了两种隔离模式:线程池隔离模式、信号量隔离模式。

线程池隔离模式

使用个线程池来存储当前请求,线程池对请求做处理,设置任务返回处理超时时间,堆积的请求先入线程池队列。这种方式要为每个依赖服务申请线程池,有一定的资源消耗,好处是可以应对突发流量(流量洪峰时,处理不完可将数据存储到线程池队列慢慢处理)。

信号量隔离模式

使用一个原子计数器(或信号量)记录当前有多少个线程在运行,请求来先判断计数器的值,若超过设置的最大线程个数则丢弃该类型的新请求,若不超过则执行计数操作请求来计数器+1,请求返回计数器-1 。这种方式时严格的控制线程且立即返回模式,无法应对突发流量(流量洪峰来临时,处理的线程超过梳理,其他的请求会直接返回,不继续去请求依赖的服务)

3. 降级

服务降级的目的是保证上游服务的稳定性,当整体资源快不够了,将某些服务先关掉,待渡过难关,再开启回来。

1、快速模式

如果调用服务失败了,那么立即失败并返回。

2、故障转移

如果调用服务失败了,那么调用备用服务,因为备用服务也可能失败,所以也可能有再下一级的备用服务,如此形成一个级联。例如:如果服务提供者不相应,则从缓存中取默认数据。

3、主次模式

举个例子:开发中需要上线一个新功能,但为了防止新功能上线失败可以回退到老的代码,我们会做一个开关比如做一个配置开关,可以动态切换到老代码功能。那么Hystrix它是使用通过一个配置来在两个command中进行切换。

4、熔断器

4.1 熔断器流程

下图是Hystrix官网提供的熔断器工作流程。

4.2 熔断器原理

  • 开始时断路器处于关闭状态(Closed)
  • 如果调用持续出错、超时或失败率超过一定限制,断路器打开进入熔断状态,后续一段时间内的所有请求都会被直接拒绝
  • 一段时间后,保护器会尝试进入半熔断状态(Half-Open),允许少量请求来进行尝试,如果调用仍然失败,则回到熔断状态,如果调用成功,则回到断路器关闭状态

5、请求合并器

5.1 HystrixCollapser

微服务架构中通常需要依赖多个远程的微服务,而远程调用中最常见的问题就是通信消耗与连接数占用。在高并发的情况之下,因通信次数的增加,总的通信时间消耗将会变得越来越长。同时,因为依赖服务的线程池资源有限,将出现排队等待与相应延迟的情况。

为了优化这两个问题,Hystrix提供了HystrixCollapser来实现请求的合并,以减少通信消耗和线程数的占用。

HystrixCollapser实现了在HystrixCommand之前放置一个合并处理器,将处于一个很短的时间窗口(默认10毫秒)内对同一个依赖服务的多个请求进行整合,并以此批量方式发起请求的功能(前提是服务提供方提供相应的批量接口)。HystrixCollapser的封装多个合并发送的具体细节,开发者只需关注业务上将单次请求合并成多次请求即可。

5.2 合并请求的开销

需要注意请求合并的额外开销:用于请求合并的延迟时间窗会使得依赖服务的请求延迟增高。比如,某个请求不通过请求合并器访问的平均耗时5ms,请求合并的延迟时间窗为10ms(默认值),那么该请求设置了请求合并器之后,最坏情况下(在延迟时间窗结束时才发起请求)该请求需要15ms才能完成。

5.3 什么时候使用合并请求的功能

合并请求存在额外开销,所以需要根据依赖服务调用的实际情况决定是否使用此功能,主要考虑下面两个方面:

a) 请求命令本身的延迟

对于单次请求而言,如果[单次请求平均时间/时间窗口]越小,对于单次请求的性能形象越小。如果依赖服务的请求命令本身是一个高延迟的命令,那么可以使用请求合并器,因为延迟时间窗的时间消耗显得微不足道了。

b) 并发量

时间窗口内并发量越大,合并求情的性能提升越明显。如果一个时间窗内只有少数几个请求,那么就不适合使用请求合并器。相反,如果一个时间窗内具有很高的并发量,那么使用请求合并器可以有效减少网络连接数量并极大提升系统吞吐量,此时延迟时间窗所增加的消耗就可以忽略不计了。

6. Hystrix工作流程

下图来自Hystrix官网,其描述了Hystrix的工作流程。

转换成流程图,如下所示:

Tags:hystrix

控制面板
您好,欢迎到访网站!
  查看权限
网站分类
最新留言