当前位置：网站首页>12 pictures take you to fully understand service current limit, circuit breaker, downgrade, and avalanche

如果 D 服务发生了故障不能响应, B 服务调用 D 时只能阻塞等待.假如 B 服务调用 D 服务设置超时时间是 10 秒,请求速率是每秒 100 个,那 10 秒内就会有 1000 个请求线程被阻塞等待,如果 B 的线程池大小设置 1000 ,那B系统因为线程资源耗尽已经不能对外提供服务了.而这又影响了入口系统 A 的服务,最终导致系统全面崩溃.

提高系统的整体容错能力是防止系统雪崩的有效手段.

要防止系统发生雪崩,就必须要有容错设计.如果遇到突增流量,一般的做法是对非核心业务功能采用熔断和服务降级的措施来保护核心业务功能正常服务,而对于核心功能服务,则需要采用限流的措施.

Let's talk about current limiting in system fault tolerance、熔断和服务降级.

二、服务限流

当系统的处理能力不能应对外部请求的突增流量时,为了不让系统奔溃,必须采取限流的措施.

1、限流指标

1）TPS

系统吞吐量是衡量系统性能的关键指标,按照The number of transactions completedTo limit the flow is the most reasonable.

但是对实操性来说,按照事务来限流并不现实.在分布式系统中完成一笔事务需要多个系统的配合.比如我们在电商系统购物,需要订单、库存、账户、支付等多个服务配合完成,有的服务需要异步返回,这样完成一笔事务花费的时间可能会很长.如果按照 TPS 来进行限流,时间粒度可能会很大大,很难准确评估系统的响应性能.

2）HPS

每秒请求数,指每秒钟服务端收到客户端的请求数量.

如果一个请求完成一笔事务,那 TPS 和 HPS 是等同的.但在分布式场景下,完成一笔事务可能需要多次请求,所以 TPS 和 HPS 指标不能等同看待.

3）QPS

服务端每秒能够响应的客户端查询请求数量.

如果后台只有一台服务器,那 HPS 和 QPS 是等同的.但是在分布式场景下,每个请求需要多个服务器配合完成响应.
目前主流的限流方法多采用 HPS 作为限流指标.

2、限流方法

1）流量计数器

这是最简单直接的方法,比如限制每秒请求数量 100 ,超过 100 的请求就拒绝掉.

但是这个方法存在2个明显的问题：

单位时间(比如1s)很难把控,如下图：

这张图上,从下面时间看, HPS 没有超过 100 ,但是从上面看 HPS 超过 100 了.

有一段时间流量超了,也不一定真的需要限流,如下图,系统 HPS 限制 50 ,虽然前 3s 流量超了,But if the read timeout is set to 5s ,并不需要限流.

2）滑动时间窗口

滑动时间窗口算法是目前比较流行的限流算法,主要思想是把时间看做是一个向前滚动的窗口,如下图：

开始的时候,我们把 t1~t5 看做一个时间窗口,每个窗口 1s ,如果我们定的限流目标是每秒 50 个请求,那 t1~t5 这个窗口的请求总和不能超过 250 个.

这个窗口是滑动的,下一秒的窗口成了 t2~t6 ,这时把 t1 时间片的统计抛弃,加入 t6 时间片进行统计.这段时间内的请求数量也不能超过 250 个.

滑动时间窗口的优点是解决了流量计数器算法的缺陷,但是也有2个问题：

流量超过就必须抛弃或者走降级逻辑
对流量控制不够精细,不能限制集中在短时间内的流量,也不能削峰填谷

3）漏桶算法

漏桶算法的思想如下图：

在客户端的请求发送到服务器之前,先用漏桶缓存起来,这个漏桶可以是一个长度固定的队列,这个队列中的请求均匀的发送到服务端.

如果客户端的请求速率太快,漏桶的队列满了,就会被拒绝掉,或者走降级处理逻辑.这样服务端就不会受到突发流量的冲击.

漏桶算法的优点是实现简单,可以使用消息队列来削峰填谷.

但是也有3个问题需要考虑:

漏桶的大小,如果太大,可能给服务端带来较大处理压力,太小可能会有大量请求被丢弃.
漏桶给服务端的请求发送速率.
使用缓存请求的方式,会使请求响应时间变长.

漏桶大小和发送速率这2个值在项目上线初期都会根据测试结果选择一个值,但是随着架构的改进和集群的伸缩,这2个值也会随之发生改变.

4）令牌桶算法

令牌桶算法就跟病人去医院看病一样,找医生之前需要先挂号,而医院每天放的号是有限的.当天的号用完了,第二天又会放一批号.

The basic idea of the algorithm is to execute the following process periodically：

客户端在发送请求时,都需要先从令牌桶中获取令牌,如果取到了,就可以把请求发送给服务端,取不到令牌,就只能被拒绝或者走服务降级的逻辑.如下图：

令牌桶算法解决了漏桶算法的问题,而且实现并不复杂,使用信号量就可以实现.在实际限流场景中使用最多,比如google的guava中就实现了令牌桶算法限流,感兴趣可以研究一下.

5）分布式限流

如果在分布式系统场景下,上面介绍的4种限流算法是否还适用呢？

以令牌桶算法为例,假如在电商系统中客户下了一笔订单,如下图：

如果我们把令牌桶单独保存在一个地方(比如redis中)供整个分布式系统用,那客户端在调用组合服务,组合服务调用订单、库存和账户服务都需要跟令牌桶交互,交互次数明显增加了很多.

有一种改进就是客户端调用组合服务之前首先获取四个令牌,调用组合服务时减去一个令牌并且传递给组合服务三个令牌,组合服务调用下面三个服务时依次消耗一个令牌.

