服务端压测怎么做

2020-04-26

字数统计: 6.1k | 阅读时长≈ 20 分钟

博文的内容并不都是我原创的，行文思路来源于一次内部分享，再结合网上众多参考资料总结出来的，算是一个学习笔记。

可能很多QA、RD同学跟我都一样，对服务端压测一直没有系统的认知，印象停留在使用压测工具如Jmeter对单接口发压，调整线程数和循环数来制造不同压力，最后计算一下TPS和成功率等就完事了？网上虽然有不少压测相关的文章，但多数是压测工具的入门级使用，有的是压测流程和指标的简单解释，或者就是几个大厂牛逼的全链路压测能力和压测平台的介绍。这些文章要不缺少系统性阐述，要不过于抽象不好理解，对没怎么接触过压测的同学不太友好。

本文在QA角度梳理一次完整的压测过程，尝试总结更为普适的压测思路，给大家提供更有意义的参考。

压测背景

测试分很多种，网上很多文章^1会玩弄概念，搬出来3个名词：压力测试（Stress Testing）、性能测试（Performance Testing）、负载测试（Load Testing）。一般情况下并不需要做这么细粒度的概念区分，这3个概念我觉得是没办法完整区分各自边界的，至少在程序逻辑上难以做得到，更多差异只是来自于不同的压测策略，所以尽管忽略这几个概念的区别，都叫它压测或者性能测试即可。

为什么需要压测

拿技术人熟知的阿里举例，应该是国内做压测最好的一个大厂。外界熟知的阿里2012双11活动，2012年11月11日零点，阿里各种系统报错、立刻下单报错、购物车支付报错、支付系统报错、购物车的东西丢失，系统显示交易成功率不到50%，产生了大量超卖，给阿里带来很大的损失。那一年的双11后，库存、商品、退款和相应数据库的同学，为了处理超卖导致的问题，没日没夜加了两周的班，同时给了用户不少糟糕购物体验。

为什么出现这么严重的问题？因为对整个全交易链路上的各个子系统的承受能力不清楚，并且错误预估了可能会达到的流量，也没有完善的预案，兵败如山倒。

2013年阿里首次提出了全链路压测方案：一方面可让链路的各个系统知道自己的承压极限；另一方面可让各个系统有个明确的优化目标，了解到整个链路的瓶颈并评估资源情况。

单系统压测与全链路压测

为什么只做单系统压测还不够呢？

在活动开始的瞬间，各系统都面临自身服务的巨大的压力，而系统之间是有互相依赖关系的，单机压测没有考虑到依赖环节压力都比较大的情况。一个系统出现故障，故障会在链路流转过程中层层累加，会造成无法评估的影响。

所以最可靠的方式是完全模拟真实场景来压测，通过线上全链路压测提前发现问题。

压测流程

完整的压测流程一般包含下面几个步骤，引用自文末参考资料：

压测目标的制定
压测链路的梳理
压测环境的准备
压测数据的构造
发压测试
瓶颈定位及容量微调
压测总结

压测目标

压测作用

新服务，无预估目标，需要通过压测得到服务基准数据或找到系统瓶颈进行优化
有明确的压测目标，需要通过压测确定服务的各项指标是否达标
常态化压测，为后期性能优化指导方向或提供参考依据

压测指标

列举一些常用指标，并不一定都需要关注，根据业务考虑指标的细化粒度。

QPS：Query Per Second，每秒处理的请求个数
TPS：Transactions Per Second，每秒处理的事务数，TPS <= QPS
RT： Response Time，响应时间，等价于Latency
RT分平均延时，Pct延时（Percentile分位数）。平均值不能反映服务真实响应延时，实际压测中一般参考Pct90，Pct99等指标
CPU使用率：出于节点宕机后负载均衡的考虑，一般 CPU使用率 < 75% 比较合适
内存使用率：内存占用情况，一般观察内存是否有尖刺或泄露
Load指标：CPU的负载，不是指CPU的使用率，而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息，表示CPU的负载情况，一般情况下 Load < CPU的核数*2，更多参考链接1和链接2
缓存命中率：多少流量能命中缓存层（redis、memcached等）
数据库耗时：数据库就是业务的生命，很多时候业务崩掉是因为数据库挂了
网络带宽：带宽是否瓶颈
接口响应错误率 or 错误日志量

这里要说明一下QPS和TPS的区别：

