Hystrix介绍
在分布式系统中往往存在着大量的服务依赖关系,其中不可避免的会出现部分服务因为发生故障而无法正常提供服务。这时候调用方如果没有对被依赖服务的故障进行有效的隔离,那么可能将当前服务所在容器的资源消耗殆尽,进而引发上一级的服务出现问题,最后有可能导致整个系统发生雪崩效应。为了应对这种情况,我们需要对依赖服务进行降级处理,同时对被依赖服务故障进行隔离。
Hystrix是Netflix开源的服务故障隔离、恢复、监控和报警的组件。Hystrix通过添加对被依赖服务延迟和故障处理逻辑控制服务间的交互,进而提高整个系统的稳定性。
Hystrix的作用
在复杂的分布式系统中往往有大量的服务依赖,在这众多的服务中不可避免得会发生部分服务出现故障的问题。这时候如果主服务没有对被依赖的服务故障进行隔离,那么可能会因为被依赖服务出现的故障拖垮主服务自身。
系统中所有服务都运行良好时,整个依赖关系可以使用下图进行描述:
image.png
系统中只要出现一个服务访问延迟,都可能阻塞住整个用户访问请求。
image.png
在一个高负载的系统中,一个服务访问延迟可以在短时间内将整个系统的资源消耗殆尽。在程序中无论是直接的网络访问,还是调用第三方的库都是潜在的故障发生点。这些潜在点的故障甚至调用延迟都可能使系统中的队列被塞满消息,容器的线程被大量消耗,进而影响到系统中其他服务的稳定。
image.png
总的来说,hystrix提供了以下这些功能帮组我们应对这种情况:
- 包裹请求:使用HystrixCommand(或者HystrixObservableCommand)包裹对依赖的调用逻辑,每个命令在独立线程中执行。这使用了设计模式中的“命令模式”。
- 跳闸机制:当某服务的错误率超过一定阀值时,Hystrix可以自动或者手动跳闸,停止请求该服务一段时间。
- 资源隔离:Hystrix为每个依赖都维护了一个小型的线程池(或者信号量)。如果该线程池已满,发往该依赖的请求就被立即拒绝,而不是排队等候,从而加速失败判断
- 监控:Hystrix可以近乎实时地监控运行指标和配置的变化,例如成功、失败、超时、以及被拒绝的请求等。
- 回退机制:当请求失败、超时、被拒绝,或当断路器打开时,执行回退逻辑。回退逻辑可由开发人员自行提供,例如返回一个缺省值。
- 自我修复:断路器打开一段时间后,会自动进入“半开”状态。
Hystrix的设计理念
设计理念的先进与否直接决定了开源组件的生命周期长短。在了解了hystrix的众多优秀功能后,我们有必要深入了解一下hystrix背后的设计理念。正是这些优秀的设计理念奠定了hystrix在服务熔断开源解决方案中的霸主地位。
hystrix设计理念概要:
- 控制单一依赖对容器线程资源的消耗
- 消峰和快速失败返回而不是进行排队操作
- 在故障发生时提供默认值的返回
- 使用故障(延迟)隔离技术手段防止对其他服务产生重大影响
- 通过实时的统计、监控和报警优化故障恢复
Hystrix的基本实现
总体看来整个hystrix通过以下这些具体的实现细节完成服务故障、服务延迟的隔离、实时搜集和统计。
- 使用HystrixCommand或则HystrixObservableCommand将所有对被依赖服务的调用包装在独立的线程中执行
- 在被依赖服务调用耗时超过配置的超时时长时直接进行超时处理
- 为每个依赖调用维护一个线程池(信号量),在队列满时直接丢弃调用
- 维护依赖调用成功、失败、超时和丢弃的统计信息
- 当被依赖服务调用出错比率超过配置的值时触发熔断器,在配置的时间段内中断对被依赖服务的调用
- 在依赖调用失败、超时、被丢弃或则启动熔断器时提供恢复逻辑
- 实时监控配置和统计数据的变化
网友评论