前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Netflix Hystrix断路器简介与工作原理

Netflix Hystrix断路器简介与工作原理

作者头像
KenTalk
发布2018-09-11 11:34:12
10.8K0
发布2018-09-11 11:34:12
举报
文章被收录于专栏:Ken的杂谈

一、前言?

1、Netflix Hystrix断路器是什么?

Netflix Hystrix是SOA/微服务架构中提供服务隔离、熔断、降级机制的工具/框架。Netflix Hystrix是断路器的一种实现,用于高微服务架构的可用性,是防止服务出现雪崩的利器。

2、为什么需要断路器?

在分布式架构中,一个应用依赖多个服务是非常常见的,如果其中一个依赖由于延迟过高发生阻塞,调用该依赖服务的线程就会阻塞,如果相关业务的QPS较高,就可能产生大量阻塞,从而导致该应用/服务由于服务器资源被耗尽而拖垮。

另外,故障也会在应用之间传递,如果故障服务的上游依赖较多,可能会引起服务的雪崩效应。就跟数据瘫痪,会引起依赖该数据库的应用瘫痪是一样的道理。


当一个应用依赖多个外部服务,一切都正常的情况下,如下图:

如果其中一个依赖发生延迟,当前请求就会被阻塞

出现这种情况后,如果没有应对措施,后续的请求也会被持续阻塞

每个请求都占用了系统的CPU、内存、网络等资源,如果该应用的QPS较高,那么该应用所以的服务资源会被快速消耗完毕,直至应用死掉。如果这个出问题的依赖(Dependency I),不止这一个应用,亦或是受影响的应用上层也有更多的依赖,那就会带来我们前面所提到的服务雪崩效应。

所以,为了应对以上问题,就需要有支持服务隔离、熔断等操作的工具

二、Hystrix 简介

1、Hystrix具备哪些能力/优点?

  • 在通过网络依赖服务出现高延迟或者失败时,为系统提供保护和控制
  • 可以进行快速失败,缩短延迟等待时间和快速恢复:当异常的依赖回复正常后,失败的请求所占用的线程会被快速清理,不需要额外等待
  • 提供失败回退(Fallback)和相对优雅的服务降级机制
  • 提供有效的服务容错监控、报警和运维控制手段

2、Hystrix 如何解决级联故障/防止服务雪崩?

  • Hystrix将请求的逻辑进行封装,相关逻辑会在独立的线程中执行
  • Hystrix有自动超时策略,如果外部请求超过阈值,Hystrix会以超时来处理
  • Hystrix会为每个依赖维护一个线程池,当线程满载,不会进行线程排队,会直接终止操作
  • Hystrix有熔断机制: 在依赖服务失效比例超过阈值时,手动或者自动地切断服务一段时间

所以,当引入了Hystrix之后,当出现某个依赖高延迟的时候:

三、Hystrix 工作原理

1、Hystrix工作流

  • 1、创建HystrixCommand 或者 HystrixObservableCommand 对象
  • 2、执行命令execute()、queue()、observe()、toObservable()
  • 3、如果请求结果缓存这个特性被启用,并且缓存命中,则缓存的回应会立即通过一个Observable对象的形式返回
  • 4、检查熔断器状态,确定请求线路是否是开路,如果请求线路是开路,Hystrix将不会执行这个命令,而是直接执行getFallback
  • 5、如果和当前需要执行的命令相关联的线程池和请求队列,Hystrix将不会执行这个命令,而是直接执行getFallback
  • 6、执行HystrixCommand.run()或HystrixObservableCommand.construct(),如果这两个方法执行超时或者执行失败,则执行getFallback()
  • 7、Hystrix 会将请求成功,失败,被拒绝或超时信息报告给熔断器,熔断器维护一些用于统计数据用的计数器。

这些计数器产生的统计数据使得熔断器在特定的时刻,能短路某个依赖服务的后续请求,直到恢复期结束,若恢复期结束根据统计数据熔断器判定线路仍然未恢复健康,熔断器会再次关闭线路。

依赖隔离

Hystrix采用舱壁隔离模式隔离相互之间的依赖关系,并限制对其中任何一个的并发访问。

线程&线程池

客户端(通常指Web应用)通过网络请求依赖时,Hystrix会将请求外部依赖的线程与会将App容器(Tomcat/Jetty/…)线程隔离开,以免请求依赖出现延迟时影响请求线程。

Hystrix会为每个依赖维护一个线程池,当线程满载,不会进行线程排队,会Return fallback或者抛出异常

可能会有人有疑问,为什么不依赖于HTTP Client去做容错保护(快速失败、熔断等),而是在访问依赖之外通过线程&线程池隔离的方式做这个断路器(Hystrix)。

主要是以下几个方面:

  1. 不同的依赖执行的频率不同,需要分开来对待
  2. 不同的依赖可能需要不同的Client的工具/协议来访问,比如我们可能用HTTP Client,可能用Thrift Client。
  3. Client在执行的过程中也可能会出现非网络异常,这些都应该被隔离
  4. Client的变化会引起断路器的变化

所以,Hystrix这样设计的好处是:

  1. 断路器功能与不同的Client Library隔离
  2. 不同依赖之间的访问互不影响
  3. 当发生大量异常时,不会造成App Container的响应线程排队,并且当异常的依赖恢复正常后,失败的请求所占用的线程会被快速清理,不需要额外等待
  4. 为不支持异步的依赖提供了异步的可能

这样做的成本是,多了一些线程上的资源消耗(排队,调度和上下文切换),不过从官方给到的数据上可能,这个消耗完全可以接受。目前Netflix每天有100亿+的Hystrix命令执行,平均每个应用实例都有40+个线程池。每个线程池有5-20个线程

依然运行良好(不过这里 ken.io 不得不吐槽下,官方没有透露单个实例硬件配置)

官方给了一组测试数据,在单个应用实例60QPS,且每秒钟有350个Hystix子线程(350次Hystrix Command执行)的情况下。Hystrix的线程成本通常为0-3ms,如果CPU使用率超过90%,这个线程成本为有所上升约为9ms。相对于网络请求的时间消耗,这个成本完全可以接受。

四、备注

本文参考
延伸阅读
本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2018/05/03 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、前言?
    • 1、Netflix Hystrix断路器是什么?
      • 2、为什么需要断路器?
      • 二、Hystrix 简介
        • 1、Hystrix具备哪些能力/优点?
          • 2、Hystrix 如何解决级联故障/防止服务雪崩?
          • 三、Hystrix 工作原理
            • 1、Hystrix工作流
              • 依赖隔离
                • 本文参考
                • 延伸阅读
            • 四、备注
            相关产品与服务
            数据库
            云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
            领券
            问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档