iis默认网站打不开,综合电商网站建设需求文档,产品营销推广策略,广州冼村和猎德村哪个最有钱目录
Hystrix的主要功能
传统容错手段
超时机制
应用容错三板斧
超时机制
舱壁隔离
熔断降级
侵入式Command用法
改进版一#xff1a;ribbon与hystrix组合
改进版二#xff1a;feign与hystrix组合
Hystrix三态转换图
源码分析
流程图
原理流程图
核心实现流程…目录
Hystrix的主要功能
传统容错手段
超时机制
应用容错三板斧
超时机制
舱壁隔离
熔断降级
侵入式Command用法
改进版一ribbon与hystrix组合
改进版二feign与hystrix组合
Hystrix三态转换图
源码分析
流程图
原理流程图
核心实现流程图
入口
HystrixCircuitBerakerConfiguration
如何做功能增强
HystrixCommand注解的切面逻辑
CommandExecutor#execute()
HystrixCommand#execute()
applyHystrixSemantics()熔断器核心逻辑
流程图
熔断器打开时
熔断器关闭时
线程隔离有两种隔离模式
信号量隔离逻辑
线程池隔离逻辑
线程池隔离原理
熔断器源码
流程图
熔断器初始化
熔断器判断机制
如何进入半开状态
滑动时间窗口
原理图
相关配置参数
监控数据收集 Hystrix的主要功能 线程池隔离、熔断降级、超时降级、宕机降级 传统容错手段
超时机制
是设置RestTemplate的连接超时和读取超时这是我们在没有使用hytrix这些辅助的分布式工具时的做法 全局异常处理器
控制器中捕获超时异常封装成统一的自定义异常并再次抛出让全局异常处理器来进行处理 上面这种就是传统的容错的处理套路 应用容错三板斧 超时机制
以前没有hytrix的时候就是直接给RestTemplate设置一个超时时间RestTemplate调用超时时会抛出TimeoutException然后我们直接catch到此异常就直接把同步阻塞的调用线程掐死 舱壁隔离
说白了就是资源隔离比如线程池隔离 熔断降级 当一段时间内失败次数达到一定阈值那么熔断器就会打开此时主业务线程就不会再去调用真正的远程的业务方法而是直接调用本地早已写好的“降级方法”返回一个可预知的结果。也就是说熔断是结果降级是处理的手段 侵入式Command用法
我们只会下单、支付、调库存等核心高频接口才需要进行降级才需要自己在本地写降级方法 这样当前端看到返回的订单的订单号为-1时就可以给客户展示一个友好的页面比如当前系统开了小差之类的 原始的hytrix API处理熔断降级时就需要这样的强侵入式写法 改进版一ribbon与hystrix组合 这里可以配置线程池 改进版二feign与hystrix组合
feign调用时通过hystrix进行降级 Hystrix的默认配置跳闸阈值 上面就是可能会发生降级的三种情况分别是宕机降级、超时降级、异常降级 生产上上面的配置一般不动使用默认的配置值 Hystrix三态转换图 默认失败比例超过50%则会打开熔断器 熔断时间窗口结束后熔断器状态就从打开转换到半开状态此时会放过一条请求去请求真正的远程业务方法如果此次调用成功则熔断器状态就转成关闭状态如果此次调用任失败那么熔断器就又会回到打开状态什么叫调用失败客户端去调用服务端接口API服务端抛了异常并且没有catch直接抛了出来、服务器宕机、服务端接口业务执行耗时太多导致客户端等待接口返回超时半开状态存在的意义就是为了让熔断器有机会回到关闭状态也就是回到能正常去远程调用的状态 这个就是工作中需要配置的ribbon的超时时间配置了ribbon的超时时间那么restTemplate也自动跟随ribbon的超时时间了 这些参数的设置就供学习平时生产大多使用默认参数 如何关闭hystrix对feign的支持 这里需要hystrix的超时时间需要设置为6000 生产上需要 hystrix的超时时间 (本次调用次数 1 出现异常时对当前实例的重试次数 1 切换实例后的重试次数 1 * ribbon的超时时间 3 * ribbon的超时时间 因为hystrix要保证所有的ribbon调用重试都结束后hystrix再去插断主线程的调用并给主线程返回降级结果 第89行把总体的熔断机制的打开
第92行可以开始选择某一个方法关闭熔断机制剩下的就是局部开启的
注意上面参数赋值用等号 源码分析 流程图
原理流程图 核心实现流程图 入口 通过框架的启动注解开始实际上这个注解内部就是通过Import注解去加载spring.factories中以EnableCircuitBreaker为key的“普通配置类” 这个ImportSelector的作用就是去找Netflix-core.jar下的spring.factories中以EnableCircuitBreaker为key的键值对将该key对应的值为一个普通配置类HystrixCircuitBerakerConfiguration将它注入到ioc容器中来 因为Springboot默认的自动配置类读取功能仅仅只是读取所有jar包下spring.factories中以EnableAutoConfigurationr为key的“自动配置类”各个第三方组件自定义的一些key下所属的“普通配置类”Springboot是不负责读取的需要各个第三方组件自己开发针对该key的加载功能普通配置类以XxxxxConfiguration命名自动配置类以XxxxxAutoConfiguration命名 业务系统首先引入这个starter-netflix-hystrix这个starter相当于一个聚合器内部聚合了很多别的功能jar包
这些带有spring-cloud-开头的就是spring cloud官方为了整合Netflix hystrix组件而开发的自动装配包 优先看与核心功能相关的配置类比如这里就优先看HystrixCircuitBreakerConfiguration类像这种HystrixSecurityAutoConfiguration一看就是与安全有关的非主功能我们就先不看这些都是看源码的技巧 HystrixCircuitBerakerConfiguration 如何做功能增强 无非就是用代理AOP横切拦截或者加待增强对象所拥有的拦截器链中加一个拦截器/过滤器 HystrixCommand注解的切面逻辑
这一段切面逻辑也就是每一个被HystrixCommand注解修饰的方法在被调起之前都会先走一遍这个切面增强逻辑。而这一段切面增强逻辑实际上也就是Hystrix熔断器起作用的逻辑
注意这都是在客户端执行的代码也就是请求发起方此时还没有到接口提供方服务端 第90行同时会拦截HystrixCommand还有合并请求的HystrixCollapser 第96行会创建一个HystrixInvokable如下是第96行的create()逻辑 GenericCommand命令模式对象中有两个核心方法一个就是run()也就是正常的业务逻辑方法另一个就是getFallback()也就是降级方法getFallback()内部会通过反射调用HystrixCommand中配置的fallBackMethod方法
从这里也知道返回的HystrixInvokable实际上就是一个GenericCommand 截止以上的流程图 CommandExecutor#execute() HystrixCommand#execute() queue()返回一个Future凭证从这里开始就是一堆的响应式变成了各种定义监听与事件响应执行来串起整个执行流程 上述流程对应的流程图 响应式编程的定义语法rxJava响应式编程框架手机上用的比较多响应式编程说白了就是一堆的观察者模式zookeeper里面的节点内容变化也会触发监听器执行这都是观察者模式 总体原理就是Observable是被观察者Observer是观察者当被观察者发生变化时就会回调观察者 这里就把34行就当做定义了一个观察者45行就定义了一个被观察者 这里把观察者注册绑定到被观察者上以后被观察者发生不同事件就会回调不同的观察者的call()方法
这里就是被HystrixCommand注解修饰的方法在发起一次调用时如果调用的方法正常返回 这里就出现了一个核心观察者applyHystrixSemantics() applyHystrixSemantics()熔断器核心逻辑
流程图 熔断器打开时 当发现当前熔断器是打开状态则调用FallBack方法也就是调用GenericCommand的getFallBack()方法getFallBack()方法会去找到HystrixCommand中配置的fallBackMethod方法并执行这个fallBackMethod方法方法最终就是通过方法名通过反射来调用到fallBackMethod方法的 第523行判断当前熔断器状态是否为打开状态 第523行判断当前熔断器状态是关闭状态则走524行开始的逻辑如果判断熔断器当前是打开状态则走557行的FallBack逻辑也就是调用降级逻辑 判断当前熔断器状态是否为打开状态
熔断器可以强制配置为关闭但是这里代码写的有点难理解与正常思维判断逻辑是个反的 熔断器关闭时 线程隔离有两种隔离模式 一种是信号量的隔离模式信号量计数器满了以后也会走降级逻辑一种是线程池的隔离模式线程池满了以后也会走降级逻辑 信号量隔离逻辑 信号量的隔离模式下如果542行获取信号量失败则执行554行的信号量拒绝FallBack但是现实中基本都用线程池隔离模式 线程池隔离逻辑
这是在没有配置信号量策略时 如果没有配置信号量那么下面的第542行会一直返回true从而进入真正的线程池隔离的逻辑 executeCommandAndObserve() getUserExecutionObservable()方法中就有监听回调方法回调方法内部就会通过线程池线程调用GenericCommand的run() 线程池隔离原理 大体流程用户在调用findById()方法时hystrix写的AOP切面类会拦截这个注解拦截这个注解后会初始化一个GenericCommand命令在初始化这个GenericCommand命令内部就会通过这些线程池的配置来初始化该命令特有的执行线程池 上上图HystrixCommand注解中的所有信息默认就会被保存在这个元信息MetaHolder中去Spring的代码都是很统一的这种注解的元数据一般都是用MetaXxxxx来保存的
这里就通过注解的元信息来构造了一个GenericCommand命令。GenericCommand是AbstractCommand的子类 AbstractCommand HystrixCommand注解中的所有信息默认就会被保存在这个元信息MetaHolder中从这些元信息中就能获得到threadPoolProperties信息
这里就会用到threadPoolKey 所以这里就实现了有多少key就会初始化出来多少个线程池也就实现了通过key的不同来实现不同粒度的隔离
如果有多个业务方法配置了相同的key那么也就实现了多个hystrix方法公用了同一个线程池 线程池缓存的技术
以后线程池隔离执行时就是把当前的GenericCommand#run()方法丢进这个threadPool中去执行的 利用线程池缓存的技术实现多个用户方法公用同一个线程池的目的只需要多个方法配置相同的commandKey和threadPoolKey 熔断器源码
hytrix的熔断器是可以直接关掉不启用的 流程图 熔断器初始化 每个命令对象都有自己专属的熔断器也有自己专属的线程池 如果没有设置启用熔断器则直接返回NoOpCircuitBreaker 从这里也能看到 是每一个CommandKey方法都有对应自己唯一的熔断器互相之间不影响不会出现一个方法的熔断器打开了影响到了别的方法的调用执行 熔断器判断机制 每一次请求调用都会走这个onNext()方法
第179行判断时间窗口内的所有请求是否小于滑动窗口能触发熔断的最小请求数如果小于则代码直接跳过不做任何操作也就是不做打开熔断器的逻辑
第185行说明样本数达标了20个
第186行如果错误率小于配置的错误率值比如小于50%直接跳过不做任何操作第192行如果错误率大于配置的错误率值比如小于50%打开熔断器并给熔断器记录下当前打开时的时间戳circuitOpened因为熔断器打开后有个默认5s的持续超过5s后进入半开状态放一个请求过去 如何进入半开状态 判断当前时间是否超过熔断器睡觉的5s
如果熔断器睡觉超过5s则把熔断器置为半开状态 滑动时间窗口
这个滑动时间窗口也可以用来实现限流策略 原理图 相关配置参数 numbuckets就是为了调整时间的统计粒度统计粒度越细则熔断器对于网络堵塞等异常状态的感应就更加灵敏
滑动窗口触发熔断的最小请求数这个是整个时间窗口内的这是一种兜底策略 监控数据收集 上图画反了下图是对的 对应源码如下 每次请求都会走上面的判断逻辑
第643行给execution注册了一个doOnCompleted事件这个事件就会在当前请求顺利执行成功后就会回调这个事件对应的回调方法也就是下面这段逻辑 每次请求调用成功没有抛异常就会调用这个回调方法这个回调方法内部就会调用断路器HystrixCircuitBreakerImpl的markSuccess()方法进行调用数据上报数据统计中心 第207行是上报本次调用数据比如本次调用是调用成功、熔断器拒绝、线程池拒绝等等不同请求都需要上报Metrics
如果当前是半开状态则关闭熔断器
