高德全链路压测——语料智能化演进之路

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
性能测试 PTS,5000VUM额度
简介: 高德全链路压测平台TestPG从无到有,在经历过常态化压测后,已基本可以保障高德的所有全链路压测和日常压测,达到了平台初期快速、准确压测和全链路压测的目标。而语料生产(流量处理)作为全链路压测的重要环节,本文将对此做重点介绍。

背景
高德地图作为日活过亿的国民级出行生活服务平台,承载着海量用户服务的是后台的超大规模集群。从用户角度,如果出问题,影响会很大。3机房异地部署造成线上环境复杂,链路复杂。在这样的条件下,如何避免因故障造成用户的伤害,以及在复杂链路条件下做好容量规划,做好灾备,并在第一时间发现问题,通过流量控制和预案演练做应急响应就显得至关重要,而所有的工作都不能等到事情发生之后才做,我们需要有一种验证手段来做好提前性能摸底,这就是全链路压测,让真实的流量提前到来。

全链路压测作为线上服务稳定性保障的重要手段,对高德来说也是非常重要的。高德全链路压测平台TestPG从无到有,在经历过常态化压测后,已基本可以保障高德的所有全链路压测和日常压测,达到了平台初期快速、准确压测和全链路压测的目标。而语料生产(流量处理)作为全链路压测的重要环节,本文将对此做重点介绍。

一次全链路压测可简单总结为3步:压测前的流量处理(也就是生产语料)、压测中确定压力模型启动压测、压测后的结果分析与问题定位。每次全链路压测,压测前的流量处理是整个压测过程中最耗时的一环。过去往往由运维采集日志交给测试同学写脚本处理,耗时相当严重、成本巨大,且存在请求过期等诸多问题。基于这些问题,高德全链路压测平台TestPG前期已规范了高德压测的语料格式,统一了高德压测的流量处理流程。但随着高德全链路压测的演进,后续面临两个主要问题:

语料生产流程缺乏统一管控。虽然平台前期已规范了语料格式,但各业务只是按照语料规范处理流量,生产流程缺乏统一、标准化管控,导致语料生产成本依然很大。尤其对于全链路压测来说,语料准备是最耗时的环节。

接口级别的精准控压无法满足需求。高德作为国民级的出行应用,流量受天气、地形、节假日的影响比较大。比如拿驾车导航来说,日常大多都是短距离的驾车导航,而国庆、春节大多都是长距离的驾车导航,而长距离的驾车导航对后端算力的要求是非线性增加的,甚至是成倍增加。但长短距离的驾车导航对压测平台来说是同一个接口,而平台目前的精准控压只能做到接口级别,无法模拟接口特征级别的压测。

基于以上两大问题,高德全链路压测团队设立语料智能化专项,重点解决以上相关问题。

解题思路和路径

引流标准化
高德的全链路压测彼时已基本拉通大多业务,但还属于一个演进阶段。对于语料处理,主要由各业务自行处理后用来压测,语料处理的来源缺乏统一性,日志、ODPS、流量等处理来源司空见惯。对于语料生产流程的统一管控,我们首先想到的是统一语料处理来源,必须选择一个低成本、高效率的方式作为语料生产的输入,而流量录制的方式就很切合。经过调研,发现高德其他业务场景对流量录制也有很大的需求。但高德过去的流量录制方式并不统一,各业务线自行拷贝流量经常会引起线上机器不稳定等问题。所以首先要做的是统一高德的流量录制,标准化引流。

语料生产平台化
要统一管控语料的生产流程,上面已经统一了语料生产的输入,接下来就是如何把流量转化为符合平台规范的语料,把整个转化流程平台化。但对于高德业务来说,各个业务都有其自身的特点,如果让平台为每个业务提供定制化的处理逻辑成本巨大,再加上平台对各个业务并不是特别熟悉,也很容易出错。而整个语料处理过程也存在一些通用的处理逻辑,所以我们必须提供一种既支持各业务定制化需求,又可以满足平台通用处理逻辑的方案。我们最终选择通过Flink来完成整个流量处理逻辑。

引流已经标准化,业务方只需查看流量的格式内容,编写Flink的UDF(用户自定义函数),处理自身业务定制化的需求即可,而后续通用的语料存储等逻辑可通过Flink的sink插件来完成。这样既可以提供通用处理逻辑,又给业务的特殊需求提供了支持,扩展性良好。

语料智能化
上面已经提到高德这种国民级出行应用受各种环境影响比较大,如何达到接口特征级别的精准控压,是当时面临的又一大难题。平台已具备接口级别的精准控压,只需把接口按照特征分类,提供真实流量的特征分布即可。但流量的特征分布是实时变化的,如何提供符合流量高峰的特征分布是语料智能化的最终目标。

