本文始发自博客：[服务端压测怎么做](https://zingpho y.github.io/2020/04/26/%E6%9C%8D%E5%8A%A1%E7%AB%AF%E5%8E%8B%E6%B5%8B%E6%80%8E%E4%B9%88%E5%81%9A/)

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

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

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

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

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

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

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

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

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

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

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

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

在单核（或物理资源少）机器上部署单个服务，排除外部链路、网络等因素，得出自身服务的单核性能情况（单位QPS/core），后续根据此单核性能指标结合压测目标值进行扩容。另外由于是压的单接口单机，无其他接口请求影响，上下游在足够资源的情况下也不会造成瓶颈，所以能确保服务的性能真实值。

单接口单机可以在正式开始大规模压测前提前发现问题，方便RD做针对的性能优化并快速检验优化效果。一部分问题会先在单接口单机压测环节中发现，而一些隐藏得更深的问题，需要延后到全链路大流量压测才能暴露。

单接口单机压测环节，服务端已经完成了部分性能优化，接下来可以进入单接口1/4资源压测，这样是为了验证在单接口单机压测中得到的单核性能数据，在扩容1/4资源下性能是否会线性增长，是否存在性能损耗以及定位损耗源。

单接口压测局限很明显，场景化压测由于引入了上下游服务的其他接口的因素，可以发现单接口压测无法发现的问题，更接近线上用户场景。

全部资源到位后，预估的线上压力是否能承受，这一步也是内网压测过程的最后一步。

除了做内网压测，还要进行拨测验证用户从客户端到服务端的整个带宽资源是否满足预期，内网压测已经确认了业务性能是否达标，因此拨测可以只选择了一个场景进行验证即可。（简单来说拨测相当于压测cdn，检查各地cdn节点资源是否充足）

压测过程也要提前规划好，然后加入一定的人工策略调整。阿里大促还会有预热环节，预先跑一部分流量使得该缓存的数据提前缓存起来。正式压测时细分有几种压测策略，引用自文末参考资料：

除了关注前面讲到的指标外，还需要关注各机房流量是否均匀（若不均匀要确认负载均衡是否work）。

发压环节的结束并不代表压测就到此为止。

如果使用了影子表，可能收尾工作会简单一些，只需要下掉影子表即可。如果数据直接落到了线上数据库，可能一大堆压测数据要清理，压测时会对数据染色（比如指定测试账号或流量携带压测标记），逐层透传，最后根据标志识别删除。

举例一些可能会发现的典型问题：

……

给出一个完整的压测过程例子：

压测最终应该输出一份报告总结，其实也就是把整个压测方案、过程、结论记录下来，写明压测目标、压测接口、压测数据、压测结论，给出发现的问题并提供优化方案。往往在压测报告完成时，性能问题已经基本被解决了，报告的意义在于梳理前面的整个流程，给后续的压测提供经验指导。

Why Averages Suck and Percentiles are Great

CoolShell-性能测试怎么做

全链路压测的大概思路

独家揭秘 | 阿里怎么做双11全链路压测？

亲历流量尖峰时刻：一名阿里技术员工的双11十年

What is Upstream and Downstream in Software Development?

一个阿里技术男经历的六年“双11”：技术改变阿里

本文由博客群发一文多发等运营工具平台 OpenWrite 发布

https://www.guru99.com/performance-vs-load-vs-stress-testing.html ↩︎