QPS一般是指一台服务器每秒能够响应的查询次数，或者抽象理解成每秒能应对多少网络流量
TPS是指一个完整事务，一个事务可能包含一系列的请求过程。举个🌰，访问一个网页，这是一个TPS，但是访问一个网页可能会对多个服务器发起多次请求，包括文本、js、图片等，这些请求会当做多次QPS计算在内，因为它们都是流量

性能测试中，平均值的作用是十分有限的，平均值代表前后各有50%的量，对于一个敏感的性能指标，我们取平均值到底意味着什么？是让50%的用户对响应时间happy，但是50%的用户感知到响应延迟？还是说50%的时间系统能保证稳定，而50%的时间系统则是一个不可控状态？

平均响应时间这种指标，只有在你每次请求的响应时间都是几乎一样的前提下才会有一样。再来个例子，人均财富这个概念有多沙雕相信大家也明白，19年有个很搞笑的新闻——腾讯员工平均月薪七万，明白平均值多不靠谱了吧😂。下图是现实世界中一个系统的响应时间柱状图，RT在前20%的请求数实际较少，而耗时特别短的请求拉低了均值（这些请求可能是命中缓存，也可能是快速失败），而大多数RT是在均值之下，那才是系统的实际性能情况。

所以说，我们不应看最好的结果，相反地，应该控制最坏的结果，用户用得爽他不保证会传播好口碑，但是用户用到生气他保证变为键盘侠肆意大骂，这也是为什么平均值无法带来足够的参考，因为happy的结果蒙蔽了我们的双眼，平均值在压测中丢失太多信息量。

总结一下，较为科学的评估方法应该将指标-成功率-流量三者挂钩在一起的：

xx%的响应在xx毫秒内返回，其中成功率为xx%。

根据这个方针，可以得到一些测试思路：

在响应时间的限制下，系统最高的吞吐量（这里不对吞吐量做严格定义，当成是QPS或TPS即可）
在成功率100%的前提下，不考虑响应时间长短，系统能承受的吞吐量
容忍一定的失败率和慢响应，系统最高能承受的吞吐量（95%成功率，前95%的请求响应时间为xx毫秒时的最大QPS）
在上面的场景下还要考虑时间和资源，比如最高吞吐量持续10分钟和持续1小时是不一样的，不同的时间持续长度下，机器资源（cpu、内存、负载、句柄、线程数、IO、带宽）的占用是否合理

目标预估

压测开展前是需要有目标的，也就是有期望的性能情况，希望接口或系统能达到的性能预期，没有目的的压测是浪费人力，下面给出几种目标预估的方法。

历史监控数据

已经上线并且有历史监控数据的接口，可以查看历史数据，找出峰值QPS和PCT99。🌰 若接口A已经上线并且做了监控，在经过某次大活动或者上线时间足够长后，存量监控数据就可以使用了。

类比

新接口或者线上未监控的接口，不存在历史数据，但存在类似功能接口的历史监控数据，可以通过类比得出压测的目标。🌰 假设上一年淘宝双十一下订单接口QPS=x，RT=y，这一年天猫平台整起来了，双十一活动与上年淘宝双十一活动场景类似，也沿用QPS=x，RT=y的目标（例子不严谨，理解即可）。

估算

新接口或者线上未监控的接口，不存在历史数据，且不存在类似功能接口的数据可供参数考，此时需要估算峰值，常用方法有8/2原则——一天内80%的请求会在20%的时间内到达。

top QPS = (总PV * 0.8) / (60 * 60 * 24 * 0.2)

RT如无特殊要求，一般采用默认值：

单服务单表类，RT<100ms
较复杂接口，RT<300ms
大数据量或调用链较长的接口，RT<1s

🌰-1 电商秒杀活动，预估同时有1000w人参与，简单起见假设总QPS是1000w。由于前端不同的秒杀倒计时形式使得请求有2s的打散，再加上nginx等webserver做了20%几率拒绝请求的策略，所以下单接口总QPS = 1000w / 2 * (1 - 0.2) = 400w/s，最终压测目标为400w/s的QPS。

🌰-2 电商全天低价抢购活动，屠龙宝刀，点击就送，一刀99级，emmmmm跑题了。根据8/2原则，预估在午休（12-1）和晚上下班后（7-10）共4h是流量高峰，估算接口峰值QPS = 活动全天接口PV / (4*3600s)。

其他

除了前面说到的情况，肯定还有一些我们无法下手的三无接口，无参考、无预估、无历史数据，这时候只能一点一点来，慢慢把压力提上去的同时收集数据，最终得出接口的最优处理能力。

