浙江移动生产全链路压力测试“和压压”的探索之旅

Posted 2021-05-02 三墩IT人

       戴安妮          性能测试工程师

       林文英          测试架构师

一、背景

这次上线的版本对系统会有多大的冲击，明天能否稳定运营；我们的系统容量当前处于什么水位，还能支撑多久的业务增长，这些是时常浮现在IT运维人员脑海里的性能问题。不管我们在上线前做了多么充分的性能测试，但是上线后总还是会出一些性能问题，似乎上线必伴随着性能“噩梦”。

究其根本，在于线下测试无法还原真实业务场景。因此我们探索直接在生产环境进行全链路压力测试。生产全链路压力测试，是指在生产环境进行，模拟真实用户发起，覆盖核心系统核心业务的持续性大并发压力测试，通过观察记录各项服务和资源的健康度指标，评估系统的处理能力、资源消耗情况和稳定性

结合业务需求，我们的压测目标分为3个阶段：

1. 衡量上线风险：测试上线后系统的性能变化，保证次日生产环境稳定；

2. 评估当前容量：测试系统的容量极限，验证当前是否处于安全水位；

3. 指导容量规划：定位系统短板，并确定每个环节的资源最佳配比。

二、解决方案

生产压测的困难众所周知，1、压力过大影响真实用户使用，甚至系统崩溃，2、较难模拟真实业务场景，3、测试产生脏数据。根据上述三个难点以及3阶段目标，我们立足于移动业务的特性，开始了探索生产压测的征程。

2.1 查询类业务压测

通过对移动业务建模，查询类和受理类业务的比例接近7:1，因此我们考虑用查询类业务代替受理类发起测试。

通过进一步分析，调用量最高的23个接口，其调用量的和达到所有接口总调用量的85%。因此，我们将这23个接口对应的5个前台页面作为最终的测试对象，包括“用户信息查询”、“综合信息查询”、“受理记录查询”等。

图 1 查询类业务压测模型

在该模型中，是由查询类业务代替了受理类业务，因此产生的压力可能会跟真实场景存在偏差。我们通过对比压测的数据与真实数据来验证该模型的有效性，发现偏差在8%左右，即同样的接口调用量，压测对系统资源的总体消耗率与真实场景相差了8%，但是接口响应时间和业务成功率等业务指标基本相同。

图 2  压测有效性对比图

虽然该模型的测试结果与真实情况存在偏差，但已经能够满足我们的第一阶段目标，即评估上线后系统性能的变化。我们每次都使用相同的测试场景，包括测试业务、测试数据和测试压力，并且在每次上线后固定的时间段内对系统发起测试，观察系统各项指标的变化值。

2.2 引流压测

由于纯粹的查询类业务压测，跟真实业务存在一定的差异，而模拟受理类业务压测需要定制化压测工具的支撑和系统改造，周期较长。因此，我们考虑对真实业务进行引流，形成单集群的压力测试。

以移动业务相对较小的远程写卡系统为例，app层总共有4台主机，每个主机上部署了1个集群，每个集群又分割了2个实例，因此，app层总共有8个实例，他们部署的应用程序是一模一样的。即，我们可以将任意一个实例上的业务请求引流至其他实例且不影响业务处理。

图 3 远程写卡系统架构图

目前浙江移动的所有系统架构都是基于一整套的中间件，每个环节均有多个集群做负载均衡。所以，可以通过调整负载策略，实现业务的引流。但是由于对系统的容量没有十足的把握，我们选择在业务量较少时进行引流压测，并且在保证安全的前提下逐步增大引流压力。

图 4 引流压测模型

由于引流压测使用的是真实业务，既不会对系统造成额外的压力，也不会形成测试脏数据，应用非常便捷。但是，引流的压力是真实业务产生的，无法随意进行细粒度的调整，也不能压到系统的极限容量，以免影响真实业务处理。因此我们最终得到的是一个实例/集群的近似容量值。并基于集群的线性扩展性，估算系统的整体容量。

2.3 混合场景压测

