Hystrix的作用
名词解释
服务雪崩
雪崩是系统中的蝴蝶效应导致其发生的原因多种多样,有不合理的容量设计,或者是高并发下某一个方法响应变慢,亦或是某台机器的资源耗尽。从源头上我们无法完全杜绝雪崩源头的发生,但是雪崩的根本原因来源于服务之间的强依赖,所以我们可以提前评估。当整个微服务系统中,有一个节点出现异常情况,就有可能在高并发的情况下出现雪崩,导致调用它的上游系统出现响应延迟,响应延迟就会导致tomcat连接本耗尽,导致该服务节点不能正常的接收到正常的情况,这就是服务雪崩行为。
服务隔离
如果整个系统雪崩是由于一个接口导致的,由于这一个接口响应不及时导致问题,那么我们就有必要对这个接口进行隔离,就是只允许这个接口最多能接受多少的并发,做了这样的限制后,该接口的主机就会空余线程出来接收其他的情况,不会被哪个坏了的接口占用满。
Hystrix是什么
Hystrix是Netflix开源的一款容错框架,包含常用的容错方法:线程池隔离、信号量隔离、熔断、降级回退。在高并发访问下,系统所依赖的服务的稳定性对系统的影响非常大,依赖有很多不可控的因素,比如网络连接变慢,资源突然繁忙,暂时不可用,服务脱机等。我们要构建稳定、可靠的分布式系统,就必须要有这样一套容错方法。
在分布式环境中,许多服务依赖项中的一些必然会失败。Hystrix是一个库,通过添加延迟容忍和容错逻辑,帮助你控制这些分布式服务之间的交互。Hystrix通过隔离服务之间的访问点、停止级联失败和提供回退选项来实现这一点,所有这些都可以提高系统的整体弹性。
Hystrix被设计的目标
- 对通过第三方客户端库访问的依赖项(通常是通过网络)的延迟和故障进行保护和控制。
- 在复杂的分布式系统中阻止级联故障。
- 快速失败,快速恢复。
- 回退,尽可能优雅地降级。
- 启用近实时监控、警报和操作控制
Hystrix解决了什么问题
复杂分布式体系结构中的应用程序有许多依赖项,每个依赖项在某些时候都不可避免地会失败。如果主机应用程序没有与这些外部故障隔离,那么它有可能被他们拖垮。
例如,对于一个依赖于30个服务的应用程序,每个服务都有99.99%的正常运行时间,你可以期望如下:
99.9930 = 99.7% 可用
也就是说一亿个请求的0.03% = 3000000 会失败
如果一切正常,那么每个月有2个小时服务是不可用的
现实通常是更糟糕
当一切正常时,请求看起来是这样的:
当其中有一个系统有延迟时,它可能阻塞整个用户请求:
在高流量的情况下,一个后端依赖项的延迟可能导致所有服务器上的所有资源在数秒内饱和(PS:意味着后续再有请求将无法立即提供服务)
Hystrix设计原则
- 防止任何单个依赖项耗尽所有容器(如Tomcat)用户线程。
- 甩掉包袱,快速失败而不是排队。
- 在任何可行的地方提供回退,以保护用户不受失败的影响。
- 使用隔离技术(如隔离板、泳道和断路器模式)来限制任何一个依赖项的影响。
- 通过近实时的度量、监视和警报来优化发现时间。
- 通过配置的低延迟传播来优化恢复时间。
- 支持对Hystrix的大多数方面的动态属性更改,允许使用低延迟反馈循环进行实时操作修改。
- 避免在整个依赖客户端执行中出现故障,而不仅仅是在网络流量中。
Hystrix是如何实现目的
- 用一个HystrixCommand 或者 HystrixObservableCommand (这是命令模式的一个例子)包装所有的对外部系统(或者依赖)的调用,典型地它们在一个单独的线程中执行
- 调用超时时间比你自己定义的阈值要长。有一个默认值,对于大多数的依赖项你是可以自定义超时时间的。
- 为每个依赖项维护一个小的线程池(或信号量);如果线程池满了,那么该依赖性将会立即拒绝请求,而不是排队。
- 调用的结果有这么几种:成功、失败(客户端抛出异常)、超时、拒绝。
- 在一段时间内,如果服务的错误百分比超过了一个阈值,就会触发一个断路器来停止对特定服务的所有请求,无论是手动的还是自动的。
- 当请求失败、被拒绝、超时或短路时,执行回退逻辑。
- 近实时监控指标和配置变化。
当你使用Hystrix来包装每个依赖项时,上图中所示的架构会发生变化,如下图所示:
每个依赖项相互隔离,当延迟发生时,它会被限制在资源中,并包含回退逻辑,该逻辑决定在依赖项中发生任何类型的故障时应作出何种响应:
Hystrix解决方案
熔断模式
这种模式主要是参考电路熔断,如果一条线路电压过高,保险丝会熔断,防止火灾。放到我们的系统中,如果某个目标服务调用慢或者有大量超时,此时,熔断该服务的调用,对于后续调用请求,不在继续调用目标服务,直接返回,快速释放资源。如果目标服务情况好转则恢复调用。
隔离模式
这种模式就像对系统请求按类型划分成一个个小岛的一样,当某个小岛被火烧光了,不会影响到其他的小岛。例如可以对不同类型的请求使用线程池来资源隔离,每种类型的请求互不影响,如果一种类型的请求线程资源耗尽,则对后续的该类型请求直接返回,不再调用后续资源。这种模式使用场景非常多,例如将一个服务拆开,对于重要的服务使用单独服务器来部署,再或者公司最近推广的多中心。
限流模式
上述的熔断模式和隔离模式都属于出错后的容错处理机制,而限流模式则可以称为预防模式。限流模式主要是提前对各个类型的请求设置最高的QPS阈值,若高于设置的阈值则对该请求直接返回,不再调用后续资源。这种模式不能解决服务依赖的问题,只能解决系统整体资源分配问题,因为没有被限流的请求依然有可能造成雪崩效应。
线程隔离
为什么要做线程隔离
比如我们现在有3个业务调用分别是查询订单、查询商品、查询用户,且这三个业务请求都是依赖第三方服务-订单服务、商品服务、用户服务。三个服务均是通过RPC调用。当查询订单服务,假如线程阻塞了,这个时候后续有大量的查询订单请求过来,那么容器中的线程数量则会持续增加直致CPU资源耗尽到100%,整个服务对外不可用,集群环境下就是雪崩。如下图
线程池隔离
使用一个线程池来存储当前的请求,线程池对请求作处理,设置任务返回处理超时时间,堆积的请求堆积入线程池队列。这种方式需要为每个依赖的服务申请线程池,有一定的资源消耗,好处是可以应对突发流量(流量洪峰来临时,处理不完可将数据存储到线程池队里慢慢处理)。
Hystrix通过命令模式,将每个类型的业务请求封装成对应的命令请求,比如查询订单->订单Command,查询商品->商品Command,查询用户->用户Command。每个类型的Command对应一个线程池。创建好的线程池是被放入到ConcurrentHashMap中,比如查询订单:
1 | final static ConcurrentHashMap<String, HystrixThreadPool> threadPools = new ConcurrentHashMap<String, HystrixThreadPool>(); |
当第二次查询订单请求过来的时候,则可以直接从Map中获取该线程池。具体流程如下图:
线程池隔离的优点
- 应用程序会被完全保护起来,即使依赖的一个服务的线程池满了,也不会影响到应用程序的其他部分。
- 我们给应用程序引入一个新的风险较低的客户端lib的时候,如果发生问题,也是在本lib中,并不会影响到其他内容,因此我们可以大胆的引入新lib库。
- 当依赖的一个失败的服务恢复正常时,应用程序会立即恢复正常的性能。
- 如果我们的应用程序一些参数配置错误了,线程池的运行状况将会很快显示出来,比如延迟、超时、拒绝等。同时可以通过动态属性实时执行来处理纠正错误的参数配置。
- 如果服务的性能有变化,从而需要调整,比如增加或者减少超时时间,更改重试次数,就可以通过线程池指标动态属性修改,而且不会影响到其他调用请求。
- 除了隔离优势外,hystrix拥有专门的线程池可提供内置的并发功能,使得可以在同步调用之上构建异步的外观模式,这样就可以很方便的做异步编程(Hystrix引入了Rxjava异步框架)。
尽管线程池提供了线程隔离,我们的客户端底层代码也必须要有超时设置,不能无限制的阻塞以致线程池一直饱和。
线程池隔离的缺点
线程池的主要缺点就是它增加了计算的开销,每个业务请求(被包装成命令)在执行的时候,会涉及到请求排队,调度和上下文切换。不过Netflix公司内部认为线程隔离开销足够小,不会产生重大的成本或性能的影响。
Netflix API每天使用线程隔离处理10亿次Hystrix Command执行。 每个API实例都有40多个线程池,每个线程池中有5-20个线程(大多数设置为10个)。
对于不依赖网络访问的服务,比如只依赖内存缓存这种情况下,就不适合用线程池隔离技术,而是采用信号量隔离。
线程池隔离小结
执行依赖代码的线程与请求线程(比如Tomcat线程)分离,请求线程可以自由控制离开的时间,这也是我们通常说的异步编程,Hystrix是结合RxJava来实现的异步编程。通过设置线程池大小来控制并发访问量,当线程饱和的时候可以拒绝服务,防止依赖问题扩散。
信号量隔离
使用一个原子计数器(或信号量)来记录当前有多少个线程在运行,请求来先判断计数器的数值,若超过设置的最大线程个数则丢弃改类型的新请求,若不超过则执行计数操作请求来计数器+1,请求返回计数器-1。这种方式是严格的控制线程且立即返回模式,无法应对突发流量(流量洪峰来临时,处理的线程超过数量,其他的请求会直接返回,不继续去请求依赖的服务)。
线程池和信号量的区别
上面谈到了线程池的缺点,当我们依赖的服务是极低延迟的,比如访问内存缓存,就没有必要使用线程池的方式,那样的话开销得不偿失,而是推荐使用信号量这种方式。下面这张图说明了线程池隔离和信号量隔离的主要区别:线程池方式下业务请求线程和执行依赖的服务的线程不是同一个线程;信号量方式下业务请求线程和执行依赖服务的线程是同一个线程
线程池和信号量的区别
线程池隔离 | 信号量隔离 | |
---|---|---|
线程 | 与调用线程不相同线程 | 与调用线程相同 |
开销 | 排队、调度、上下文开销等 | 无线程切换,开销低 |
异步 | 支持 | 不支持 |
并发支持 | 支持(最大线程池大小) | 支持(最大信号量上限) |
开销 | 速度快,占用内存 | 速度稍慢,节省内存 |
信号量小结
信号量隔离的方式是限制了总的并发数,每一次请求过来,请求线程和调用依赖服务的线程是同一个线程,那么如果不涉及远程RPC调用(没有网络开销)则使用信号量来隔离,更为轻量,开销更小。
熔断器
熔断器(Circuit Breaker)介绍
熔断器,现实生活中有一个很好的类比,就是家庭电路中都会安装一个保险盒,当电流过大的时候保险盒里面的保险丝会自动断掉,来保护家里的各种电器及电路。Hystrix中的熔断器(Circuit Breaker)也是起到这样的作用,Hystrix在运行过程中会向每个commandKey对应的熔断器报告成功、失败、超时和拒绝的状态,熔断器维护计算统计的数据,根据这些统计的信息来确定熔断器是否打开。如果打开,后续的请求都会被截断。然后会隔一段时间默认是5s,尝试半开,放入一部分流量请求进来,相当于对依赖服务进行一次健康检查,如果恢复,熔断器关闭,随后完全恢复调用。如下图:
再来看下熔断器在整个Hystrix流程图中的位置,从步骤4开始,如下图:
Hystrix会检查Circuit Breaker的状态。如果Circuit Breaker的状态为开启状态,Hystrix将不会执行对应指令,而是直接进入失败处理状态。如果Circuit Breaker的状态为关闭状态,Hystrix会继续进行线程池、任务队列、信号量的检查。
熔断器设计
在熔断的设计主要参考了hystrix的做法。其中最重要的是三个模块:熔断请求判断算法、熔断恢复机制、熔断报警
- 熔断请求判断机制算法:
使用无锁循环队列计数,每个熔断器默认维护10个bucket,每1秒一个bucket,每个blucket记录请求的成功、失败、超时、拒绝的状态,默认错误超过50%且10秒内超过20个请求进行中断拦截。 - 熔断恢复:
对于被熔断的请求,每隔5s允许部分请求通过,若请求都是健康的(RT<250ms)则对请求健康恢复。 - 熔断报警:
对于熔断的请求打日志,异常请求超过某些设定则报警
熔断器小结
每个熔断器默认维护10个bucket,每秒一个bucket,每个blucket记录成功,失败,超时,拒绝的状态,默认错误超过50%且10秒内超过20个请求进行中断拦截。下图显示HystrixCommand或HystrixObservableCommand如何与HystrixCircuitBreaker及其逻辑和决策流程进行交互,包括计数器在断路器中的行为。
配置参数说明
触发fallback的情况
名字 | 描述 | 触发fallback |
---|---|---|
EMIT | 值传递 | NO |
SUCCESS | 执行完成,没有错误 | NO |
FAILURE | 执行抛出异常 | YES |
TIMEOUT | 执行开始,但没有在允许的时间内完成 | YES |
BAD_REQUEST | 执行抛出HystrixBadRequestException | NO |
SHORT_CIRCUITED | 断路器打开,不尝试执行 | YES |
THREAD_POOL_REJECTED | 线程池拒绝,不尝试执行 | YES |
SEMAPHORE_REJECTED | 信号量拒绝,不尝试执行 | YES |
fallback方法抛出异常的情况
名字 | 描述 | 抛异常 |
---|---|---|
FALLBACK_EMIT | Fallback值传递 | NO |
FALLBACK_SUCCESS | Fallback执行完成,没有错误 | NO |
FALLBACK_FAILURE | Fallback执行抛出出错 | YES |
FALLBACK_REJECTED | Fallback信号量拒绝,不尝试执行 | YES |
FALLBACK_MISSING | 没有Fallback实例 | YES |
hystrix dashboard界面监控参数
配置信息
default或HystrixCommandKey最常用的几项
超时时间
默认1000ms,单位:ms
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds
在调用方配置,被该调用方的所有方法的超时时间都是该值,优先级低于下边的指定配置
hystrix.command.HystrixCommandKey.execution.isolation.thread.timeoutInMilliseconds
在调用方配置,被该调用方的指定方法(HystrixCommandKey方法名)的超时时间是该值
线程池核心线程数
hystrix.threadpool.default.coreSize(默认为10)
Queue
hystrix.threadpool.default.maxQueueSize
最大排队长度。默认-1,使用SynchronousQueue。其他值则使用 LinkedBlockingQueue。如果要从-1换成其他值则需重启,即该值不能动态调整,若要动态调整,需要使用到下边这个配置
hystrix.threadpool.default.queueSizeRejectionThreshold
排队线程数量阈值,默认为5,达到时拒绝,如果配置了该选项,队列的大小是该队列
注意:如果maxQueueSize=-1的话,则该选项不起作用
断路器
hystrix.command.default.circuitBreaker.requestVolumeThreshold
当在配置时间窗口内达到此数量的失败后,进行短路。默认20个
hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds
短路多久以后开始尝试是否恢复,默认5s
hystrix.command.default.circuitBreaker.errorThresholdPercentage
出错百分比阈值,当达到此阈值后,开始短路。默认50%
fallback
hystrix.command.default.fallback.isolation.semaphore.maxConcurrentRequests
调用线程允许请求HystrixCommand.GetFallback()的最大数量,默认10。超出时将会有异常抛出,注意:该项配置对于THREAD隔离模式也起作用
属性配置参数
Command Properties
以下属性控制HystrixCommand行为
Execution
以下属性控制HystrixCommand.run()如何执行。
参数 | 描述 | 默认值 |
---|---|---|
execution.isolation.strategy | 隔离策略,有THREAD和SEMAPHORE THREAD - 它在单独的线程上执行,并发请求受线程池中的线程数量的限制 SEMAPHORE - 它在调用线程上执行,并发请求受到信号量计数的限制 |
默认使用THREAD模式,以下几种场景可以使用SEMAPHORE模式:只想控制并发度外部的方法已经做了线程隔离调用的是本地方法或者可靠度非常高、耗时特别小的方法(如medis) |
execution.isolation.thread.timeoutInMilliseconds | 超时时间 | 默认值:1000 在THREAD模式下,达到超时时间,可以中断 在SEMAPHORE模式下,会等待执行完成后,再去判断是否超时 设置标准: 有retry,99meantime+avg meantime 没有retry,99.5meantime |
execution.timeout.enabled | HystrixCommand.run()执行是否应该有超时。 | 默认值:true |
execution.isolation.thread.interruptOnTimeout | 在发生超时时是否应中断HystrixCommand.run()执行。 | 默认值:trueTHREAD模式有效 |
execution.isolation.thread.interruptOnCancel | 当发生取消时,执行是否应该中断。 | 默认值为falseTHREAD模式有效 |
execution.isolation.semaphore.maxConcurrentRequests | 设置在使用时允许到HystrixCommand.run()方法的最大请求数。 | 默认值:10SEMAPHORE模式有效 |
Fallback
以下属性控制HystrixCommand.getFallback()如何执行。这些属性适用于ExecutionIsolationStrategy.THREAD和ExecutionIsolationStrategy.SEMAPHORE。
参数 | 描述 | 默认值 |
---|---|---|
fallback.isolation.semaphore.maxConcurrentRequests | 设置从调用线程允许HystrixCommand.getFallback()方法的最大请求数。 | SEMAPHORE模式有效默认值:10 |
fallback.enabled | 确定在发生失败或拒绝时是否尝试调用HystrixCommand.getFallback()。 | 默认值为true |
Circuit Breaker
断路器属性控制HystrixCircuitBreaker的行为。
参数 | 描述 | 默认值 |
---|---|---|
circuitBreaker.enabled | 确定断路器是否用于跟踪运行状况和短路请求(如果跳闸)。 | 默认值为true |
circuitBreaker.requestVolumeThreshold | 熔断触发的最小个数/10s | 默认值:20 |
circuitBreaker.sleepWindowInMilliseconds | 熔断多少秒后去尝试请求 | 默认值:5000 |
circuitBreaker.errorThresholdPercentage | 失败率达到多少百分比后熔断 | 默认值:50主要根据依赖重要性进行调整 |
circuitBreaker.forceOpen | 属性如果为真,强制断路器进入打开(跳闸)状态,其中它将拒绝所有请求。 | 默认值为false此属性优先于circuitBreaker.forceClosed |
circuitBreaker.forceClosed | 该属性如果为真,则迫使断路器进入闭合状态,其中它将允许请求,而不考虑误差百分比。 | 默认值为false如果是强依赖,应该设置为truecircuitBreaker.forceOpen属性优先,因此如果forceOpen设置为true,此属性不执行任何操作。 |
Metrics
以下属性与从HystrixCommand和HystrixObservableCommand执行捕获指标有关。
参数 | 描述 | 默认值 |
---|---|---|
metrics.rollingStats.timeInMilliseconds | 此属性设置统计滚动窗口的持续时间(以毫秒为单位)。对于断路器的使用和发布Hystrix保持多长时间的指标。 | 默认值:10000 |
metrics.rollingStats.numBuckets | 此属性设置rollingstatistical窗口划分的桶数。以下必须为true - “metrics.rollingStats.timeInMilliseconds%metrics.rollingStats.numBuckets == 0” -否则将抛出异常。 | 默认值:10 |
metrics.rollingPercentile.enabled | 此属性指示是否应以百分位数跟踪和计算执行延迟。 如果禁用它们,则所有摘要统计信息(平均值,百分位数)都将返回-1。 | 默认值为true |
metrics.rollingPercentile.timeInMilliseconds | 此属性设置滚动窗口的持续时间,其中保留执行时间以允许百分位数计算,以毫秒为单位。 | 默认值:60000 |
metrics.rollingPercentile.numBuckets | 此属性设置rollingPercentile窗口将划分的桶的数量。以下内容必须为true - “metrics.rollingPercentile.timeInMilliseconds%metrics.rollingPercentile.numBuckets == 0” -否则将抛出异常。 | 默认值:6 |
metrics.rollingPercentile.bucketSize | 此属性设置每个存储桶保留的最大执行次数。如果在这段时间内发生更多的执行,它们将绕回并开始在桶的开始处重写。 | 默认值:100 |
metrics.healthSnapshot.intervalInMilliseconds | 此属性设置在允许计算成功和错误百分比并影响断路器状态的健康快照之间等待的时间(以毫秒为单位)。 | 默认值:500 |
Request Context
这些属性涉及HystrixCommand使用的HystrixRequestContext功能。
参数 | 描述 | 默认值 |
---|---|---|
requestCache.enabled | HystrixCommand.getCacheKey()是否应与HystrixRequestCache一起使用,以通过请求范围的缓存提供重复数据删除功能。 | 默认值为true |
requestLog.enabled | HystrixCommand执行和事件是否应记录到HystrixRequestLog。 | 默认值为tru |
Collapser Properties
下列属性控制HystrixCollapser行为。
参数 | 描述 | 默认值 |
---|---|---|
maxRequestsInBatch | 此属性设置在触发批处理执行之前批处理中允许的最大请求数。 | Integer.MAX_VALUE |
timerDelayInMilliseconds | 此属性设置创建批处理后触发其执行的毫秒数。 | 默认值:10 |
requestCache.enabled | 此属性指示是否为HystrixCollapser.execute()和HystrixCollapser.queue()调用启用请求高速缓存。 | 默认值:true |
ThreadPool Properties
以下属性控制Hystrix命令在其上执行的线程池的行为。
大多数时候,默认值为10的线程会很好(通常可以做得更小)。
参数 | 描述 | 默认值 |
---|---|---|
coreSize | 线程池coreSize | 默认值:10设置标准:qps*99meantime+breathing room |
maximumSize | 此属性设置最大线程池大小。 这是在不开始拒绝HystrixCommands的情况下可以支持的最大并发数。 请注意,此设置仅在您还设置allowMaximumSizeToDivergeFromCoreSize时才会生效。 | 默认值:10 |
maxQueueSize | 请求等待队列 | 默认值:-1如果使用正数,队列将从SynchronizeQueue改为LinkedBlockingQueue |
queueSizeRejectionThreshold | 此属性设置队列大小拒绝阈值 - 即使未达到maxQueueSize也将发生拒绝的人为最大队列大小。 此属性存在,因为BlockingQueue的maxQueueSize不能动态更改,我们希望允许您动态更改影响拒绝的队列大小。 | 默认值:5注意:如果maxQueueSize == -1,则此属性不适用。 |
keepAliveTimeMinutes | 此属性设置保持活动时间,以分钟为单位。 | 默认值:1 |
allowMaximumSizeToDivergeFromCoreSize | 此属性允许maximumSize的配置生效。 那么该值可以等于或高于coreSize。 设置coreSize <maximumSize会创建一个线程池,该线程池可以支持maximumSize并发,但在相对不活动期间将向系统返回线程。 (以keepAliveTimeInMinutes为准) | 默认值:false |
metrics.rollingStats.timeInMilliseconds | 此属性设置statistical rolling窗口的持续时间(以毫秒为单位)。 这是为线程池保留多长时间。 | 默认值:10000 |
metrics.rollingStats.numBuckets | 此属性设置滚动统计窗口划分的桶数。注意:以下必须为true - “metrics.rollingStats.timeInMilliseconds%metrics.rollingStats.numBuckets == 0” -否则将引发异常。 | 默认值:10 |
其他
参数 | 描述 | 默认值 |
---|---|---|
groupKey | 表示所属的group,一个group共用线程池 | 默认值:getClass().getSimpleName(); |
commandKey | 默认值:当前执行方法名 | |
threadPoolKey | 具有相同的threadPoolKey的使用同一个线程池 |