Hystrix介绍

Hystrix介绍

在分布式系统中往往存在着大量的服务依赖关系,其中不可避免的会出现部分服务因为发生故障而无法正常提供服务。这时候调用方如果没有对被依赖服务的故障进行有效的隔离,那么可能将当前服务所在容器的资源消耗殆尽,进而引发上一级的服务出现问题,最后有可能导致整个系统发生雪崩效应。为了应对这种情况,我们需要对依赖服务进行降级处理,同时对被依赖服务故障进行隔离。

Hystrix是Netflix开源的服务故障隔离、恢复、监控和报警的组件。Hystrix通过添加对被依赖服务延迟和故障处理逻辑控制服务间的交互,进而提高整个系统的稳定性。  

 

Hystrix的作用

在复杂的分布式系统中往往有大量的服务依赖,在这众多的服务中不可避免得会发生部分服务出现故障的问题。这时候如果主服务没有对被依赖的服务故障进行隔离,那么可能会因为被依赖服务出现的故障拖垮主服务自身。

系统中所有服务都运行良好时,整个依赖关系可以使用下图进行描述:

系统中只要出现一个服务访问延迟,都可能阻塞住整个用户访问请求。

在一个高负载的系统中,一个服务访问延迟可以在短时间内将整个系统的资源消耗殆尽。在程序中无论是直接的网络访问,还是调用第三方的库都是潜在的故障发生点。这些潜在点的故障甚至调用延迟都可能使系统中的队列被塞满消息,容器的线程被大量消耗,进而影响到系统中其他服务的稳定。

 总的来说,hystrix提供了以下这些功能帮组我们应对这种情况:

  • 包裹请求:使用HystrixCommand(或者HystrixObservableCommand)包裹对依赖的调用逻辑,每个命令在独立线程中执行。这使用了设计模式中的“命令模式”。
  • 跳闸机制:当某服务的错误率超过一定阀值时,Hystrix可以自动或者手动跳闸,停止请求该服务一段时间。
  • 资源隔离:Hystrix为每个依赖都维护了一个小型的线程池(或者信号量)。如果该线程池已满,发往该依赖的请求就被立即拒绝,而不是排队等候,从而加速失败判断
  • 监控:Hystrix可以近乎实时地监控运行指标和配置的变化,例如成功、失败、超时、以及被拒绝的请求等。
  • 回退机制:当请求失败、超时、被拒绝,或当断路器打开时,执行回退逻辑。回退逻辑可由开发人员自行提供,例如返回一个缺省值。
  • 自我修复:断路器打开一段时间后,会自动进入“半开”状态。

 

Hystrix的设计理念

设计理念的先进与否直接决定了开源组件的生命周期长短。在了解了hystrix的众多优秀功能后,我们有必要深入了解一下hystrix背后的设计理念。正是这些优秀的设计理念奠定了hystrix在服务熔断开源解决方案中的霸主地位。

hystrix设计理念概要:

  • 控制单一依赖对容器线程资源的消耗
  • 消峰和快速失败返回而不是进行排队操作
  • 在故障发生时提供默认值的返回
  • 使用故障(延迟)隔离技术手段防止对其他服务产生重大影响
  • 通过实时的统计、监控和报警优化故障恢复

 

Hystrix的基本实现

总体看来整个hystrix通过以下这些具体的实现细节完成服务故障、服务延迟的隔离、实时搜集和统计。

  • 使用HystrixCommand或则HystrixObservableCommand将所有对被依赖服务的调用包装在独立的线程中执行
  • 在被依赖服务调用耗时超过配置的超时时长时直接进行超时处理
  • 为每个依赖调用维护一个线程池(信号量),在队列满时直接丢弃调用
  • 维护依赖调用成功、失败、超时和丢弃的统计信息
  • 当被依赖服务调用出错比率超过配置的值时触发熔断器,在配置的时间段内中断对被依赖服务的调用
  • 在依赖调用失败、超时、被丢弃或则启动熔断器时提供恢复逻辑
  • 实时监控配置和统计数据的变化

 

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值