流量突发、服务过载?中国工商银行是如何“求解”分布式服务限流阈值的?

【供稿】中国工商银行软件开发中心


面临的问题

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

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

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


求解的过程

常用服务限流指标

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

对于服务节点,比较常用的限流指标有:每秒处理请求数(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),置信区间的上限可作为服务的限流阈值。

实践的情况

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

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

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

还不过瘾?还想了解更多大型系统的优秀实践?10月26-27日,GOPS 全球运维大会 2023 · 上海站,更多企业 DevOps、AIOps、可观测性、FinOps、SRE,就在 GOPS!

长按图片二维码更精彩

近期好文:

运维如何解决 K8s 多租户的安全隔离难题?请收好这篇实践

“高效运维”公众号诚邀广大技术人员投稿
投稿邮箱:jiachen@greatops.net,或添加联系人微信:greatops1118。

标签

发表评论