总括:
回退部分原理过程:
Hystrix可以用于熔断也可用于获取缓存请求的结果,避免同样的请求重复多次
1,拦截到相应的注解方法--注解为入口
获取方法的metaholder---包含方法的信息,回退的信息
2,获取方法对应的执行实例 (执行的就是这个)
执行实例中的builder这里创建,这里会再次设置回退,结果缓存,缓存移除(根据注解,属性标志填充,有值build就通过设置相应的值,不为空说明需要进行相应操作)
3,executtype获取执行类类型
同步执行
异步执行
返回Observable对象
同样返回Observable对象
4,执行前判断是不是观察者模式,进而选择执行器
在执行的过程中一旦执行失败就会,执行getfallback()执行一个回退操作,利用了观察者模式 ----参考这个设计执行链,回调模式
queue().get()----futrue模式
缓存部分原理过程:
执行的就是builder---这个builder中有目标方法run,有对应的fallback(观察者模式),有是否缓存的处理(用享元模式判断是否从缓存中获取)
存入缓存:
1,获取并发策略,缓存实例,根据注解判断是否启用缓存 根据前缀+并发策略+key组合
2,判断是否启用缓存,启用的话先判断缓存是否为空,不为空就从缓存中获取,为空就从接口获取,并存入缓存---concurrenthashmap
刷新缓存:
1,@HystrixCommand+@CacheRemove注解组合实现
用的还是hystrix注解的切面 以hsytrix为主线,判断的时候用builder中的CacheRemoveInvocationContext为空为标志,有值才刷新缓存
在每次执行后都会判断是否需要清楚缓存--注意在查找的时候用的是默认的并发策略,可能和实际的不一致导致清除无效
2,@CacheRemove注解实现
用的是CacheRemove的切面,注意springcloud并没有帮我们注册HystrixCacheAspect实例,用之前需要注册HystrixCacheAspect实例,CacheInvocationContext的来源是自己
该切面自己组装的不是hystrixcommand组装的
前言
最近在项目中需要使用Hystrix的request cache来提升服务的稳定性与高性能,其对于单个request请求,能够对指定方法methodA的返回值进行缓存,在多次调用methodA方法时仅会执行方法体一次,从而降低本次请求的复杂度。如果在methodA中存在对下游服务的依赖,则同步能够提高下游服务的稳定性,一定程度降低其并发性要求。Cache中的数据会存在更新,Hystrix同步提供了clear cache的对应实现。本章将从源码的角度来剖析下Hystrix是如何实现降级、缓存操作的。
本章概要
1、Hystrix是如何实现fallback的?
2、Hystrix是如何实现request cache的存储与获取?
3、Hystrix是如何实现request cache的清除?
Hystrix是如何实现fallback的?
在实际应用过程通过@HystrixCommand注解能够更加简单快速的实现Hystrix的应用,那么我们就直接从@HystrixCommand注解入手,其中包含了诸多参数配置,如执行隔离策略,线程池定义等,这些参数就不一一说明了,我们来看看其是如何实现服务降级的,如下图
其定义了fallbackMethod方法名,正如其名,其提供了一个定义回退方法映射,在异常触发时此方法名对应的method将被触发执行,从而实现服务的降级。那么@HystrixCommand注解又是如何被执行的呢,我们找到HystrixCommandAspect.java,其切点定义如下
可以看到被@HystrixCommand注解的方法将会执行切面处理。通过Hystrix的类关系图先来了解下其定义了哪些类来实现我们的HystrixCommand,
在HystrixCommandAspect的methodsAnnotatedWithHystrixCommand方法中我们可以看到如下
以上通过红色框标记了3个重点。
首先来看第一个,通过类关系图已经可以了解到,其定义了后续真正执行HystrixCommand的GenericCommand实例,其定义如下
这里有两个重点,一个是metaHolder包含了当前被注解方法的所有相关有效信息(定义在HystrixCommandAspect.java中),如下可以看到红色框中已经标记了fallback回退方法的设定:
另一个是其构造参数中的HystrixCommandBuilder,其定义来源于HystrixCommandBuilderFactory,如下主要参数设定均通过metaHolder来实现:
此处我们仍然需要关注红色框中的标记信息,在创建HystrixCommandBuilder实例过程中会设定当前执行方法体是CacheResult还是CacheRemove操作,同时设定需要被忽略的异常以及回退方法指令。简单了解下CacheInvocationContext的设定过程,如下
后续在cache处理的部分会再次提到CacheInvocationContext,这里先伏笔下。
再来看第二个红色框中的标记,根据名称即可判断,其主要是作为后续执行体类型的一个判断条件,在定义切点时已经可以看到当前切面不仅可以处理HystrixCommand还能够处理HystrixCollapser(HystrixCollapser是做请求合并的,不在本章的分析范围内)。
跟着代码继续往下,到了第三个红色框,在进入执行体前,其有一个判断条件,判断其是否是一个Observable模式(在Hystrix中,其实现大量依赖RXJAVA,会无处不在的看到Observable,其是一种观察者模式的实现,具体可以到RxJava项目官方做更多了解)。那么我们就来看看CommandExecutor中是如何执行,方法体如下
其根据executionType决定了最终的执行方式,如下
execute():同步执行,从依赖的服务返回一个单一的结果对象,或是在发生错误的时候抛出异常;
queue():异步执行,直接返回一个Future对象,其中包含了服务执行结束时要返回的单一结果对象;
observe():返回Observable对象,它代表了操作的多个结果,他是一个Hot Observable;
toObservable():同样返回Observable对象,也代表了操作的多个结果,但其返回的是一个Cold Observable。
这里我们通过execute()同步执行的方式继续跟踪,在原理上各方法差异不大,其均是由toObservable()扩展后实现的,execute()方法的实现是执行queue()后获取返回的Future对象,通过get()方法阻塞然后获取对应的返回值实现同步,在HystrixCommand中定义如下:
此时我们需要特别关注注释中的一段话,其提示了我们,一旦方法执行失败,则会通过getFallback()方法来执行一个回退操作。 直接进入GenericCommand类中,可以找到最终的实现
如上,其呼应了上面构造HystrixCommandBuilder是的CommandAction指令。可能我们会有亦或,又是如何触发getFallback()和run()方法的,具体的方法调用线路可以从AbstractCommand的toObservable()方法开始找,这里就不展开了。通过下图可以很容易理解为何我们上面只需要分析execute()即可,而方法的调用线程从toObservable()方法开始找:
Hystrix是如何实现request cache的存储与获取?
上面已经介绍了Hystrix是如何实现fallback的,同时也在构造HystrixCommandBuilder时已经提及了其对后续的cache将会起到一个关键作用。本小节将重点来分析Hystrix是如何实现Request cache的获取和存储的。
首先来看看HystrixRequestCache的定义
其通过ConcurrentHashMap来保证了cache的线程安全,其key值通过prefix前缀+hystrix并发策略+cachekey组合。
上面已经提及,调用的线路从AbstractCommand中的toObservable()方法开始,如下我们先来看看AbstractCommand构造函数的定义
通过红色框中的标记已经可以看到其通过HystrixPlugins获取concurrencyStrategy并发策略,从而实例化了HystrixRequestCache实例requestCache。
找到方法链的入口,在toObservable()方法中如下首先尝试从cache中获取value
继续跟进至HystrixRequestCache的get方法获取cache对应的value,我们先关注下其获取过程与当前的并发策略有关
获取返回值后会进行如下判断:
fromCache如果不为空,则直接返回cache中缓存的value值;
fromCache为空,则如果启用了requestCache并且设定了cacheKey则会进行cache存储
但首次调用其值必然为null,那么我们来看看是如何实现cache的存储的
通过putIfAbsent实现cache的存储
cache中存储值为HystrixCachedObservable实例,通过already能够判断是否已经有其他线程保存cache至,如果已经存储则为直接使用
小节:本小节即完成了cache的存储与cache的获取使用分析。
Hystrix是如何实现request cache的清除?
既然有存储和获取使用,那么必然有清除动作,本小节来看看,Hystrix又是如何对request cache实现清除的呢?有两种方案:
1、通过@HystrixCommand+@CacheRemove注解组合实现;
2、单用@CacheRemove注解实现;
通过@HystrixCommand+@CacheRemove注解组合实现
既然注解中有@HystrixCommand,根据上面的源码分析,代码的主体实现仍然是基于HystrixCommand作为线路的,我们直接找到AbstractHystrixCommand类,如下process方法在每次的调用链路中均会被执行,
可以看到其中明确调用了flushCache方法来实现cache的清除动作,其定义如下
其根据cacheRemoveInvocationContext判断是否需要清除cache,而cacheRemoveInvocationContext值在HystrixCommandBuilderFactory中通过metaHolder已经设定完成,具体在第一小节也有相关说明,
往下继续找到HystrixRequestCacheManager中的clearCache方法,
这里我们需要特别注意,在clear过程中,HystrixRequestCache实例采用了默认的并发策略,与我们存储时采用的并发可能不一致,在实际开发过程中默认的并发策略是无法满足需求的,此时我们执行下面的remove动作是无法clear成功的:
单用@CacheRemove注解实现
Hystrix对于没有@HystrixCommand注解的方法同样能够实现cache的清除功能,仅仅需要@CacheRemove一个注解即可。在源码中我们找到HystrixCacheAspect切面类,其作用就是清除request cache,下面来看下源码中的定义吧。
首先来看其切点定义
可以看到其切点定义明确说明了被@CacheRemove且不被@HystrixCommand注解方生效,再来看看其核心定义
这里的核心代码已经被红色框标出,其仍然是通过调用HystrixRequestCacheManager中的clearCache方法,此处与第一种方法最大的差异在于CacheInvocationContext来源差异,这里可以看到,在调用clearCache之前通过切点方法信息,构建了与HystrixCommandAspect中类似的MetaHolder实例,从而构建CacheInvocationContext实例。
这里有一个特别需要注意的,springcloud默认并没有帮我们注册HystrixCacheAspect实例,如果需要启用该切面,则需要注册HystrixCacheAspect对应的bean即可。
小节,结合源码的分析,在最后一步竟然可能会造成无法clear成功,有点失望,目前已经在Github中提了issue(https://github.com/Netflix/Hystrix/issues/1802),其实现如下扩展部分内容。
扩展
为了避免clearCache失败导致功能开发阻塞,故直接对其做了如下调整即可正常使用,后续等待官方确认回复:
其调整在HystrixRequestCacheManager的clearCache方法中展开,仅仅是通过HystrixPlugins来获取当前的并发策略而已。
原文:https://blog.csdn.net/songhaifengshuaige/article/details/80345072
相关推荐
Hystrix源码分析1 Hystrix是一个流行的熔断器工具,用于防止服务雪崩效应。它通过对方法的AOP拦截来实现熔断和降级。下面是Hystrix源码分析的主要知识点: 1. HystrixCommandAspect类 HystrixCommandAspect是...
在这个“Hystrix源码_可以跑起来”的主题中,我们将深入探讨Hystrix的工作原理、核心组件以及如何运行和调试其源代码。 首先,Hystrix的核心理念是将服务之间的调用封装在隔离的执行环境中,以避免单个依赖故障导致...
Hystrix源码简析:包括线程隔离和信号量隔离实现分析、熔断器实现分析等
1、Hystrix 源码解析 —— 调试环境搭建 2、Hystrix 源码解析 —— 执行命令方式 3、Hystrix 源码解析 —— 执行结果缓存 4、Hys
### Spring Cloud Hystrix & Dashboard 源码解读 #### 一、加载、初始化概要 ##### 1.1 @EnableCircuitBreaker 的生效 `@EnableCircuitBreaker` 注解是 Spring Cloud Hystrix 提供的一个关键注解,用于启动熔断器...
本篇将围绕SpringCloud的核心组件进行源码分析,包括Eureka服务注册与发现、Ribbon客户端负载均衡、Hystrix断路器、Zuul路由网关以及Config分布式配置中心,旨在帮助读者深入理解这些组件的工作原理。 一、Eureka:...
《Hystrix Dashboard 1.5.12:构建弹性微服务的重要工具》 Hystrix Dashboard 是 Netflix 开源的一款强大的监控工具,主要用于监控微服务架构中的 Hystrix 库的性能和健康状况。在标题提到的 "hystrix-dashboar...
本压缩包“微服务断路器hystrix应用实例java工程源码.zip”包含了一个基于Java实现的Hystrix应用实例,这个实例旨在帮助开发者理解和掌握如何在实际项目中集成和使用Hystrix。通过分析源码,我们可以深入学习以下几...
springcloud:Hystrix服务熔断demo源码案例演示
Hystrix是一个由Netflix开源的延迟和容错库,旨在隔离远程系统、服务和第三方库的访问点,停止级联失败,提供后备选项,并实现优雅降级。它在高并发的分布式系统中尤为重要,可以在复杂的系统中保证服务调用的稳定性...
spring-cloud-netflix-hystrix-dashboard-2.2.3.RELEASE.jar
在Spring Cloud生态系统中,Hystrix是一个至关重要的组件,它主要负责实现服务容错和断路器模式,以增强系统的稳定性和健壮性。本文将深入探讨如何在Spring Cloud项目中集成并使用Hystrix,以及如何将其与Feign...
《Hystrix监控异常处理全解析》 在分布式系统中,Spring Cloud Hystrix是一款非常重要的断路器框架,它能够有效地防止服务雪崩,保护系统稳定。然而,在实际使用过程中,我们可能会遇到Hystrix监控台报错的情况。...
在分布式系统中,服务间的调用异常处理是至关重要的,Spring Cloud Hystrix 就是为了解决这一问题而设计的。Hystrix 是 Netflix 开源的一个延迟和容错库,用于隔离服务间的调用,防止因某个服务的不稳定导致整个系统...
3. Hystrix源码:学习Hystrix如何实现断路器模式,如何监控服务的运行状态,以及熔断、降级和回退策略的实现。 4. Zuul或Spring Cloud Gateway源码:了解它们如何处理请求转发,实现API路由和过滤器,以及安全策略的...
【标题】"hystrix-dashboard.zip" 是一个包含示例代码的压缩包,与Spring Cloud相关的Hystrix Dashboard集成有关。Hystrix Dashboard是Netflix开源的一款监控工具,它能够帮助我们实时监控微服务架构中的断路器状态...
Spring Cloud Hystrix是一个由Netflix开源的Java框架,用于在分布式系统中提供延迟和容错功能,特别适用于对微服务架构中的远程过程调用(RPC)进行控制。其核心目标是通过添加一个延迟容忍层来隔离各个微服务之间的...
《深入理解Spring Cloud Netflix Hystrix:构建弹性微服务架构》 在当今的软件开发领域,微服务架构已经成为主流,而Spring Cloud作为Java生态中的微服务解决方案,深受开发者喜爱。其中,Spring Cloud Netflix ...
2. **创建Hystrix命令**:Hystrix的核心是命令(Command)模式,我们需要为每个服务调用创建一个HystrixCommand子类。在命令类中,定义执行业务逻辑的`run()`方法和备用的`fallback()`方法。`run()`方法是正常的业务...
### Hystrix简介 Hystrix 是一个由 Netflix 开发并开源的容错库,它旨在通过添加延迟容忍和容错逻辑来隔离服务之间的交互,从而提高系统的整体弹性和性能。在分布式系统中,服务之间通常会通过网络进行通信。然而,...