饿了么全链路压测平台的实现与原理

背景

在上篇文章中,我们曾介绍过饿了么的全链路压测的探索与实践,重点是业务模型的梳理与数据模型的构建,在形成脚本之后需要人工触发执行并分析数据和排查问题,整个过程实践下来主要还存在以下问题:

  1. 测试成本较高,几乎每个环节都需要人力支撑,费时费力。
  2. 由于测试用例较多,涉及的测试机范围较广,手工执行容易犯错,线上测试尤其危险。
  3. 记录结果和测试报告极不方便,需要二次加工、填写和上传。
  4. 测试过程中靠手工监控,覆盖不全且定位问题困难。

基于这些因素,我们决定推进全链路压测的自动化进程。这篇我们主要介绍全链路压测平台的实践。

目标

为了解决以上核心痛点,平台至少需要保证以下方面的功能:

  • 用例管理:用户建立测试用例,上传资源文件,系统进行分类管理。
  • 压测执行:一键触发已有测试用例,可指定线程数、预热时间、测试周期和测试机等,可以自动切分数据,分布式执行。
  • 实时结果(热数据):响应时间、吞吐量、错误率等数据以图表形式实时显示。
  • 测试结果(冷数据):平均响应时间、平均吞吐量,90/95/99线等数据以图表形式在测试结束后显示。
  • 测试机集群监控:监控测试集群的使用状态,提示用户可用的测试机。
  • 安全保障:平台应该对用户操作进行适当限制,并能自我应对一些异常情况。

主要功能与实现概要

压测平台是典型的B/S类型Java Web项目,基于Spring Boot开发,前端使用AngularJS。平台本身不执行测试只做调度,避免成为瓶颈,后台均使用JMeter执行测试;平台自身会维护压测机集群,保证压测机是可供测试的;测试期间产生的冷数据(用例数据、结果数据)持久化至MongoDB,热数据(实时数据)持久化至InfluxDB并定期清理。

分布式测试

在使用JMeter进行性能测试时,如果并发量比较大,单机的配置可能无法支持,这时需要联合多机进行分布式测试。我们并没有采用JMeter自身的分布式功能,而是自己做了实现,主要是考虑到:

  1. JMeter的分布式测试执行和单机执行方式的差异较大,这会导致平台架构不必要的复杂度,实际用户只感知测试机的数量区别。
  2. JMeter分布式执行的方式,master机通常不参与测试,而是收集slave信息,但这会造成一定程度上的资源浪费。

我们使用饿了么内部的EOC工具对压测机进行调度,并实现了JMeter自身具备的分布式调度功能,相应的对比见下表。基于我们的实现,压测过程中热数据和冷数据是分离传输的,冷数据在测试完成后才会传输(如果不需要压测端数据,甚至可以配置不存储冷数据),因此该方案对于扩容是非常友好的,理论上支持的TPS没有上限。

测试状态流转

测试状态流转是压测平台的核心,每一轮正常的测试工作都会经历一条主线,即:配置 -> 触发 -> 运行 -> 结果收集 -> 清理。测试状态流转的设计围绕着这条主线,辅以外部干预和内部监控功能,保证测试的正常进行。

此外,我们还需要鉴别出各种可能的异常情况(如测试触发失败)和合理情况(如用户主动停止),并据此输出不同的反馈信息,并且无论测试流程出现何种分支,最后都能形成闭环,这对系统的健壮性非常重要。以下是状态流转图:

举两个典型的应用场景:

  1. 用户触发测试后,由于测试压力过大,运维要求立刻停止测试,这时的闭环为:初始 -> BOOTING -> LAUNCHING -> 用户触发停止 -> 直接进入收集流程 -> 状态标记为STOP -> 清理压测机 -> 初始
  2. 用户触发测试后,压测机由于某些原因突然断网,这时的闭环为:初始 -> BOOTING -> LAUNCHING -> 监控发现问题 -> 状态标记为FAILURE -> 清理压测机 -> 初始

整个状态流转的实现,采用异步Job机制实现了类似状态机的概念,状态属性持久化到数据库中,便于恢复。

实时数据

JMeter本身并不提供图形化的实时数据展示功能,以往我们只能通过JMeter Log看到一些粗略的信息,并结合外部监控工具观察指标情况。在压测平台中,我们对该功能进行了实现,主要原理是通过JMeter的Backend Listener (JMeter 3.2+),将测试结果实时发往InfluxDB,同时平台向InfluxDB轮询查询数据,得到实时曲线并展示给用户。

