关于性能测试的重要性及必要性已是个老生常谈的问题了,现分别从技术角度和业务战略角度总结一下:
性能测试:解决大型营销活动中洪峰流量引起的系统表现不确定性
- 压测环境准备:复用真实的线上环境,压测结果和问题暴露才都是最真实情况。可通过压测流量全局识别、透传(数据进影子区域),我们采用第一种方案,压测流量全局识别;
- 基础数据准备:以电商场景为例,构造满足大促场景的核心基础相关数据(如买家、卖家、商品信息),以线上数据为数据源,进行采样、过滤和脱敏,并保持同等量级。
全链路压测示意图:
一、压测环境改造
数据准备的同时,需考虑压测环境(即压测对象的部署环境)是哪里,不同环境就需要做不同的准备。
压测环境,包括双十一压测,全部选择的是线上环境,此时需评估如果要进行全链路压测,是否直接使用现有环境、同一个 API 多次压测是否会被拦截、是否会有脏数据影响、如果有影响应该如何改造避免等。以上这些问题总结下来即为两类问题:业务问题和数据传递问题。
改造分为两方面:业务改造和中间件改造。
业务改造
业务改造即为了解决压测过程中的业务异常问题,或压测请求无法正常被执行的问题。
举例如下:
- 流量区分与识别:压测流量和业务流量的区分,并可在全链路系统中识别出来;
- 流量单一性问题:比如下单,同一个人执行一次下单后再重复执行就会失败;
- 剔除压测数据对报表的影响
- 动态校验
- …
业务改造涉及的内容无法穷举,需根据不同的业务模型、业务架构及配置,逐个梳理。一般梳理改造之后,后续所有新应用都按照规范去开发,每年的压测前进行基础的查漏补缺即可。
中间件改造
中间件作为衔接业务应用之间的组件,在压测中有个至关重要的功能就是将流量标识传递下去,一直到最终的数据库层面。
二、数据准备
主要分为两部分:业务模型的建立和基础数据的构造。
业务模型数据
业务模型数据,即压测的业务模型相关的数据,包括涉及到哪些 API,这些 API 之间的压测量级是什么样的或者有什么样的比例关系等。业务模型的构造准确度,直接影响了压测结果的可参考性。
压测基础数据
如果说业务模型对应的是确定要压测的接口/API 的话,那压测流量数据,就是确定这些压测 API 到底压测的是什么内容,比如:登录哪些用户、查看哪些商品和店铺、购买哪些商品,甚至是付款价格是什么。
流量数据中最重要的部分,即为真实的压测数据,我们可以称之为基础数据,比如交易的买家、卖家、商品数据等。全链路压测的目的是为了模拟双 11,所以模拟的真实性非常重要,基础数据的真实性就是至关重要的一环。全链路压测会以线上数据作为数据源,经过采样、过滤、脱敏等操作,形成可作为压测使用的数据。
四、流量安全策略
流量安全策略主要是为了保证能够正常的施压流量且数据不错乱,安全地、符合预期地进行。
- 测试数据和正常数据的严格隔离,即非法流量的监控和保护机制
- 手段:影子表数据。影子表和线上结构一致,但是处于隔离位置的可写压测数据表
- 效果:数据隔离,避免了数据错乱
- 压测流量的安全过滤,即不被识别为攻击流量
- 手段:将安全相关策略接入流控降级功能;针对压测适当放松安全策略,或根据特殊标记识别
- 效果:压测流量不被判定为攻击流量,成功压测的同时保障线上业务的安全性
五、压测实施
一切准备就绪之后,即可开始进行全链路压测。
可以通过先一轮、低量级的全链路压测,来提前预热系统,包括在真正大促活动之前也可这样操作,即提前缓存住需要缓存的数据。
正式压测
1)峰值脉冲:即完全模拟大促目标峰值流量,进行大促态压测,观察系统表现
2)系统摸高:取消限流降级保护功能,抬高当前压测值(前提是当前的目标压测值已经达到,则可以进行摸高测试),观察系统的极限值是多少。可进行多轮提升压力值压测,直到系统出现异常为止
4)破坏性测试:这个主要是为了验证预案的有效性,类似于容灾演练时的预案执行演练。即为持续保持大促态压测,并验证预案的有效性,观察执行预案之后对系统的影响
压测报告
问题定位分析
压测结束之后,会将压测过程中的系统表现、监控数据等整理,进行压测复盘,分析当前系统瓶颈、后续改进修复计划及下一轮压测时间等。在分析定位问题时,因涉及的系统较多、子业务系统的形态不一,需要具体问题具体分析,其中不免需要一线研发的介入。
咨询方案 获取更多方案详情