稳定性实践:限流降级

稳定性实践:限流降级

本周我们继续来讨论稳定性实践的内容。在现实情况下,当面对极端的业务场景时,瞬时的业务流量会带来大大超出系统真实容量的压力。

为了应对,前面我们介绍了容量规划方面的实践经验。不过,我们不会无限度地通过扩容资源来提升容量,因为无论从技术角度,还是从成本投入角度,这样做都是不划算的,也是不现实的。

所以,我们通常采取的策略就是限流降级,以保障承诺容量下的系统稳定;同时还有业务层面的开关预案执行,峰值时刻只保障核心业务功能,非核心业务功能就关闭

今天我们就先来介绍一下限流降级的解决方案。

什么是限流和降级

首先,我们先梳理清楚限流和降级的概念,明白它们会发挥怎样的作用,这样才便于我们理解后续的解决方案。

限流,它的作用是根据某个应用或基础部件的某些核心指标,如QPS或并发线程数,来决定是否将后续的请求进行拦截。比如我们设定1秒QPS阈值为200,如果某一秒的QPS为210,那超出的10个请求就会被拦截掉,直接返回约定的错误码或提示页面。

降级,它的作用是通过判断某个应用或组件的服务状态是否正常,来决定是否继续提供服务。以RT举例,我们根据经验,一个应用的RT在50ms以内,可以正常提供服务,一旦超过50ms,可能就会导致周边依赖的报错或超时。所以,这时我们就要设定一个策略,如果应用的RT在某段时间内超过50ms的调用次数多于N次,那该应用或该应用的某个实例就必须降级,不再对外提供服务,可以在静默一定时间后(比如5s或10s)重新开启服务。

这里再特别说一下降级,今天我们讲的内容可以理解为服务降级,后面我会介绍业务开关,可以理解为业务降级

这里只是叫法不同,不同的人有不同的理解,所以我们在讨论概念时,还是尽量回到我们要解决的问题和场景上来,上下文保持一致了,在观点和思路上也更容易达成一致。

讲到这里,再提个问题,我们讲的降级,和熔断这个概念是什么关系?你不妨停下来,按照我们刚刚讲过的思路思考一下。

  • 先来说说“服务熔断”和“服务降级”。为什么要说这个呢,因为我很长时间里都把这两个概念同质化了,不知道这两个词大家怎么理解,一个意思or有所不同?

    现在的我是这么来看的:

    • 服务熔断:在股票市场,熔断这个词大家都不陌生,是指当股指波幅达到某个点后,交易所为控制风险采取的暂停交易措施。相应的,服务熔断一般是指软件系统中,由于某些原因使得服务出现了过载现象,为防止造成整个系统故障,从而采用的一种保护措施,所以很多地方把熔断亦称为过载保护。

    • 服务降级:大家都见过女生旅行吧,大号的旅行箱是必备物,平常走走近处绰绰有余,但一旦出个远门,再大的箱子都白搭了,怎么办呢?常见的情景就是把物品拿出来分分堆,比了又比,最后一些非必需品的就忍痛放下了,等到下次箱子够用了,再带上用一用。而服务降级,就是这么回事,整体资源快不够了,忍痛将某些服务先关掉,待渡过难关,再开启回来。

所以从上述分析来看,

  • 两者其实从有些角度看是有一定的类似性的:

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

    1. 触发原因不太一样,服务熔断一般是某个服务(下游服务)故障引起,而服务降级一般是从整体负荷考虑;
    2. 管理目标的层次不太一样,熔断其实是一个框架级的处理,每个微服务都需要(无层级之分),而降级一般需要对业务有层级之分(比如降级一般是从最外围服务开始)
    3. 实现方式不太一样,这个区别后面会单独来说;这个主要在代码方面进行实现。

常见的限流解决方案

我们先看几种常见的限流类型。

第一类,接入层限流。

作为业务流量的入口,我们限流的第一道关卡往往会设置在这里,而且接入层限流往往也是最有效的。这里又有两类解决方案,根据接入层所使用的技术方案而定。

  1. Nginx限流
    Nginx或其开源产品是最常用的Web服务器,我们使用的是TEngine。对于一个Web类应用,如Web页面或H5页面,我们通常会将限流策略增加到这一层,会设置QPS、并发数以及CPU的Idle作为限流指标。Nginx有对应的函数接口,可以获取到以上指标信息,然后通过Lua脚本实现限流的逻辑,并作为TEngine的插件安装即可。

  2. API路由网关模式

    对于客户端模式的接入,我们使用了API路由网关模式,一方面可以更方面地管理客户端与服务端的链接,另一方面也可以通过配置的方式管理服务接口,这里的服务管理会复用到微服务架构的配置中心,并实现相应的路由策略。对于QPS和并发限流,直接在配置中心中进行配置即可。

第二类,应用限流。

这一类的限流策略跟上面API路由网关模式的限流相似,同样是依赖配置中心管理,限流逻辑会配套服务化的框架完成。

第三类,基础服务限流。

主要针对数据库、缓存以及消息等基础服务组件的限流而设定。同样,限流逻辑会配套分布式数据库中间件,缓存或消息的框架来实现。