6）hystrix限流

hystrix可以使用信号量和线程池来进行限流.

信号量限流

hystrix可以使用信号量进行限流,比如在提供服务的方法上加下面的注解.这样只能有20个并发线程来访问这个方法,超过的就被转到了errMethod这个降级方法.

@HystrixCommand(
 commandProperties= {
   @HystrixProperty(name="execution.isolation.strategy", value="SEMAPHORE"),
   @HystrixProperty(name="execution.isolation.semaphore.maxConcurrentRequests", value="20")
 },
 fallbackMethod = "errMethod"
)

线程池限流

hystrix也可以使用线程池进行限流,在提供服务的方法上加下面的注解.

@HystrixCommand(
    commandProperties = {
            @HystrixProperty(name = "execution.isolation.strategy", value = "THREAD")
    },
    threadPoolKey = "createOrderThreadPool",
    threadPoolProperties = {
            @HystrixProperty(name = "coreSize", value = "20"),
   @HystrixProperty(name = "maxQueueSize", value = "100"),
            @HystrixProperty(name = "maximumSize", value = "30"),
            @HystrixProperty(name = "queueSizeRejectionThreshold", value = "120")
    },
    fallbackMethod = "errMethod"
)

这里要注意：在 java 的线程池中,如果线程数量超过 coreSize ,创建线程请求会优先进入队列,如果队列满了,就会继续创建线程直到线程数量达到 maximumSize ,之后走拒绝策略.
但在hystrix配置的线程池中多了一个参数 queueSizeRejectionThreshold ,如果 queueSizeRejectionThreshold < maxQueueSize ,队列数量达到 queueSizeRejectionThreshold 就会走拒绝策略了,因此 maximumSize 失效了.如果 queueSizeRejectionThreshold > maxQueueSize ,队列数量达到 maxQueueSize 时, maximumSize 是有效的,系统会继续创建线程直到数量达到 maximumSize .Hytrix线程池设置坑[2]

三、服务熔断

1、基本介绍

相信大家对断路器并不陌生,它就相当于一个开关,打开后可以阻止流量通过.比如保险丝,当电流过大时,就会熔断,从而避免元器件损坏.

服务熔断是指调用方访问服务时通过断路器做代理进行访问,断路器会持续观察服务返回的成功、失败的状态,当失败超过设置的阈值时断路器打开,请求就不能真正地访问到服务了.

By returning an as expected to the calling method、可处理的备选响应（FallBack）,而不是⻓Time to wait or throw an exception that the calling method cannot handle,This ensures that the thread of the service caller will not be blocked⻓时间占用,避免故障在分布式系统中蔓延,乃至雪崩.如果目标服务情况好转则恢复调用.

服务熔断是解决服务雪崩的重要手段.

2、断路器的状态

断路器有3种状态：

CLOSED ：默认状态.断路器观察到请求失败比例没有达到阈值,断路器认为被代理服务状态良好.
OPEN ：断路器观察到请求失败比例已经达到阈值,断路器认为被代理服务故障,打开开关,请求不再到达被代理的服务,而是快速失败.
HALF OPEN ：断路器打开后,为了能自动恢复对被代理服务的访问,会切换到半开放状态,去尝试请求被代理服务以查看服务是否已经故障恢复.如果成功,会转成 CLOSED 状态,否则转到 OPEN 状态.

断路器的状态切换图如下：

四、服务降级

1、基本介绍

Service pressure has increased dramaticallyAt the same time, according to the current business situation and traffic, some services and services⻚face a strategic downgrade,以此缓解服务器的压力,以保证核心任务的进行.同时保证部分甚至大部分任务客户能得到正确的响应.也就是当前的请求处理不了了或者出错了,给一个默认的返回.

Such as a post bar type of website,当服务器吃不消的时候,可以选择把发帖功能关闭,注册功能关闭,改密码,改头像这些都关了,为了确保登录和浏览帖子这种核心的功能.

一句话就是,服务降级是对非核心、非关键的服务进行降级,保证系统核心服务正常运行.

2、使用hystrix降级

1 ）异常降级

hystrix降级时可以忽略某个异常,在方法上加上 @HystrixCommand 注解：

下面的代码定义降级方法是 errMethod ,对 ParamErrorException 和 BusinessTypeException 这两个异常不做降级处理.

@HystrixCommand(
 fallbackMethod = "errMethod",
 ignoreExceptions = {ParamErrorException.class, BusinessTypeException.class}
)

2）调用超时降级

下面的方法是调用第三方接口 3 秒未收到响应就降级到 errMethod 方法.

@HystrixCommand(
    commandProperties = {
            @HystrixProperty(name="execution.timeout.enabled", value="true"),
            @HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds", value="3000"),
    },
    fallbackMethod = "errMethod"
)

五、总结

熔断必会触发降级,所以熔断也是降级一种.区别在于熔断是对调用链路的保护,而降级是对系统过载的一种保护处理.

1、熔断和降级的相同点

目的很一致,都是从可用性可靠性着想,为防止系统的整体缓慢甚至崩溃,采用的技术手段
最终表现类似,对于两者来说,最终让用户体验到的是某些功能暂时不可达或不可用
粒度一般都是服务级别,当然,业界也有不少更细粒度的做法,比如做到数据持久层（允许查询,不允许增删改）
自治性要求很高,熔断模式一般都是服务基于策略的自动触发,降级虽说可人工干预,但在微服务架构下,完全靠人显然不可能,开关预置、配置中心都是必要手段（sentinel）