京东技术:Hystrix 分布式系统限流、降级、熔断框架

IT实战联盟 2019-03-06 17:22:25 ⋅ 376 阅读
为什么需要Hystrix


在大中型分布式系统中,通常系统很多依赖,如下图:



在高并发访问下,这些依赖的稳定性与否对系统的影响非常大,但是依赖有很多不可控问题:如网络连接缓慢,资源繁忙,暂时不可用,服务脱机等,如下图:



当依赖阻塞时,大多数服务器的线程池就出现阻塞,影响整个线上服务的稳定性,如下图:



在复杂的分布式架构的应用程序有很多的依赖,都会不可避免地在某些时候失败。高并发的依赖失败时如果没有隔离措施,当前应用服务就有被拖垮的风险。



Hystrix如何解决依赖隔离


  • Hystrix使用命令模式HystrixCommand(Command)包装依赖调用逻辑,每个命令在单独线程中/信号授权下执行。

  • 可配置依赖调用超时时间,超时时间一般设为比99.5%平均时间略高即可。当调用超时时,直接返回或执行fallback逻辑。

  • 为每个依赖提供一个小的线程池或信号,如果线程池已满调用将被立即拒绝,默认不采用排队。加速失败判定时间。

  • 依赖调用结果分:成功、失败/抛出异常、超时、线程拒绝、短路。 请求失败(异常,拒绝,超时,短路)时执行fallback(降级)逻辑。

  • 提供熔断器组件,可以自动运行或手动调用,停止当前依赖一段时间(10秒),熔断器默认错误率阈值为50%,超过将自动运行。

  • 提供近实时依赖的统计和监控。




Hystrix依赖的隔离架构,如下图:


如何使用Hystrix



  使用maven引入Hystrix依赖   

    <hystrix.version>1.3.16</hystrix.version> <hystrix-metrics-event-stream.version>1.1.2</hystrix-metrics-event-stream.version> 

    <dependency> <groupId>com.netflix.hystrix</groupId> <artifactId>hystrix-core</artifactId> <version>${hystrix.version}</version> </dependency> <dependency> <groupId>com.netflix.hystrix</groupId> <artifactId>hystrix-metrics-event-stream</artifactId> <version>${hystrix-metrics-event-stream.version}</version> </dependency>



  使用命令模式封装依赖逻辑 

 

    public class HelloWorldCommand extends HystrixCommand<String> {  private final String name;  public HelloWorldCommand(String name) {  //最少配置:指定命令组名(CommandGroup)  super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"));  this.name = name;  }  @Override  protected String run() {  // 依赖逻辑封装在run()方法中  return "Hello " + name +" thread:" + Thread.currentThread().getName();  }  //调用实例  public static void main(String[] args) throws Exception{  //每个Command对象只能调用一次,不可以重复调用,  //重复调用对应异常信息 HelloWorldCommand helloWorldCommand = new HelloWorldCommand("sync-hystrix");  //使用execute()同步调用代码,效果等同于:helloWorldCommand.queue().get();  String result = helloWorldCommand.execute();  System.out.println("result=" + result); 

    helloWorldCommand = new HelloWorldCommand("async-hystrix"); //异步调用,可自由控制获取结果时机, Future<String> future = helloWorldCommand.queue(); //get操作不能超过command定义的超时时间,默认:1秒 result = future.get(100, TimeUnit.MILLISECONDS); System.out.println("result=" + result); System.out.println("mainThread=" + Thread.currentThread().getName()); } }


  使用Fallback() 提供降级策略   



    //重载HystrixCommand的getFallback方法实现逻辑 public class HelloWorldCommand extends HystrixCommand<String> {  private final String name;  public HelloWorldCommand(String name) {  super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("HelloWorldGroup")) .andCommandPropertiesDefaults(HystrixCommandProperties.Setter() .withExecutionIsolationThreadTimeoutInMilliseconds(500)));  this.name = name;  }  @Override  protected String getFallback() {  return "exeucute Falled";  }  @Override  protected String run() throws Exception {  //sleep 1 秒,调用会超时  TimeUnit.MILLISECONDS.sleep(1000);  return "Hello " + name +" thread:" + Thread.currentThread().getName();  }  public static void main(String[] args) throws Exception{  HelloWorldCommand command = new HelloWorldCommand("test-Fallback");  String result = command.execute();  } }

NOTE: 除了HystrixBadRequestException异常之外,所有从run()方法抛出的异常都算作失败,并触发降级getFallback()和断路器逻辑。

HystrixBadRequestException用在非法参数或非系统故障异常等不应触发回退逻辑的场景。


  依赖命名:CommandKey


    public HelloWorldCommand(String name) {  super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"))  /* HystrixCommandKey工厂定义依赖名称 */  .andCommandKey(HystrixCommandKey.Factory.asKey("HelloWorld")));  this.name = name; }


NOTE: 每个CommandKey代表一个依赖抽象,相同的依赖要使用相同的CommandKey名称。依赖隔离的根本就是对相同CommandKey的依赖做隔离。


  依赖分组:CommandGroup   


命令分组用于对依赖操作分组,便于统计,汇总等。

    //使用HystrixCommandGroupKey工厂定义 public HelloWorldCommand(String name) {  Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("HelloWorldGroup")) } 

NOTE: CommandGroup是每个命令最少配置的必选参数,在不指定ThreadPoolKey的情况下,字面值用于对不同依赖的线程池/信号区分。


  线程池/信号:ThreadPoolKey   

 

public HelloWorldCommand(String name) {  super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"))  .andCommandKey(HystrixCommandKey.Factory.asKey("HelloWorld"))  /* 使用HystrixThreadPoolKey工厂定义线程池名称*/  .andThreadPoolKey(HystrixThreadPoolKey.Factory.asKey("HelloWorldPool")));  this.name = name; 

NOTE: 当对同一业务依赖做隔离时使用CommandGroup做区分,但是对同一依赖的不同远程调用如(一个是redis 一个是http),可以使用HystrixThreadPoolKey做隔离区分。


最然在业务上都是相同的组,但是需要在资源上做隔离时,可以使用HystrixThreadPoolKey区分。


  信号量隔离:SEMAPHORE   


隔离本地代码或可快速返回远程调用(如memcached,redis)可以直接使用信号量隔离,降低线程隔离开销。


 
  1. public class HelloWorldCommand extends HystrixCommand<String> {

  2. private final String name;

  3. public HelloWorldCommand(String name) {

  4. super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("HelloWorldGroup"))

  5. /* 配置信号量隔离方式,默认采用线程池隔离 */

  6. .andCommandPropertiesDefaults(HystrixCommandProperties.Setter()

  7. .withExecutionIsolationStrategy(HystrixCommandProperties.ExecutionIsolationStrategy.SEMAPHORE)));

  8. this.name = name;

  9. }

  10. @Override

  11. protected String run() throws Exception {

  12. return "HystrixThread:" + Thread.currentThread().getName();

  13. }

  14. public static void main(String[] args) throws Exception{

  15. HelloWorldCommand command = new HelloWorldCommand("semaphore");

  16. String result = command.execute();

  17. System.out.println(result);

  18. System.out.println("MainThread:" + Thread.currentThread().getName());

  19. }

  20. }


Hystrix关键组件分析


  Hystrix流程结构解析   


流程说明:

1,每次调用创建一个新的HystrixCommand,把依赖调用封装在run()方法中;

2,执行execute()/queue做同步或异步调用;

3,判断熔断器(circuit-breaker)是否打开,如果打开跳到步骤8,进行降级策略,否则继续后续步骤;

4,判断线程池/队列/信号量是否跑满,如果跑满进入降级步骤8,否则继续后续步骤;

5,调用HystrixCommand的run方法,运行依赖逻辑;

a 依赖逻辑调用超时,进入步骤8

6,判断逻辑是否调用成功;

a 返回成功调用结果

b 调用出错,进入步骤8

7,计算熔断器状态,所有的运行状态上报给熔断器,用于统计从而判断熔断器状态;

8,getFallback()降级逻辑;

以下四种情况将触发getFallback调用:

  • run()方法抛出非HystrixBadRequestException异常

  • run()方法调用超时

  • 熔断器开启拦截调用

  • 线程池/队列/信号量是否跑满

没有实现getFallback的Command将直接抛出异常

fallback降级逻辑调用成功直接返回

降级逻辑调用失败抛出异常

9,返回执行成功结果;


  熔断器:Circuit Breaker   


Circuit Breaker 流程架构和统计



每个熔断器默认维护10个bucket,每秒一个bucket,每个blucket记录成功、失败、超时、拒绝的状态,默认错误超过50%且10秒内超过20个请求进行中断拦截.。


  隔离(Isolation)分析   


Hystrix隔离方式采用线程/信号的方式,通过隔离限制依赖的并发量和阻塞扩散。


(1) 线程隔离

把执行依赖代码的线程与请求线程分离,请求线程可以自由控制离开的时间(异步过程)。

通过线程池大小可以控制并发量,当线程池饱和时可以提前拒绝服务,防止依赖问题扩散。

线上建议线程池不要设置过大,否则大量堵塞线程有可能会拖慢服务器。



线程池的使用示意图如下图所示,当n个请求线程并发对某个接口请求调用时,会先从hystrix管理的线程池里面获得一个线程,然后将参数传递给这个线程去执行真正调用。线程池的大小有限,默认是10个线程,可以使用maxConcurrentRequests参数配置,如果并发请求数多于线程池线程个数,就有线程需要进入队列排队,但排队队列也有上限,默认是 5,如果排队队列也满,则必定有请求线程会走fallback流程。


线程池模式可以支持异步调用,支持超时调用,支持直接熔断,存在线程切换,开销大。



(2) 线程隔离的优缺点

线程隔离的优点:

  • 使用线程可以完全隔离第三方代码,请求线程可以快速放回。

  • 当一个失败的依赖再次变成可用时,线程池将清理,并立即恢复可用,而不是一个长时间的恢复。

  • 可以完全模拟异步调用,方便异步编程。

线程隔离的缺点:

  • 线程池的主要缺点是它增加了cpu,因为每个命令的执行涉及到排队(默认使用SynchronousQueue避免排队),调度和上下文切换。

  • 对使用ThreadLocal等依赖线程状态的代码增加复杂性,需要手动传递和清理线程状态。



NOTE: Netflix公司内部认为线程隔离开销足够小,不会造成重大的成本或性能的影响。


Netflix内部API每天100亿的HystrixCommand依赖请求使用线程隔,每个应用大约40多个线程池,每个线程池大约5-20个线程。


(3) 信号隔离

信号隔离也可以用于限制并发访问,防止阻塞扩散, 与线程隔离最大不同在于执行依赖代码的线程依然是请求线程(该线程需要通过信号申请)。

如果客户端是可信的且可以快速返回,可以使用信号隔离替换线程隔离,降低开销。


线程隔离与信号隔离区别如下图:



信号量的使用示意图如下图所示,当n个并发请求去调用一个目标服务接口时,都要获取一个信号量才能真正去调用目标服务接口,但信号量有限,默认是10个,可以使用maxConcurrentRequests参数配置,如果并发请求数多于信号量个数,就有线程需要进入队列排队,但排队队列也有上限,默认是 5,如果排队队列也满,则必定有请求线程会走fallback流程,从而达到限流和防止雪崩的目的。



信号量模式从始至终都只有请求线程自身,是同步调用模式,不支持超时调用,不支持直接熔断,由于没有线程的切换,开销非常小。


(4) 总结

当请求的服务网络开销比较大的时候,或者是请求比较耗时的时候,我们最好是使用线程隔离策略,这样的话,可以保证大量的容器(tomcat)线程可用,不会由于服务原因,一直处于阻塞或等待状态,快速失败返回。而当我们请求缓存这些服务的时候,我们可以使用信号量隔离策略,因为这类服务的返回通常会非常的快,不会占用容器线程太长时间,而且也减少了线程切换的一些开销,提高了缓存服务的效率。


  • 线程池:适合绝大多数的场景,99%的。对依赖服务的网络请求的调用和访问,timeout这种问题

  • 信号量:适合你的访问不是对外部依赖的访问,而是对内部的一些比较复杂的业务逻辑的访问,但是像这种访问,系统内部的代码,其实不涉及任何的网络请求,那么只要做信号量的普通限流就可以了,因为不需要去捕获timeout类似的问题,算法+数据结构的效率不是太高,并发量突然太高,因为这里稍微耗时一些,导致很多线程卡在这里的话,不太好,所以进行一个基本的资源隔离和访问,避免内部复杂的低效率的代码,导致大量的线程被hang住


Reference:

http://blog.51cto.com/developerycj/1950881

http://www.coolxuewang.com/view/4


---------------END----------------

后续的内容同样精彩

长按关注“IT实战联盟”哦




全部评论: 0

    我有话说:

    Java并发解决方案:分布式应用实践

    任何都不是漫无目的的,也不是一个开关就可以解决的问题,常用的算法有:令牌桶,漏桶。在之前的文章中,也讲到过,但是那是基于单机场景来写。 之前文章:接口算法:漏桶算法&令牌桶算法

    「推荐」通过API网关实现微服务管控-熔断降级

      今天准备谈下基于API网关来实现微服务治理管控中的服务熔断降级方面的内容。在前面谈微服务架构的时候也谈到过类似通过Hystrix,Sentinel来是服务熔断。包括也不断

    京东到家订单中心系统mysql到es的转化之路

    原文:https://www.toutiao.com/i6796507988602389006 京东到家订单中心系统业务中,无论是外部商家的订单生产,或是内部上下游系统的依赖,订单查询的调用量都非常

    码云推荐:一个优秀的分布式spring boot/Spring Cloud API框架,特别适合微服务架构

    一个优秀的分布式spring boot/Spring Cloud API框架,特别适合微服务架构.

    高可用降级组件 Sentinel Go 1.0 GA 版本正式发布

    Sentinel 是阿里巴巴开源的,面向云原生、分布式服务架构的高可用流量防护组件,主要以流量为切入点,从、流量整形、熔断降级系统自适应保护等多个维度来帮助开发者保障微服务的稳定性

    Martian框架发布 3.0.3 版本,Redis分布式

    项目简介 Martian 是一个声明式 API 编程(DAP)框架,可以帮助你快速开发后端服务。 以HttpServer作为 http服务,彻底脱离Tomcat这一类的Web容器和Servlet

    京东技术:【揭秘】一个轻量级分布式 RPC 框架 — EasyRpc

    了解EasyRPC框架内容,点击详情查看吧

    京东技术京东系统架构师如何让笨重的架构变得灵巧

    京东系统架构师,从事架构设计与开发工作,熟悉各种开源软件架构。在Web开发、架构优化上有较丰富实战经历。

    商城系统 DBShop V3.0 Beta 发布

    全新重构,首次亮相。 系统简介 DBShop企业级商城系统,使用PHP语言基于Laminas(Zendframework 3) + Doctrine 2 组合框架开发完成。可定制、多终端、多场景、多

    【开源资讯】JWCloud 专业版 v1.0.0 发布,基于 SpringCloud 研发的微服务框架

    简介 JavaWeb_Cloud 微服务平台是一款基于 SpringCloud 框架研发的分布式微服务框架,主要使用技术栈包括: SpringCloud、Vue、ElementUI

    京东技术:如何实现靠谱的分布式锁?(附SharkLock的设计选择)

    分布式锁,是用来控制分布式系统中互斥访问共享资源的一种手段,从而避免并行导致的结果不可控。

    精品推荐:JDFlutter | 京东技术中台新一代跨平台开发框架

    DFlutter 是商城共享技术部-多端融合技术部推出的新一代跨平台开发框架,可快速集成至现有 Android/iOS 工程,开发者可借助 JDFlutter 平台快速完成 Flutter 业务开发。

    京东技术:使用JDReact小程序双向转换

    JDReact是京东商城前台产品研发部推出的多端融合开发框架

    京东技术:服务治理与监控 | 分布式服务跟踪(SGM)实践

    监控系统的建设就像攀登一座高山,而这座山上除了有陡峭的山坡之外,还存在着沼泽和很多的未知。我们正在不断探索新的方法去攀登征服这座高山。

    「转载」蘑菇街消息系统上云实践

    小编又来啦~本周要推荐给大家的是一篇跟中间件上云相关的技术文章,这里面详细的记录了,蘑菇街自研消息系统上云的全过程,也是市面上开放出来为数不多的企业自研组件上云实践。有相关需求的同学可以好好学习下

    京东技术:多数据模型数据库 | 应用实例解析

    作 者 简 介吕信,京东商城技术架构部资深架构师,拥有多年数据产品研发及架构经验。

    Apache HBase 2.3.2 发布,分布式存储系统

    Apache HBase 2.3.2 已经发布。HBase – Hadoop Database,是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统,利用 HBase 技术可在廉价 PC

    Python ORM框架SQLAlchemy 1.3.20 发布

    SQLAlchemy 1.3.20 发布了。SQLAlchemy 是一个 Python 的 SQL 工具包以及数据库对象映射(ORM)框架。它包含整套企业级持久化模式,专门用于高效和高性能的数据库