讲到这里,我来解释几个关键的技术点。

  • 资源和策略。资源是我们要进行限流的对象,可能是一个应用,或者一个方法,也可能是一个接口或者URL,体现了不同的限流粒度和类型。策略就是限流的规则,比如下面我们要提到的QPS和并发数限流。

  • 时间精度。主要指对于QPS、并发数或CPU的阈值判断。比如对于QPS,我们就会设定一个QPS时间精度(假设3s),如果低于阈值则不启用策略,如果超过阈值就启动限流策略。

  • 指标计数。对于并发限制请求,会统计当前的并发数,1次请求进入到限流模块加1,等请求结束退出时减1,当前正在处理的请求数就是并发数。对于QPS限流,统计QPS不能按照秒统计,因为第1s,系统可能就被打挂了,所以QPS得按照毫秒级别去统计,统计的级别越小,性能损耗越大。所以定在10ms~100ms的级别去统计会更平滑一些,比如将1s切成10份,每一份100ms,一个请求进来肯定会落在某一份上,这一份的计数值加1。计算当前的QPS,只需要将当前时间所在份的计数和前面9份的计数相加,内存里面需要维护当前秒和前面2秒的数据。

  • 限流方式。对于Nginx就针对总的请求进行限流即可,但是粒度会比较粗。对于应用层,因为配置中心的灵活性,其限流就可以做得更细化。比如可以针对不同来源限流,也可以针对去向限流,粒度上可以针对类级别限流,也可以针对不同的方法限流,同时还可以针对总的请求情况限流,这些灵活策略都可以在微服务的配置中心实现。

  • Spring AOP。对于Java应用,绝大多数公司都会用到Spring框架,包括我们上面讲到的分布式数据库等组件,也一样会依赖Spring框架,比如我们用到的MyBatis开源组件。

    而Spirng框架中的关键技术点,就是IoC和AOP,我们在限流方案的实现上,也会利用到相关技术。简单来说就是,我们通过配置需要限流的方法作为AOP的切入点,设定Advice拦截器,在请求调用某个方法,或请求结束退出某个方法时,进行上述的各种计数处理,同时决定是否要进行限流,如果限流就返回约定好的返回码,如果不限流就正常执行业务逻辑。基于AOP这样一个统一的技术原理,我们就可以开发出与业务逻辑无关的限流组件,通常会在对外的服务调用、数据库调用、缓存调用、消息调用这些接口方法上设置默认的切面,并在业务代码运行时注入,这样就可以做到对业务透明,无侵入性。

  • Web类型的限流。对于Web类型URL接口限流,我们就利用Servlet的Filter机制进行控制即可。

  • 控制台。上面我们讲了各种配置和策略,如果都是通过人工来操作是不现实的,这时就需要开发对应的限流降级的控制台,将上述的各种配置和策略通过界面的方式进行管理,同时在配置完成之后,能够同步到对应的服务实例上。比如对于Nginx,当一个策略配置完成后,就要同步到指定的服务器上生成新的配置文件并Reload。对于配置中心模式的策略,也就是Spring AOP模式的限流,在控制台上配置完成后,就要将配置值同步更新到配置中心里,同时再通过运行时的依赖注入,在线上运行的业务代码中生效。

    整体简化的示意图如下:

限流降级的难点

上面整体介绍了限流降级的解决方案,我们可以看到涉及到很多新概念,各种不同的限流类型,同时还有比较复杂的技术细节,所以要清晰地理解这些概念。

对于降级,主要是针对RT来进行判断,它的整个技术方案没有限流这么复杂,且思路上跟限流是相似的,所以我们就不再单独介绍降级的技术方案了。

从整个建设过程来看,我的体会是,限流降级的难点和关键还是在于整体技术栈的统一,以及后期对每个应用限流降级资源策略的准确把握和配置

我们先来看整体技术栈的统一,这其实也就是我们在专栏最开始就讲到的标准化建设。这里我们会基于一个统一的技术栈进行限流降级方案的设计,要求有统一的Web服务器类型。对服务化框架、各类分布式框架以及代码开发框架(如Spring),这些都要有很明确的要求。如果这里面有某些应用使用的框架不同,那么这套统一的方案就无法推广落地。

我们在实际推广过程中就遇到很多类似的问题,导致大量的时间耗费在技术栈统一上,甚至会要求业务代码做出改变和调整,代码上线运行后再进行统一,这个代价是非常大的。

这也是为什么我们在一开始就非常强调标准化的重要性。这里我们再强调一下标准化,再来复习一下以应用为核心的运维体系的思维导图。

再来看对应用的限流降级资源策略的把握,这个就需要对应用和业务有深入的了解。比如开发人员要非常清楚哪些接口是核心接口,它的来源和去向有哪些;哪些来源是核心的,哪些是非核心的;如果要限流,需要对哪些接口限流,同时要重点保障哪些接口等等

对于限流和降级的具体策略,就是QPS和并发数的配置,也要来源于线上实际运行维护的经验,才能知道配置多少是合适的,配置太大没有限流效果,太小又会频繁触发限流,影响正常业务运行。

所以,限流和降级也是一个动态调测和完善的过程,对于有些动态变化的资源是做不到一劳永逸的。

怎么办呢?一方面我们要依赖人的经验;另一方面,从最终的解决方案看,当调用次数和日志达到一定体量时,我们希望能够借助机器学习算法的手段,来帮助我们分析什么样的设置是最合理的。

今天我们讨论了限流和降级的概念、解决方案以及难点,欢迎留言与我讨论。

精选提问

  1. 又看到机器学习了

    场景复杂到一定程度,体量大到一定规模,就必须要靠算法的力量了。
    
posted @ 2020-07-24 15:49  PassZhang  阅读(69)  评论(0编辑  收藏