压测准备

压测场景

压测是有目的的压测，也就是说不是随便找些接口发一通压力，而压测全部的接口也是做不到的或者说无意义的，得有压测的优先级，所以梳理压测场景是很重要的。高优场景主要有下面几个：

高频业务场景（今日头条首页下拉刷新）
关键业务场景，使用频率低，一旦出问题就很严重（微信账号登录）
性能高消耗场景（淘宝下单）
曾经出现过问题的场景

压测有分单接口压测和场景化压测，前者会简单一些，后者一般是多个接口混合操作以组成一个业务场景，两者在方法上是相通的。

梳理场景时QA需要与RD对齐，确认不同接口的RD负责人、需要压测的接口、系统性能现状以及压测目标；在确定每个接口的压测目标时，要考虑到压测对象是单实例单机房还是集群；在细节上也要确认是单接口压测还是场景化压测，每个接口的流量占比以及优先级，需不需要发足够的压力来触发系统的自动扩容或降级等更进一步的运维能力。

压测环境

在梳理完压测场景后，就要确认压测链路是否完整或符合预期。从一个服务到另一个服务，是不是链路上每一个服务都要压到？下游服务如审计安全等是不是已经考虑到？压测过程中产生的脏数据是否会影响线上数据？可能还要细化到具体下游某个服务不参与压测，如何处理呢？以上种种问题，可能需要推动整个链路相关的业务方进行对应业务改造来适配压测流量，改造完后还要自测验证才能正式开始压测，下面讲一些重点问题，部分内容引用自[文末的参考资料][全链路压测的大概思路]。

脏数据问题

如果是在独立的一套环境中操作，不存在该问题
影子表：线上压测一般将数据写入影子表（在schema上与原数据表一致的不同名表，如user表对应影子表user_stress）而非原数据表，实现压测数据与线上数据隔离
白名单：指定测试id或者测试账号，在入库后通过统一id区分压测数据，统一处理
各类存储层的压测改造，包括缓存层、消息队列、离线数据库等隔离问题。常规方法在压测链路中透传压测标记（也叫流量染色，挺形象的），比如json数据中加is_stress标记，存储层根据标记区分压测流量，对压测数据添加指定前后缀再入库等特殊处理

不参与压测的服务如何处理

mock server：mock服务返回响应的时长应该遵循线上时延分布，对业务的代码实现无侵入
服务stub：针对压测流量做处理，类似单测stub，代码stub模拟服务返回response，需要修改代码

可以独立部署一套线下环境进行压测。在不影响线上环境的前提下，确保机房，网络，存储，上下游服务与线上保持一致，部署一套独立的环境进行测试，机器与线上隔离，机器出问题不会影响线上。这种方式压测只是针对较少的几个系统进行，因为很难把整个链路所有系统都独立再部署一套，所以应用范围有限。

备注：上游、下游如何定义？ RFC 2616

Upstream and downstream describe the flow of a message: all messages flow from upstream to downstream.

下游的输入来自于上游的输出，假设有服务A、B，A调用了B（或者说A依赖B），那B就是A的上游，A就是B的下游，因为A的输入来自于B的输出（A调用了B，获取B的输出）。

更简单地理解，越接近用户的东西，越是下游。

更常见的方法是直接使用线上环境压测，在机器负载低的时间段（如深夜）人工发起或定时发起压测。

压测监控体系

确认好压测流程的技术支持和Mock数据的支持后，还要确认压测链路的监控体系是否完整，一来方便在压测过程中及时发现问题，二来是为了积攒历史压测数据，三来顺便确认监控系统本身是否可靠且全部到位。一般监控项包括（也就是压测指标）：

核心接口和核心依赖的流量、响应耗时、成功率
消息队列、缓存、数据库
机器物理资源

压测数据

压测数据其实没什么神秘的，网上说什么按照业务模型产出数据，表达上做了过度抽象反而不好理解，其实意思就是按照业务核心场景将所需要的数据构造出来。关键是要如何科学地模拟线上数据分布，引用文末参考资料，阿里双十一大促中有如下的业务流量漏斗模型，需要给不同场景科学地分配流量比例，这个比例是分析出来的而不是拍脑袋的。可以想象，阿里大促的流量不可能全部最后都走到付款流程，必然很多流量会在前面的流程就结束了，也就意味着，你把全部压测数据都构造成【走到付款场景】的话，你的压测结果是不准确的。