在实践过程中,向InfluxDB发送数据的频次是比较高的,可能会对压测机造成压力,因此我们改造了JMeter的InfluxDB sender,替换了HTTP方式,增加了以UDP协议发送数据的实现,解决了这一问题。

预配置

在“测试状态流转”一节中,阐明了测试的总体流程,第一步即为配置,配置的具体内容是:将测试需要的脚本、数据文件和插件,推送到每一台测试机上,为测试执行做好准备。

但如果测试文件比较大,或者需要配置的压测机数量比较多,配置可能会占用较多时间,影响测试进程,这是很多平台遇到的共性问题。对此,我们提出了预配置的概念,即用户可以提前对测试用例,针对某几台压测机进行配置工作,但并不执行。预配置会保留一定的时间,在这段时间内,用户可以直接执行测试,不需要再重复配置。

以下为预配置的状态转换图:

熔断与兜底

全链路压测一般都在线上真实环境进行,安全是首要考虑的因素,不能因为测试本身而导致服务不可用或事故。我们提供了四个维度的机制进行安全保障。

  1. 权限管理:用户权限分级管理,不能随意触发他人的测试用例,同时高峰期和禁止发布期,不允许执行任何测试。
  2. 停止功能:这是面向用户的手动停止功能,用户可以随时点击运行状态下的测试用例上的停止按钮,后台会直接kill掉所有运行该测试用例的测试机上的JMeter进程。
  3. 熔断功能:系统会根据实时信息中的错误率进行判断,当一定时间内的实时错误率达到或超过某个阈值时,该次测试将被自动熔断,无需用户干预。
  4. 兜底脚本:最极端的情况,当整个系统不可用,而此时需要停止测试时,我们提供了一份外部脚本直接进行停止。

结果收集

由于我们自己实现了JMeter分布式的管理,因此我们也需要自己对结果集进行处理,结果的主要来源为测试生成的JTL文件。

针对JTL,结果数据需要做预聚合再存入,原因是JTL中单条结果数据的大小非常小(大约100多个字节),但总量很大(可能有几万到几百万条),很容易由于重复存储维度字段的KEY值而导致表过大。预聚合主要根据以label作大分类,维度作小分类,以时间作为聚合标准,interval固定,从而保证Document大小不会过大。

以下是结果集片段的数据结构概要(单label):

前端会根据持久化的数据,形成可视化图表,为用户展现。

总结与展望

全链路压测平台自今年7月上线以来,为超过5个部门累计提供了上千次测试服务。按照每一类测试配置和执行的人力成本为15分钟计算,大约节省了1000个小时的工作量。

目前,全链路压测的自动化只是针对测试执行范畴,我们还有很多工作要做,在未来,我们希望能够将自动化的脚步覆盖到测试前和测试后,真正建设出全链路压测的自动化生态体系。

参考:https://www.testwo.com/article/1104

原文地址:https://www.cnblogs.com/unknows/p/8622188.html

时间: 2024-11-06 03:41:30

饿了么全链路压测平台的实现与原理的相关文章

全链路压测资料汇总——业内大厂解决方案

最近忙于公司的全链路压测平台调研和技术规划文档输出工作,参考了全网能搜到的业内大厂的全链路压测方案,这里做个汇总,以及将个人认为可以落地的方案做一个关键点整理. 技术链接 滴滴全链路压测解决之道 阿里巴巴的全链路压测 阿里怎么做双11全链路压测? 美团全链路压测自动化实践 全链路压测平台在美团中的实践 饿了么全链路压测的探索与实践 饿了么全链路压测平台的实现与原理 有赞全链路压测方案设计与实施详解 京东全链路压测系统(ForceBot)架构解密 罗辑思维在全链路压测方面的实践和工作笔记 大厂方案

全链路压测第一次实践

每年双十一,对买家来说是一场买买买的剁手之旅,但对于电商公司的技术人员来说,却是一次严峻的技术期末考.如何保证系统在预估的流量洪峰来临时,既能保证用户的买买买不受影响, 促进业务及营销活动的目标达成,又能用尽可能少的成本投入保障系统的稳定可用性,是技术童鞋必须面对的挑战.我司在双十一来临的最后关口完成了整个核心链路的全链路压测, 大幅提高了核心链路的服务性能,并发布了最终优化版本.在双十一期间,也取得了一定的成果,期间包括技术.运营.产品.行政等各部门都为之付出了很多努力. 下面的内容,是从启动

有赞全链路压测实战

