Hystrix简介

        hystrix对应的中文名字是“豪猪”,豪猪周身长满了刺,能保护自己不受天敌的伤害,代表了一种防御机制,这与hystrix本身的功能不谋而合,因此Netflix团队将该框架命名为Hystrix,并使用了对应的卡通形象做作为logo。

1. Hystrix是什么?

        在分布式环境中,许多服务依赖的一些服务中不可避免地会存在一些失败的情况。 Hystrix是这样一个框架,通过添加容忍延迟和容错逻辑,可帮助我们控制这些分布式服务之间的交互。 Hystrix通过隔离各个服务之间的访问点,减少服务之间的级联故障以及为我们提供回滚策略来实现这一点,所有这些都可以提高分布式系统的整体弹性。

1.1 Hystrix的历史

        Hystrix从Netflix API团队在2011年开始的弹性工程演变而来。2012年,Hystrix继续发展和成熟,Netflix内的许多团队都采用了它。 如今,Netflix每天都会通过Hystrix执行数百亿线程隔离和数千亿次信号隔离调用。 这导致了分布式系统正常运行时间和弹性的显着改善。

        以下链接提供了有关Hystrix的更多上下文以及它试图解决的挑战:

1.2 Hystrix的目标是什么?

Hystrix是为了解决以下问题的:                 

  • 通过第三方客户端库(通常通过网络)访问依赖关系,从而对延迟和故障进行保护和控制。
  • 停止复杂分布式系统中的级联故障。
  • 失败迅速并迅速恢复。
  • 可能的情况下回退并优雅地降级。
  • 启用近实时监控,警报和操作控制。

1.3 Hystrix能解决什么问题

        复杂分布式系统架构中的应用程序具有许多服务依赖关系,每个依赖关系在都可能在某些时候不可避免地失败。 如果主机应用程序不与这些外部故障隔离开来,则有可能被被这些外部故障拖垮。

    例如,对于依赖30个服务的应用程序,每个服务的正常运行时间为99.99%,那么以下将是你期望的值:

    系统正常运行的时间 = 99.99 ✖️ 99.99 ✖️99.99 ✖️······99.99 = 99的30次方 = 99.7%

    系统异常运行的时间 = 0.3%

    假设系统有10亿次请求

    那么在这10亿次请求中失败的次数 = 10亿 ✖️0.3% =  3,000,000次失败

        即使所有的依赖服务都按照正常的概率运行,那么系统每个月至少也有2小时以上的时间是异常的。在实际的生产环境中,情况可能更糟。

        即使所有依赖性都能很好地发挥作用,如果您不设计整个系统的弹性,那么几十项服务中的每一项即使有0.01%的时间宕机,那么总体影响等同于每月停机时间可能达到的小时数。

        当系统所依赖的所有服务都很健壮的情况下,请求的流程如下图所示:


当系统依赖的服务中出现一个延迟的服务的时候,这个延迟的服务可能会对整个用户请求造成影响如下图所示:



        对于高流量场景,单个后端依赖出现延迟可能导致所有服务器上的所有资源在数秒内达到饱和状态。

        应用程序中的每个点都可以通过网络传播或可能通过网络请求的客户端库进行传播,这是潜在失败的根源。 比失败更糟糕的是,这些应用程序还可能导致服务之间的延迟增加,从而备份队列,线程和其他系统资源耗尽,从而导致整个系统发生更多级联故障。


        当通过第三方客户端执行网络访问时,这些问题会加剧 - 实施细节隐藏且随时可能更改的“黑匣子”,并且每个客户端库的网络或资源配置都不同,并且通常难以监控和 更改。

        更糟糕的是,传递依赖性执行潜在的代价昂贵的或容易出错的网络调用,而不会被应用程序明确调用。

        网络连接失败或降级。 服务和服务器失败或变得缓慢。 新的库或服务部署会改变行为或性能特征。 客户端库存在bug。

        所有这些都表示需要进行对依赖项进行隔离,合理的管理故障和延迟,以便单个失败的依赖关系都无法拖垮整个应用程序或系统。

1.4 Hystrix设计的原则是什么?

  • 防止任何单个依赖项耗尽容器中(如Tomcat)所有的用户线程。
  • 切断负载并快速失败而不是让请求排队。
  • 尽可能提供回退以保护用户免受故障。
  • 使用隔离技术(例如隔板,泳道和断路器模式)来限制任何一种依赖的影响。
  • 通过接近实时的指标,监控和警报来优化发现时间。
  • 通过配置更改的低延迟传播优化恢复时间,并支持Hystrix大多数方面的动态属性更改,这使您可以通过Hystrix反馈进行实时操作修改。
  • 防止整个依赖客户端执行失败,而不仅仅是网络流量。

猜你喜欢

转载自blog.csdn.net/shixuetanlang/article/details/80034656