要实现语料智能化需要经历3个阶段。第一阶段是流量特征统计。我们需要明确影响流量变化的因素,体现到流量上就是具体的参数分布,具体有哪些参数会随着外界环境的变化而变化。当然这块高德大多业务线都有一些粗略的分析结果,前期可以直接采用,后期就需要有更细粒度的特征分析。

第二阶段是流量特征提取。有了具体的特征参数后,就需要对特征参数进行提取统计,后续可用来做智能预测。但特征参数的提取到底应该如何去做呢?经过综合分析发现放到语料生产的环节最合适。引流拷贝流量,语料生产环节用来处理流量,在这个环节提取特征参数再好不过了。而整个语料生产扩展性良好,对用户的特殊需求通过UDF完成,整个流量特征提取刚好可以在通用逻辑里面完成。

第三阶段就是智能预测与机器学习。有了特征参数的统计数据,就可以借助往年高德地图国庆或春节的流量特征,加上今年随着业务的流量变化趋势,智能预测出符合今年国庆或春节流量特征的数据,做到接口特征级别的精准压测,做到真正意义上的全链路压测,为高德地图服务的稳定性保驾护航。后续也可以借助机器学习自动发现影响流量变化的特征参数,自动采集分析,做到真正意义的语料智能化。

整体方案
dongkai1.png

整个引流工作将由开发的统一引流平台来完成,引流平台通过引流插件把流量缓存到Kfaka,最终落盘到ODPS。而整个语料生产服务直接对接引流平台,处理来自ODPS的流量即可。

语料生产服务的整体处理过程都由Flink来完成。用户只需编写Flink的UDF来完成自己业务线定制化的需求即可。而且整个Flink的UDF支持多参数传递,用户可灵活编写UDF,在执行过程中动态传递相关参数,解决请求过期等问题。

Flink sink是由平台开发的一个Flink源表解析插件,主要包括流量的特征分析与提取,以及把生产好的语料按照接口命名写入OSS供平台压测使用。目前流量的特征由各业务线自己提供,通过在平台添加完成。Flink sink在执行过程中调用平台开放API获取特征数据进行采集,最终上报给平台,平台后续再根据这些数据进行机器学习,智能预测出符合流量高峰的流量特征,供全链路压测使用。

核心功能介绍

Iflow引流平台
基于上面的问题分析,高德工程效率团队积极迎接挑战,短短几个月开发了Iflow引流平台,对高德的引流进行了统一管控,具体如下图所示:
dongkai2.png

Iflow引流平台以任务的方式对高德的引流进行管理。目前采用引流插件的方式进行流量拷贝(后续将支持更多引流方式),流量通过Kafka缓存,最终写入ODPS供大家使用。用户只需要从ODPS提取需要的数据即可。而启动引流需要相关负责人审批,周知到关联业务,有效的降低了引流引起事故后排查的成本。

TestPG语料智能化
高德全链路压测平台语料智能化主要由3个模块组成:业务线管理、压测名单管理和接口比例管理。业务线管理主要用来管理高德各个链路的相关数据,包括关联引流任务、启动引流、引流记录、语料路径、压测header管理和触发语料生产等功能。一条业务线就是一条压测链路,从引流到语料生产以及语料特征分析等都是在业务线维度完成的。具体如下图所示:
dongkai3.png

功能介绍

  • 关联引流任务:主要完成和引流平台任务的关联以及配置相关的参数。
  • 启动引流任务:启动引流平台任务,在引流结束后会自动触发语料生产,通过执行用户编写的Flink UDF和平台开发的Flink插件,完成语料的生产和特征参数的提取。
  • 语料路径:在每次启动引流触发语料生产后平台会自动生成语料路径,用户可在创建语料的时候自主选择。
  • 压测header管理:每条业务线都有自身的业务特点,在header上的体现也不同,这里主要用来管理压测http服务发送的header内容。
  • 触发语料生产:语料生产有2条途径,一是关联好引流任务启动引流后会自动触发语料生产,包括特征参数提取等一系列的操作;二是在引流成功后,用户可能对UDF等参数有所修改,也可以通过此按钮来触发语料生产。

压测名单管理主要用来管理压测的接口。一个公司开始做压测,业务肯定是需要跟着去适配的,随之而来的就是业务改造,这是一个漫长的过程。为了方便管理,高德全链路压测平台对高德这边的接口进行统一管理。具体如下图所示:
dongkai4.png

压测名单是在引流过程中自动上报的,引流只要发现未在压测名单的接口就会自动上报压测平台,平台根据关联应用去关联对应的负责人,并推动确认。如果可压测就确认为压测名单,下次语料生产作为白名单正常引流。如果不能压测就区分为免压接口或待跟进接口。待跟进接口平台后续会以消息通知的形式推动业务线改造,最终达到真正意义的接口覆盖全、链路覆盖全的全链路压测。

接口比例管理前期主要是用来管理BI提供的、以及每次全链路压测调整的比较贴近真实情况的接口比例数据,作为后续全链路压测的一个参考。后期将通过语料生产提取流量特征的统计数据,智能分析预测出符合真实情况的流量比例,供全链路压测直接使用,具体如下图所示:
dongkai5.png

