高德全链路压测平台TestPG的架构与实践 (5)

高德全链路压测平台TestPG的架构与实践

高德压测平台的现状

高德压测平台从2018年开始启动,经过大半年的发展,已经成功支持了高德2019年春节全链路压测,2019年五一全链路压测,在施压能力方面达到百万级别。

目前高德压测平台包括语料生产,场景构造,压测资源管理,压测任务调度,压测过程监控,压测调试,压测错误排查,压测报告生成,压测报告评估(对比基线,从QPS,rt,cpu,mem这几个维度进行压测结论的评估)等功能。

平台从2018年底投入使用至今,共执行几千次的压测。通过开放api的方式,平台开放压测能力,现已成功和持续交付平台打通,为持续交付提供可靠的性能指标。

自春节后,平台主要致力于降低压测门槛,提升压测效率。对于大部分简单的压测需求,从原有的语料->场景->任务逐级构造模式简化为一键压测模式,在初次使用平台成本方面,简单的压测工作预计能从平均3小时,减小为平均30分钟。

虽然高德压测平台在近一年的时间里,取得了一些成果,我们也支撑了几次全链路压测。但是我们的全链路压测还不能完全满足上文的三个要求,其中最关键的场景真实性还无法得到保证,"全链路压测" 对于高德来说,还是远方,我们还有很多路要走,还有很多困难要克服。

高德压测平台的未来

在可见未来里,我们期望在以下几个方面去探索和实践:

全链路监控

TestPG目前的监控是基于用户自定义链路的监控,在链路真实性上无法得到保障。未来我们将会与运维团队合作,打造基于EagleEye链路自动梳理的全链路监控。除了基本的系统指标监控功能外,TestPG平台还会在下面的几个方面进行探索:

监控大盘,全面的展示系统的状态

短板机器,短板服务的识别

基于时间序列的性能问题挖掘

结合邮件,钉钉等手段,对发现的问题进行及时的报警

简化语料生成流程

目前压测语料的生成采用的是用户自定义脚本的方式。平台定义好语料目录格式,语料文件格式,用户编写语料处理(一般以日志文件为基础)的程序,然后上传到平台。平台会执行用户提供的程序,然后在将程序的输出文件存储在OSS上,以备压测之用。

这种方式降低了平台的实现成本,也给用户提供了足够灵活度,但是增加了语料的处理门槛。未来我们会将这部分工作全部交由平台来处理,用户只需要提供原材料,配置生成规则即可。

丰富压力模型

TestPG平台目前的压力模型是Jmeter原生的,为了最大限度的接近真实场景,在压力模拟上,我们还需要具备如下几种压力模型:

步进施压

抖动施压

脉冲施压

压测置信度评估

压测场景能否代表真实的用户场景?这是一个TestPG目前还无法回答的问题。场景的真实性现在依托于业务同学的经验,业务同学按照自己抽象出来的业务模型对原材料(通常是线上日志)进行处理,生成平台规定格式的预料文件。语料对平台和用户来讲,都是黑盒子,除了被测系统外,没人知道语料的模型是否接近真实世界的用户场景。

因此,我们期望通过一些技术手段来对压测场景的真实性进行一个科学的评估,这便是压测置信度评估。置信度评估的目标是评估压测的场景和我们期望的场景相似度,下面是压测置信度评估需要探索的方向:

建设场景特征库(例如五一,十一,春节)

基于特征库的压测场景置信度评估

基于地理位置的压测场景置信度评估

基于链路覆盖度的压测场景置信度评估

基于流量模型的压测场景置信度评估

结合上述维度的评估数据,我们可以给出一个具有价值的评估报告,作为一个重要的参考,可以帮助用户评估压测的效度。

链路改造

TestPG平台的中期目标是要支撑高德业务的全链路压测,成为高德系统稳定性的试金石。但现在我们离真正的全链路压测的距离还很远,我们的压测场景只覆盖了读请求,还不具备支持写请求压测的能力,原因是系统还不具备全链路流量识别的能力,还不具备隔离压测流量的能力。未来,全链路压测,全场景覆盖是必经之路。

 

高德全链路压测平台TestPG的架构与实践

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zwsxff.html