大中型分布式系统中,Hystrix 分布式系统限流、降级、熔断框架
为什么需要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)可以直接使用信号量隔离,降低线程隔离开销。
public class HelloWorldCommand extends HystrixCommand<String> { private final String name; public HelloWorldCommand(String name) { super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("HelloWorldGroup")) /* 配置信号量隔离方式,默认采用线程池隔离 */ .andCommandPropertiesDefaults(HystrixCommandProperties.Setter() .withExecutionIsolationStrategy(HystrixCommandProperties.ExecutionIsolationStrategy.SEMAPHORE))); this.name = name; } @Override protected String run() throws Exception { return "HystrixThread:" + Thread.currentThread().getName(); } public static void main(String[] args) throws Exception{ HelloWorldCommand command = new HelloWorldCommand("semaphore"); String result = command.execute(); System.out.println(result); System.out.println("MainThread:" + Thread.currentThread().getName()); } }
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住
转载于:https://my.oschina.net/u/3954808/blog/3099440
大中型分布式系统中,Hystrix 分布式系统限流、降级、熔断框架相关推荐
- Spirng Cloud 中gateway 网关限流和熔断
分流:原先数据库只放一个服务器,无论多少个都只能访问这个服务器,访问不了就排队(延迟)(如果同一时间也高并发了那就限流) 限流:同一时间限制访问的人数 限流的算法 漏桶算法:把请求放到一个容器中,控制 ...
- c++突破网关屏蔽_通过API网关实现微服务管控-限流,熔断和降级
今天准备谈下基于API网关来实现微服务治理管控中的服务限流,熔断和降级方面的内容.在前面谈微服务架构的时候也谈到过类似通过Hystrix,Sentinel来是服务限流熔断.包括也不断地在谈去中心化架构 ...
- Sentinel Dubbo 适配器看限流与熔断(实战思考篇)
本文是源码分析 Sentinel 系列的第十三篇,已经非常详细的介绍了 Sentinel 的架构体系.滑动窗口.调用链上下文.限流.熔断的实现原理,相信各位读者朋友们对Sentinel有一个较为体系化 ...
- 高并发中的 限流、熔断、降级、预热、背压你都知道是什么意思吗?
首先,我们需要明确一下这几个名词出现的场景:分布式高并发环境.如果你的产品卖相不好,没人鸟它,那它就用不着这几个属性.不需要任何加成,低并发系统就能工作的很好. 分布式系统是一个整体,调用关系错综复杂 ...
- 10张图带你彻底搞懂什么是限流、熔断、服务降级
在分布式系统中,如果某个服务节点发生故障或者网络发生异常,都有可能导致调用方被阻塞等待,如果超时时间设置很长,调用方资源很可能被耗尽.这又导致了调用方的上游系统发生资源耗尽的情况,最终导致系统雪崩. ...
- 12张图带你彻底搞懂服务限流、熔断、降级、雪崩
目录 一.服务雪崩 二.服务限流 1.限流指标 1)TPS 2)HPS 3)QPS 2.限流方法 1)流量计数器 2)滑动时间窗口 3)漏桶算法 4)令牌桶算法 5)分布式限流 6)hystrix限流 ...
- 微服务从零到一 什么是限流、熔断和降级
什么是限流.熔断和降级 服务降级限流熔断 在进入正题之前,有个问题,分布式系统中肯定会遇到服务雪崩效应,这个服务雪崩效应是什么呢? 下面这幅图可以说明这个问题 服务雪崩图 商品详情展示服务会 ...
- 限流降级神器-哨兵(sentinel)原理分析
Sentinel 是阿里中间件团队开源的,面向分布式服务架构的轻量级高可用流量控制组件,主要以流量为切入点,从流量控制.熔断降级.系统负载保护等多个维度来帮助用户保护服务的稳定性. 大家可能会问:Se ...
- sentinel 阿里 原理_限流降级神器:哨兵(sentinel)原理分析
文章较长,但是干货满满,建议收藏或关注后细读 Sentinel 是阿里中间件团队开源的,面向分布式服务架构的轻量级高可用流量控制组件,主要以流量为切入点,从流量控制.熔断降级.系统负载保护等多个维度来 ...
- Spring Cloud入门-Sentinel实现服务限流、熔断与降级(Hoxton版本)
文章目录 Spring Cloud入门系列汇总 摘要 Sentinel简介 安装Sentinel控制台 创建sentinel-service模块 限流功能 创建RateLimitController类 ...
最新文章
- Linux 搭建golang开发环境
- c语言程序设计网课作业答案,《C语言程序设计》作业答案
- php 正则 回溯,PHP正则匹配绕过
- Spring Data JPA教程:获取所需的依赖关系
- day15 java的final
- dojo调用php,dojo学习第一天 Tab选项卡 实现_dojo
- 神器!输错命令,fuck 一下,就能自动纠正!
- 【pytorch】梯度爆炸/消失解决办法
- 传智:自己简单实现一个struts2框架的demo
- vue项目强制清除页面缓存
- m低信噪比下GPS信号的捕获算法研究,使用matlab算法进行仿真
- 求助!神舟笔记本BIOS进不去!
- 商城电商day 06 三、商品详情业务需求分析
- 利用webuploader实现超大文件分片上传、断点续传
- 为什么香肠能激活手机屏幕,手套不能
- 我应该购买iPhone 7或7 Plus吗?
- transform matrix3d
- http与https与其他
- 搜狗搜索X知乎:世界是这样检索的
- 手机cpu性能天梯图2023 手机cpu处理器排行榜2023