失效链接处理 |
SpringCloud服务容错保护(Hystrix)介绍与使用示例 PDF 下载
本站整理下载:
提取码:c22m
相关截图:
主要内容:
前言
前一章节,我们知道了如何利用RestTemplate+Ribbon和Feign的方式进行服务的调用。在微服务架构中,一个服务可能会调用很多的其他微服务应用,虽然做了多集群部署,但可能还会存在诸如网络原因或者服务提供者自身处理的原因,或多或少都会出现请求失败或者请求延迟问题,若服务提供者长期未对请求做出回应,服务消费者又不断的请求下,可能就会造成服务提供者服务崩溃,进而服务消费者也一起跟着不可用,严重的时候就发生了系统雪崩了。鉴于此,产生了断路器等一系列的服务保护机制。本章节,就来说下如何利用Hystrix进行容错处理。
一点知识
按照此系列的惯例,我们先来了解下一些相关的知识。
容错处理手段
容错处理是指软件运行时,能对由非正常因素引起的运行错误给出适当的处理或信息提示,使软件运行正常结束。
从百度百科的解释中可以看出,简单理解,所谓的容错处理其实就是捕获异常了,不让异常影响系统的正常运行,正如java中的try catch一样。
而在微服务调用中,自身异常可自行处理外,对于依赖的服务若发生错误,或者调用异常,或者调用时间过长等原因时,避免长时间等待,造成系统资源耗尽。一般上都会通过设置请求的超时时间,如http请求中的ConnectTimeout和ReadTimeout;再或者就是使用熔断器模式,隔离问题服务,防止级联错误等。
雪崩效应
在微服务架构中,存在很多的微服务单元,各个微服务之间通过网络进行通讯,难免出现依赖关系,若某一个单元出现故障,就很容易因依赖关系而引发故障的蔓延,产生“雪崩效应”,最终导致整个系统的瘫痪。
如图所示:A作为服务提供者,B为A的服务消费者,C和D是B的服务消费者。A不可用引起了B的不可用,并将不可用像滚雪球一样放大到C和D时,雪崩效应就形成了,也就应了那句话:星星之火,可以燎原!
熔断器
熔断器和现实生活中的空气开关作用很像。它可以实现快速失败,如果它在一段时间内侦测到许多类似的错误,会强迫其以后的多个调用快速失败,不再访问远程服务器,从而防止应用程序不断地尝试执行可能会失败的操作,使得应用程序继续执行而不用等待修正错误,或者浪费CPU时间去等到长时间的超时产生。熔断器也可以使应用程序能够诊断错误是否已经修正,如果已经修正,应用程序会再次尝试调用操作。
熔断器模式就像是那些容易导致错误的操作的一种代理。这种代理能够记录最近调用发生错误的次数,然后决定使用允许操作继续,或者立即返回错误。
可以看出,熔断器一共有三种状态,之间转换关系如下:
关闭状态当熔断器处于关闭状态时,请求是可以被放行的;当熔断器统计的失败次数触发开关时,转为打开状态。
打开状态当熔断器处于打开状态时,所有请求都是不被放行的,直接返回失败;只有在经过一个设定的时间窗口周期后,熔断器才会转换到半开状态
半开状态当熔断器处于半开状态时,当前只能有一个请求被放行;这个被放行的请求获得远端服务的响应后,假如是成功的,熔断器转换为关闭状态,否则转换到打开状态。
个人觉得,主要还是快速失败,避免请求堆积,压垮服务器。进而起到保护服务高可用的目的。
Hystrix实践
何为Hystrix
Hystrix是一个实现了超时机制和断路器模式的工具类库。
Hystrix是Netflix开源的一个延迟和容错库,用于隔离访问远程系统、服务或第三方库,防止级联失败,从而提升系统的可用性和容错性。
Hystrix容错机制:
包裹请求:使用HystrixCommand包裹对依赖的调用逻辑,每个命令在独立线程中执行,这是用到了设计模式“命令模式”。
跳闸机制:当某服务的错误率超过一定阈值时,Hystrix可以自动或手动跳闸,停止请求该服务一段时间。
资源隔离:Hystrix为每个依赖都维护了一个小型的线程池,如果该线程池已满,发往该依赖的请求就被立即拒绝,而不是排队等候,从而加速判定失败。
监控:Hystrix可以近乎实时的监控运行指标和配置的变化。如成功、失败、超时、被拒绝的请求等。
回退机制:当请求失败、超时、被拒绝,或当断路器打开时,执行回退逻辑。回退逻辑可自定义。
自我修复:断路器打开一段时间后,会自动进入半开状态,断路器打开、关闭、半开的逻辑转换。
下图就是Hystrix的回退策略,防止级联故障。
|