平台优势

语料平台化生产
整个语料生产对接了引流平台,并通过Flink来完成。既支持了业务方定制化的需求,也支持平台通用化的处理逻辑,扩展性良好。通用逻辑通过Flink sink来实现,并加入了流量特征提取等功能,推动了语料智能化的顺利进行。用户只需要学习Flink完成UDF的编写,然后在平台完成相关配置即可。很大程度上提高了语料生产的效率和质量,是语料从格式标准化向生产流程标准化的一大飞跃。

语料智能化
平台在整个语料生产的过程中,通过Flink插件完成了特征参数的统计汇总。目前用户只需在平台完成相关特征的配置,平台在语料生产过程中就会分析特征并统计汇总。有了特征参数的统计数据,将有助于平台后续的智能分析与预测,达到接口特征级别的精准控压,最终达到完全意义的全链路压测。

平台目前已经完成了语料的自动生产,并加入了语料智能化相关的工作。整个压测名单也是通过引流自动上报,后续将通过消息通知自动拉通业务线改造解决。接口比例管理模块也已支持接口比例的展示和调整,最终通过语料特征的智能预测,即可生产出符合流量高峰真实特征的语料。这些都将推动高德全链路压测智能化的演进。

未来展望
高德全链路压测平台语料智能化发展已经有一段时间了,通过大家的不懈努力,语料智能化已完成了语料的自动生产,以及特征参数的汇总和提取,为后续智能化奠定了基础。未来平台将通过机器学习的方式分析学习采集到的特征数据,根据往年流量高峰的特征情况,加今年流量的变化趋势预测出符合今年流量高峰的特征情况,做到接口特征级别的精准控压,完全模拟真实流量压测达到真正意义的全链路压测。

此外,平台将会借助机器学习自动分析发现影响流量变化的参数,自动提取分析,提高语料生产的准确性。

平台也会有置信度评估系统,分别对比真实的流量特征和预测的流量特征,分析产生误差的原因,进一步提高预测的精准度,做到完全真实的流量生产。后续配合平台的精准压测、压力模型和监控等功能达到真正意义的无人化、智能化的全链路压测。

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
相关文章
|
7月前
|
监控 Cloud Native 测试技术
PTS 3.0:开启智能化的压测瓶颈分析
PTS 3.0:开启智能化的压测瓶颈分析
205750 132
|
7月前
|
负载均衡 NoSQL 关系型数据库
性能基础之全链路压测知识整理
【2月更文挑战第16天】性能基础之全链路压测知识整理
310 11
|
7月前
|
存储 缓存 中间件
高可用之全链路压测
【2月更文挑战第30天】全链路压测是提升系统可用性的关键方法,它模拟真实流量和业务场景在生产环境中测试,确保性能、容量和稳定性。
|
监控 测试技术 UED
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(1)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(1)
294 0
|
域名解析 网络协议 数据可视化
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(2)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(2)
209 0
|
SQL 监控 关系型数据库
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(3)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(3)
201 0
|
数据可视化 测试技术 定位技术
全链路压测(14):生产全链路压测SOP
从实践经验的角度出发,生产全链路压测在技术实现上没有太多新花样,但要在不同的业务和企业落地,就各有各的实践路径。对于没有太多经验的同学来说,全链路压测的落地,大多还是基于个人的经验和熟悉的领域,即都是在局部作战,缺乏全局的视角和可视化地图。从全局来讲,缺少适用于自己的全链路压测最佳实践。
全链路压测(14):生产全链路压测SOP
|
2月前
|
测试技术 持续交付 Apache
Python性能测试新风尚:JMeter遇上Locust,性能分析不再难🧐
【10月更文挑战第1天】Python性能测试新风尚:JMeter遇上Locust,性能分析不再难🧐
154 3
|
3月前
|
测试技术 数据库 UED
Python 性能测试进阶之路:JMeter 与 Locust 的强强联合,解锁性能极限
【9月更文挑战第9天】在数字化时代,确保软件系统在高并发场景下的稳定性至关重要。Python 为此提供了丰富的性能测试工具,如 JMeter 和 Locust。JMeter 可模拟复杂请求场景,而 Locust 则能更灵活地模拟真实用户行为。结合两者优势,可全面评估系统性能并优化瓶颈。例如,在电商网站促销期间,通过 JMeter 模拟大量登录请求并用 Locust 模拟用户浏览和购物行为,可有效识别并解决性能问题,从而提升系统稳定性和用户体验。这种组合为性能测试开辟了新道路,助力应对复杂挑战。
117 2
|
1月前
|
测试技术 持续交付 Apache
Python性能测试新风尚:JMeter遇上Locust,性能分析不再难🧐
Python性能测试新风尚:JMeter遇上Locust,性能分析不再难🧐
54 3