一.前言 有赞致力于成为商家服务领域里最被信任的引领者,因为被信任,所有我们更需要为商家保驾护航,保障系统的稳定性.有赞从去年开始通过全链路压测,模拟大促真实流量,串联线上全部系统,让核心系统同时达到流量峰值: 验证大促峰值流量下系统稳定性 容量规划 进行强弱依赖的划分 降级.报警.容灾.限流等演练 …通过全链路压测这一手段,对线上系统进行最真实的大促演练,获取系统在大压力时的表现情况,进而准确评估线上整个系统集群的性能和容量水平,不辜负百万商家的信任. 有赞对于性能测试主要有线下单系统单接口.

来自滴滴、微博、唯品会、魅族、点评关于全链路压测等问题实践分享

架构师小组交流会:每期选一个时下最热门的技术话题进行实践经验分享. 第二期:因为大家对全链路压测的问题比较感兴趣,因此做了一番探讨. 参与嘉宾:滴滴技术负责人彭令鹏.魅族系统架构师何伟.唯品会应用架构负责人张广平.新浪微博技术专家聂永.大众点评交易平台技术负责人陈一方.七牛云首席架构师李道兵. 本文是对此次交流的整理,欢迎探讨. 第一轮:自由交流 滴滴彭令鹏:大家好,我是彭令鹏,目前在滴滴平台部负责整个专快车业务的稳定性和效率,之前在百度做了5年半的网页搜索部底层架构的工作.现在在滴滴主要在推四

阿里10年分布式技术沉淀:阿里高可用体系核心缔造者、全链路压测创始人告诉你!

原文链接 7月27日,云栖社区.阿里中间件将举办首届阿里巴巴中间件技术峰会,揭秘阿里10年分布式技术干货.目前活动官网已上线:https://yq.aliyun.com/promotion/262, 点击报名. 本次活动看点十足,大咖齐聚.纯正干货,下面给大家做下详解介绍,相信看后定会让你动心! 议题详情 双11核武器全链路压测--张军 / 阿里巴巴中间件高级技术专家 阿里巴巴双11备战期间,保障系统稳定性最大的难题在于容量规划,而容量规划最大的难题在于准确评估从用户登录到完成购买的整个链条中,

技术文章 | 系统稳定性保障核武器——全链路压测

为什么要做全链路压测? 对阿里巴巴而言,每年最重要的一天莫过于双11.这是因为在双11的零点,系统会遭遇史无前例的巨大洪峰流量冲击,保证双11当天系统的稳定性对高可用团队来说是巨大的挑战.在这个挑战中会有很多不确定因素,大致分为两方面: 技术架构带来的不确定性,阿里在08年开始对系统进行拆分,由原有的单一系统拆分成了分布式架构,包括CDN.网关.负载均衡.分布式页面系统等,整体的技术生态十分丰富.分布式环境任意环节出了问题都可能会对系统造成影响: 业务发展带来的不确定性,系统的可用性随着业务增长

京东全链路压测军演系统(ForceBot)架构解密

摘要:全链路压测是应对电商大促容量规划最有效的手段,如何有效进行容量规划是其中的架构关键问题.京东在全链路压测方面做过多年尝试,本文转载京东商城基础平台技术专家文章,介绍其最新的自动化压测 ForceBot 体系. ForceBot愿景 1.诞生背景 伴随着京东业务的不断扩张,研发体系的系统也随之增加,各核心系统环环相扣,尤其是强依赖系统,上下游关系等紧密结合,其中一个系统出现瓶颈问题,会影响整个系统链路的处理性能,直接影响用户购物体验. 往年的 618.双 11 大促备战至少提前 3 个月时间

如何开展全链路压测&全链路压测核心要素

之前对全链路压测概念比较懵,现在简单梳理下,后续有学习到的干货再持续补充:可参考:阿里全链路压测京东全链路压测 1.什么是全链路压测 基于实际的生产业务场景.系统环境,模拟海量的用户请求和数据对整个业务链进行压力测试,并持续调优的过程. 2.全链路压测解决什么问题 针对业务场景越发复杂化.海量数据冲击下整个业务系统链的可用性.服务能力的瓶颈,让技术更好的服务业务,创造更多的价值. 3.如何开展全链路压测?分析压测业务场景涉及系统服务:协调各个压测系统资源:压测环境(需要将请求和访问.业务数据处理

四大语言,八大框架|滴滴全链路压测解决之道

https://mp.weixin.qq.com/s/wX1l9flnrr8K7-fCHAvBWw 四大语言,八大框架|滴滴全链路压测解决之道 青云QingCloud OmniStack 2017-08-09 原文地址:https://www.cnblogs.com/yuanjiangw/p/10848335.html