流量突发、服务过载,分布式服务如何限流阈值?

一、面临的问题

在庞大的云计算+分布式+服务化的系统中,包含着由数万服务节点组成了大型网状结构,调用链路复杂,同一个节点上的服务存在资源竞争关系,而上下游节点间又存在压力传导关系,因此每个服务节点及其上的每个服务均需要实施流量防护。

目前限流、熔断等流量防护技术均比较成熟,但实际应用过程中相关参数设置过于宽松,在外部流量突增时无法发挥理想的防护作用,仍然时常出现服务节点资源争抢、交易超时等问题。

因此,如何合理评估和设置服务的限流阈值,成为一个困扰系统维护人员的难题,本研究课题尝试去寻求一个合理的解。

二、求解的过程

常用服务限流指标

限流就是对超过预设阈值的请求流量,按照规则拒绝部分请求,以保障服务节点的关键资源不被突增的流量耗尽,避免其他次生问题产生。

对于服务节点,比较常用的限流指标有:每秒处理请求数(TPS)、最大并发数。

业务层面要求服务节点达到一定的业务处理能力,往往通过单位时间能处理多少请求进行描述。如果业务已经明确了每秒处理请求数(TPS)的指标要求,可照此设置限流阈值。

而从保证系统稳定可用的角度考量,最好限流指标是:最大并发数。通过限制服务的最大并发数,可以保证任何时刻该服务都不会有过多的并发处理在消耗资源。

理论上这两个指标可以通过下面的公式进行粗略的换算:

并发数=TPS*服务平均响应时间

本文重点讨论最大并发数指标的限流阈值如何评估。

节点整体限流阈值的评估

1、理论分析

限流参数是指触发限流的指标阈值。如果限流阈值设置过大,在流量冲高时不能触发限流,会引发应用服务器过载,性能恶化,服务超时;如果设置过小,则资源使用率一直处于低水位,浪费服务器资源。评估服务节点的限流阈值,就是评估服务节点能同时处理的请求数,也即服务的最大并发数。对于服务节点来讲,服务的最大并发数是由服务线程池的大小决定的,

因此,服务线程池大小就是服务节点整体的限流阈值,它决定了服务节点的处理能力、资源使用情况、运行稳定性。如此关键的参数,建议通过压力测试的手段来评估。

在压力测试过程中找到资源使用率处于较高水位,而服务相应时间内性能没有明显下降的临界点,在这个临界点下每秒处理请求数TPS或最大并发数,就是最优的服务线程池大小。

2、压力测试方法

为了达到更好的评估效果,应让压力测试环境尽量和生产情况尽量保持一致:首先服务节点的硬件配置和生产保持一致,另外节点中各个服务的交易量配比和生产保持一致。如果考虑到测试成本,建议选择交易量占比较大的服务作为测试样本。

对于已经上线运行的服务节点,如果能够录制生产高峰期的真实流量进行回放测试则更为理想。

在压力测试过程中,逐步提高请求的并发,直到服务器资源使用率达到较高水位(如CPU达到80%左右),此时的服务并发数可作为节点的并发限流阈值,也就是服务线程池大小,如下图所示▼。

图片

3、注意事项

压力测试过程中应同步观测服务的平均响应时间是否出现恶化。上图中平均响应时间变化曲线在并发数达到限流阈值之前都比较平稳,是较为理想的情况。

测试过程也可能出现服务平均响应时间恶化,而CPU、内存等硬件资源使用率不高的情况,则提示存在其他瓶颈问题,如数据库访问效率、程序解决线程安全所加的对象锁等,需要排查解决瓶颈问题后再继续压测。

单个服务限流阈值的评估

1、理论分析

服务节点整体限流阈值,可一定程度保护节点的资源使用不会过载使用。但资源有限,而每个节点上运行多个服务,服务之间会发生资源的争抢,因此还需考虑服务级别的限流,不让少数服务占用过多资源。为了限制服务使用的资源,服务并发数是最有效的限流指标。

能否把上一节压力测试的临界点时每个服务的并发数作为每个服务的限流阈值?结合实际情况,答案是否定的。因为节点中各服务的交易量占比随时都在发生变化,不断的此消彼长,这样的限流阈值过于片面,缺乏弹性。

为了评估每个服务的限流阈值,需要对每个服务分别开展压力测试。首先要评估每个服务允许使用的资源占比多少,作为压力测试中取临界点时要达到的资源使用率目标。

根据服务重要程度高低,其允许占用的资源使用率有所不同,如快捷支付服务节点中,支付服务可以允许消耗节点绝大部分的资源,而其他查询、维护类服务允许获得的资源则较少。

2、压力测试方法

根据每个服务的重要程度设定其资源使用率的最大值,单独进行压力测试。每个服务压测时,逐步提高请求的并发,直到服务器资源使用率达到目标水位(如CPU达到50%左右),此时的服务并发数可作为节点的并发限流阈值,如下图所示▼。

图片

3、历史数据分析预测法

在实际应用中,每个服务节点的服务数少则几十,多则几百,所有的服务全面进行压力测试的人力和时间成本太高,一般只能对少量关键服务进行压力测试。

但服务限流的目标主要就是限制非关键服务的并发,保障关键服务的资源供给,仅设置关键服务的限流阈值没能达到这个目标。因此压力测试方法计算服务限流阈值存在成本和收益矛盾,需要寻求其他解决方案。

我们从生产监控数据中获取过去一段时期服务每日最大并发数进行分析,发现历史最大并发数对评估服务限流阈值具有参考意义,但需要解决以下问题:

问题1:由于负载均衡算法是随机算法,同一个服务集群中不同节点的负载并不均等,最大并发数存在一定的随机性,有一定概率出现毛刺。

另外,系统中一些故障导致服务处理缓慢或卡顿,也会造成服务并发数出现非正常增长。这些异常数据均不应作为评估限流阈值的依据;

问题2:随着业务推广,服务的交易量会不断增长,未来最大并发数可能会较快突破以原先的历史最大并发数。

针对上述问题,可以对服务并发数的历史数据进行一定处理,让限流阈值变得更加合理:

1、对历史数据进行降噪处理,排除因随机或故障引起的异常数据

考虑到某些业务的促销活动有周期性,如每年618、双11,因此需要获取1年以上历史数据自以为分析依据。假设数据符合正态分布,绝大多数的数据距离均值不超过三个标准差(99.73%),因此把距离均值超过三个标准差的数据作为毛刺去除。

2、对历史数据进行趋势预测,为未来业务发展预留合理增长空间

考虑到数据量和计算成本,我们选择典型的时序分析模型:自回归移动平均模型ARMA,ARMA模型结合了自回归(AR)和滑动平均(MA)的特性,预测结果综合了时间序列数据中的趋势和波动性。下图是使用ARMA模型绘制出的某个服务并发数未来3个月的变化趋势及置信区间(置信水平设置为0.99),置信区间的上限可作为服务的限流阈值。

图片

三、实践的情况

根据上面的理论研究和方案探讨,可以得出结论:对于服务节点整体限流阈值,应使用压力测试方法进行评估;对于单个服务的限流阈值,则通过并发数历史数据进行降噪处理和趋势预测,较低成本地生成推荐值。

研究课题的落地实施过程中,我们研发了一套流量防护参数管控系统,从生产监控历史数据中获取过去一年服务的每日最大并发数,然后根据前面研究中提到的算法,对这些数据进行了降噪处理和趋势预测等分析计算,得到服务限流参数的建议值,并为用户提供查询和主动推送服务。

图片

这套流量防护参数管控系统已经为几十个业务系统推荐了限流参数,用户反馈该系统推荐的限流阈值较为合理,能更加有效地防范流量突增带来的风险,保障服务节点稳定运行。

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 是的,我知道一些常用的分布式限流工具。以下是一些比较流行的限流工具: 1. Redis: 使用 Redis 可以简单地实现限流,特别是滑动窗口限流。 2. Guava RateLimiter: Guava 是 Google 的 Java 工具包,其中 RateLimiter 可以提供高效的令牌桶限流。 3. Bucket4J: Bucket4J 是一个 Java 库,可以提供功能强大的令牌桶和漏桶限流。 4. Netflix Zuul: Netflix Zuul 是一个微服务网关,内置了对限流的支持,可以很方便地在应用程序的边界处实现限流。 这些工具都有不同的优势和特性,请根据您的具体需求和环境选择适合您的工具。 ### 回答2: 有一些好用的分布式限流工具可以帮助我们实现系统流量控制和限流,以下是其中几个常用的: 1. Alibaba Sentinel(阿里巴巴开源):一个功能强大的分布式系统流量防卫士,支持实时的流量控制、熔断降级、系统保护等功能,提供了丰富的配置和管理方式。 2. Spring Cloud Gateway:Spring Cloud生态系统中的一个网关工具,可以通过使用过滤器和限流机制来实现分布式限流,支持基于QPS、令牌桶等算法进行限流控制。 3. Nacos(阿里巴巴开源):一个用于动态服务发现、配置管理和服务治理的平台,其中包含了限流的功能,可以通过配置限流规则来实现请求的限制。 4. Redis+Lua脚本:通过在Redis中使用Lua脚本来实现限流功能。可以利用Redis的高性能和原子操作特性,结合令牌桶、漏桶等算法来实现流量控制。 5. ZooKeeper:一个分布式协调服务,可以用于实现分布式限流。可以利用ZooKeeper的有序节点特性和Watch机制来控制请求的并发量。 这些工具各有特点,具体选择取决于应用场景和需求。在实际使用时,需要根据系统的规模、性能需求和业务特点等因素,综合考虑选择合适的分布式限流工具。 ### 回答3: 当今的分布式系统越来越复杂和庞大,限流是保证系统稳定性和高可用性的重要策略之一。以下是我所知的几个好用的分布式限流工具: 1. Redis:Redis是一个高性能的内存数据存储系统,通过其提供的分布式缓存和限流功能可以实现简单而高效的限流逻辑。需要利用Redis的计数器或令牌桶等数据结构,将请求和访问进行计数,在达到限流阈值时进行拒绝或延迟处理。 2. Sentinel:Sentinel是阿里巴巴开源的一款分布式流量控制组件,它提供了流量控制、熔断降级、系统负载等功能。通过在每个服务节点上配置规则,可以统一限制请求的数量,避免系统被过多的请求压垮。 3. Nginx:Nginx是一款高性能的开源Web服务器,也可以用作分布式限流工具。通过配置Nginx反向代理服务器的限流策略,可以限制请求的并发数、连接数等,而且能够根据不同的URL或IP设置不同的限流策略。 4. Alibaba Yet Another Distributed Rate Limiter (Sentinel):Sentinel是一个用于流量控制的分布式限流组件,由Alibaba开源。它具有动态规则的特性,可以基于各种参数和维度(如QPS、线程数、CPU负载等)对请求进行限流,以保护系统免受过载。 以上是一些我所知道的分布式限流工具,每个工具都有其独特的特点和适用场景。根据具体的需求和系统架构,选择适合的工具进行分布式限流是非常重要的。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值