在分布式系统中,如果某个服务节点发生故障或者网络发生异常,都有可能导致调用方被阻塞等待,如果超时时间设置很长,调用方资源很可能被耗尽。这又导致了调用方的上游系统发生资源耗尽的情况,最终导致系统雪崩。
如下图:
如果?D
?服务发生了故障不能响应,?B
?服务调用?D
?时只能阻塞等待。假如?B
?服务调用?D
?服务设置超时时间是?10
?秒,请求速率是每秒?100
?个,那?10
?秒内就会有?1000
?个请求线程被阻塞等待,如果?B
?的线程池大小设置?1000
?,那?B
?系统因为线程资源耗尽已经不能对外提供服务了。而这又影响了入口系统?A
?的服务,最终导致系统全面崩溃。
提高系统的整体容错能力是防止系统雪崩的有效手段。
在?Martin Fowler
?和?James Lewis
?的文章?《Microservices: a definition of this new architectural term》?[1]?中,提出了微服务的?9
?个特征,其中一个是容错设计。
要防止系统发生雪崩,就必须要有容错设计。如果遇到突增流量,一般的做法是对非核心业务功能采用熔断和服务降级的措施来保护核心业务功能正常服务,而对于核心功能服务,则需要采用限流的措施。
今天我们来聊一聊系统容错中的限流、熔断和服务降级。
当系统的处理能力不能应对外部请求的突增流量时,为了不让系统奔溃,必须采取限流的措施。
系统吞吐量是衡量系统性能的关键指标,按照事务的完成数量来限流是最合理的。
但是对实操性来说,按照事务来限流并不现实。在分布式系统中完成一笔事务需要多个系统的配合。比如我们在电商系统购物,需要订单、库存、账户、支付等多个服务配合完成,有的服务需要异步返回,这样完成一笔事务花费的时间可能会很长。如果按照?TPS
?来进行限流,时间粒度可能会很大大,很难准确评估系统的响应性能。
每秒请求数,指每秒钟服务端收到客户端的请求数量。
?
如果一个请求完成一笔事务,那?TPS
?和?HPS
?是等同的。但在分布式场景下,完成一笔事务可能需要多次请求,所以?TPS
?和?HPS
?指标不能等同看待。
?
服务端每秒能够响应的客户端查询请求数量。
?
如果后台只有一台服务器,那?HPS
?和?QPS
?是等同的。但是在分布式场景下,每个请求需要多个服务器配合完成响应。
?
?
目前主流的限流方法多采用?HPS
?作为限流指标。
?
这是最简单直接的方法,比如限制每秒请求数量?100
?,超过?100
?的请求就拒绝掉。
但是这个方法存在?2
?个明显的问题:
1s
?)很难把控,如下图:
这张图上,从下面时间看,?HPS
?没有超过?100
?,但是从上面看?HPS
?超过?100
?了。
HPS
?限制?50
?,虽然前?3s
?流量超了,但是如果读超时时间设置为?5s
?,并不需要限流。
滑动时间窗口算法是目前比较流行的限流算法,主要思想是把时间看做是一个向前滚动的窗口,如下图:
开始的时候,我们把?t1~t5
?看做一个时间窗口,每个窗口?1s
?,如果我们定的限流目标是每秒?50
?个请求,那?t1~t5
?这个窗口的请求总和不能超过?250
?个。
这个窗口是滑动的,下一秒的窗口成了?t2~t6
?,这时把?t1
?时间片的统计抛弃,加入?t6
?时间片进行统计。这段时间内的请求数量也不能超过?250
?个。
滑动时间窗口的优点是解决了流量计数器算法的缺陷,但是也有?2
?个问题:
漏桶算法的思想如下图:
在客户端的请求发送到服务器之前,先用漏桶缓存起来,这个漏桶可以是一个长度固定的队列,这个队列中的请求均匀的发送到服务端。
如果客户端的请求速率太快,漏桶的队列满了,就会被拒绝掉,或者走降级处理逻辑。这样服务端就不会受到突发流量的冲击。
漏桶算法的优点是实现简单,可以使用消息队列来削峰填谷。
但是也有?3
?个问题需要考虑:
?
漏桶大小和发送速率这?2
?个值在项目上线初期都会根据测试结果选择一个值,但是随着架构的改进和集群的伸缩,这?2
?个值也会随之发生改变。
?
令牌桶算法就跟病人去医院看病一样,找医生之前需要先挂号,而医院每天放的号是有限的。当天的号用完了,第二天又会放一批号。
算法的基本思想就是周期性的执行下面的流程:
客户端在发送请求时,都需要先从令牌桶中获取令牌,如果取到了,就可以把请求发送给服务端,取不到令牌,就只能被拒绝或者走服务降级的逻辑。如下图:
?
令牌桶算法解决了漏桶算法的问题,而且实现并不复杂,使用信号量就可以实现。在实际限流场景中使用最多,比如?google
?的?guava
?中就实现了令牌桶算法限流,感兴趣可以研究一下。
?
如果在分布式系统场景下,上面介绍的?4
?种限流算法是否还适用呢?
以令牌桶算法为例,假如在电商系统中客户下了一笔订单,如下图:
如果我们把令牌桶单独保存在一个地方(比如?redis
?中)供整个分布式系统用,那客户端在调用组合服务,组合服务调用订单、库存和账户服务都需要跟令牌桶交互,交互次数明显增加了很多。
有一种改进就是客户端调用组合服务之前首先获取四个令牌,调用组合服务时减去一个令牌并且传递给组合服务三个令牌,组合服务调用下面三个服务时依次消耗一个令牌。
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]
?
相信大家对断路器并不陌生,它就相当于一个开关,打开后可以阻止流量通过。比如保险丝,当电流过大时,就会熔断,从而避免元器件损坏。
服务熔断是指调用方访问服务时通过断路器做代理进行访问,断路器会持续观察服务返回的成功、失败的状态,当失败超过设置的阈值时断路器打开,请求就不能真正地访问到服务了。
为了更好地理解,我画了下面的时序图:
?
可以参考?Martin Fowler
?的论文《CircuitBreaker》?[3]?。
?
断路器有?3
?种状态:
CLOSED
?:默认状态。断路器观察到请求失败比例没有达到阈值,断路器认为被代理服务状态良好。
OPEN
?:断路器观察到请求失败比例已经达到阈值,断路器认为被代理服务故障,打开开关,请求不再到达被代理的服务,而是快速失败。
HALF?OPEN?CLOSED?OPEN?
断路器的状态切换图如下:
使用断路器需要考虑一些问题:
HALF OPEN
?进行重试。
connection?timeout?telenet?HALF?OPEN?
read timeout
?会比较长,防止客户端大量重试请求导致的连接、线程资源不能释放
前面讲了限流和熔断,相比来说,服务降级是站在系统全局的视角来考虑的。
在服务发生熔断后,一般会让请求走事先配置的处理方法,这个处理方法就是一个降级逻辑。
服务降级是对非核心、非关键的服务进行降级。
hystrix降级时可以忽略某个异常,在方法上加上?@HystrixCommand
?注解:
下面的代码定义降级方法是?errMethod
?,对?ParamErrorException
?和?BusinessTypeException
?这两个异常不做降级处理。
@HystrixCommand(??fallbackMethod?=?"errMethod",??ignoreExceptions?=?{ParamErrorException.class,?BusinessTypeException.class}?)?
专门针对调用第三方接口超时降级。
下面的方法是调用第三方接口3秒未收到响应就降级到errMethod方法。
@HystrixCommand(?????commandProperties?=?{?????????????@HystrixProperty(name="execution.timeout.enabled",?value="true"),?????????????@HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",?value="3000"),?????},?????fallbackMethod?=?"errMethod"?)?
限流、熔断和服务降级是系统容错的重要设计模式,从一定意义上讲限流和熔断也是一种服务降级的手段。
熔断和服务降级主要是针对非核心业务功能,而核心业务如果流程超过预估的峰值,就需要进行限流。
对于限流,选择合理的限流算法很重要,令牌桶算法优势很明显,也是使用最多的限流算法。
在系统设计的时候,这些模式需要配合业务量的预估、性能测试的数据进行相应阈值的配置,而这些阈值最好保存在配置中心,方便实时修改。
领取专属 10元无门槛券
私享最新 技术干货