爆发式的业务增长一般是基于特殊的业务场景，而且主要是受理类业务。比如“充值送话费”活动，“空中充值”、“银行充值”是主要操作对象；而年末的业务高峰，主要是由“用户积分兑换”等业务引起的。因此，我们需要模拟混合业务场景对系统进行压测，测试系统的性能短板，并指导资源的最佳配置。

1) 压测模型

参考引流压测模型，对于集群部署的系统，我们可以通过对一个集群的压测结果，推广到整个系统。

图 5 混合业务压测模型

首先，隔离出一套集群，集中火力对该集群进行压测。在测试过程中，不断调整每个环节的实例数量，使整个系统的资源达到最优配比，即随着业务量的增长每个环节的资源使用率增长比例相当。该最优资源配比即可用于指导系统扩容或者调整现有的资源配置，使整个系统的资源利用率最大化。

1) 功能组件

我们基于开源的JMeter工具做定制开发，形成全链路压测工具“和压压”，其工作原理如下：

图 6 “和压压”工作原理图

• 控制台

  i. 配置测试场景，并负责将测试脚本以多进程/多线程方式在压力生成器上运行；

ii. 通知代理器进行数据初始化或清理；

iii. 搜集测试过程中被测系统各个环节的性能数据。

• 代理器

i. 根据要求进行生产数据的初始化或者清理测试产生的垃圾数据。

• 压力生成器

i. 根据要求模拟一定数量的虚拟用户对被测系统发送业务请求，实现对被测系统的压力测试，其中一个虚拟用户对应一个业务并发；

ii. 发送测试的过程及结果数据信息给控制台进行采集汇总。

• 分析器

i. 分析并展示测试结果。同时对测试结果进行保存。

2.4 压测保障

由于大并发的压测可能会占用了过多资源导致真实的业务请求得不到及时响应，甚至崩溃。因此，我们的压测一般在凌晨进行，并在真实业务量开始上涨前结束。另外，我们还组建了专业的团队进行压测保障，包括监控、应急和功能验证。

• 监控团队

借助于监控系统，对各项健康度指标的监控。一旦指标超过设定的阀值，即表示系统已出现不稳定的情况，需立即停止测试。

表 1 压测监控项

	监控项	监控指标
系统健康度指标	主机资源消耗监控	CPU使用率
		内存使用率
		磁盘IO
		网络连接数
	软件资源消耗监控	线程使用数
	数据库监控	数据库连接数
业务健康度指标	接口监控	接口调用量
		接口平均响应时间
		接口系统成功率
	查询代理监控	查询代理调用量
		查询代理成功率
	日志监控	错误日志量

• 系统应急团队

由各专业组抽调人员组成虚拟团队，包括主机专家、数据库专家、应用维护专家，当出现系统崩溃时迅速响应。

• 功能验证团队

测试结束后，由功能测试专家组成验证团队，进行核心业务的回归验证，保证系统各项业务正常。

三、实施效果

浙江移动生产全链路压力测试目前已覆盖新营业厅、合作式渠道等多个核心系统，并通过压测规避了多起故障。

• 发现系统登录异常

在某次上线结束后，功能验证正常，但是在压测时，发现小部分账号登陆失败。经多次手工登陆验证，偶发性地登陆后的组织切换页面空白。经排查是提供系统内部跳转服务的某个实例异常，由于另一个实例仍能提供服务，因此只有小部分账号登录失败。经重启该实例后，业务恢复正常。

• 发现合作式渠道性能瓶颈

在合作式渠道压测过程中，发现渠道app的主机CPU使用率接近100%，导致测试压力集中在该层无法向后端传递，因此确认合作式渠道的性能短板在渠道app层。经紧急扩容后，性能瓶颈得到缓解。

四、后续建设思考

目前，受理类业务的测试场景较局限，暂不支持复杂的业务。后续将扩大压测范围，进一步提升测试场景与生产实际场景的拟合度。

另外，目前的压测都是选在凌晨业务量低谷时进行，需要大量的人力进行保障，后续需提高压测的自动化和智能化，实现无人值守的的生产全链路压测。

---