全链路压测分析（纯干货）

最近网传，微信支付崩了，哈罗出了问题，部分公司性能测试架构师招聘又开始火热起来，现在都叫做全链路压测，那什么是全链路压测呢，跟传统压测区别是啥呢？全链路最早是阿里提出来的，在2012年的双11，零点的时候，系统交易成功率不足50%，下单报错，购物车报错，并伴随着大量超卖，后来提出了全链路压测，这篇文章就来聊聊全链路压测的关键点。

面试过很多公司，性能测试有很多形态，一般的公司还在工具使用阶段，做下简单的监控，然后出报告，结束，这样的做法基本就是走个形式，也有的开发团队相对负责，会在压测的过程中协助诊断，看看有没有优化点，一般来说多少会发现一些问题，会有些效果，但是往往大促，又会出现其他问题，leader问不是做过压测了吗？你觉得做过，但好像又做得不够.....

1.什么是线上全链路性能测试：

基于真实的用户场景，实际线上环境，按照既定流量，对各个业务链路进行压力测试的过程。

2.为什么要做全链路性能测试：

很多公司有线下性能测试，为啥还要做全链路呢，能解决一般性能测试的什么问题呢？我认为在每个环境做性能测试是相互补充的过程，在线下的性能测试，由于机器监控，部署迅速以及相应的权限充足，我们可以迅速定位到一些性能bug，如内存泄漏，死锁，超卖等问题，但是线下的机器达到的指标不能准确的反馈到线上的实际情况，我们并不能简单通过一些充满大量经验值的公式去推算，这样的结果和拍脑袋也没啥太大差异，再加上线下环境大多以分链路，模块压测为主，所以全链路压测在这样的背景下就诞生了，我们的前提是在线下已经模块压测完成，无明显瓶颈的情况下开展，在线上进行链路的充分模拟压测。

3.全链路压测的核心是什么？

无论何种测试，核心的东西一定是需求分析，那全链路性能需求分析的要点是啥呢，和传统线下性能测试有啥区别呢？

请求数据源：

在传统线下性能测试，一般我们拿到接口参数便开始调试，写脚本，按照场景进行测试，而线上我们需要根据实际数据源统计，包含web端，app端，小程序端等，这个是我们的客户端数据来源，还有我们的运营商带宽占用情况，cdn节点的分布，这样就涉及到外网的压测，外网的压测策略和内网细节上的差别还是比较大的，本文不作具体讨论。

架构拓扑分析：

线上的部署结构往往比我们测试环境要复杂很多，测试环境往往是线上很小的一个分支，线上各种微服务的依赖集群，中间件，db需要调研的非常清楚，多少服务器，服务器上部署实例的情况，每个细节都会影响到压测的结果，以及分析的准确性。

数据分析：

数据分析可以分很多层次，在一般的性能压测中，我们一般会关注参数化数据和db数据，全链路压测中，还需要关注，redis数据，mq堆积，以及key的大小对实际带宽的影响，这些都跟中间件相关，一旦出现问题，对网站的影响往往是毁灭性的，带宽这块往往也是线下局域网测试不能覆盖的，线上会跨机房调用，所以尤其需要关注这块。

监控分析：

大多是情况下，我们会做硬件层的监控包括cpu，带宽，内存，磁盘等，然后客户端进行数据采集，指标一般也通过压测数据采集，但这些在全链路压测中还是显得还有基础，我们需要去通过更多服务器维度监控，包含各服务集群的业务指标数据，db层的实时下单数据，容器级别资源监控数据等内容，以及结合健康度指标等，在线上压测需要设置阈值，尽可能规避线上风险，防止造成用户流失。

压测目标的设定：

我们很多公司在线下压测的时候因无参考数据，可能压到拐点作为首选目标，而成熟的互联网公司一定会做线上的容量评估，一般会根据以往业绩以及流量相结合，会有一定比例增长的预估，还有通过推送转化率去评估，个人觉得可以长期做模型去进行数据积累，达到经验值的参考。

流量回放：

首先来说，能做到流量回放的公司很少，这个涉及到系统的改造，关键在于数据加工这块，能达到流量回放，测试的很多前期准备工作会少很多，但同时前期的开发改造任务也非常繁重，在阿里也一个开发团队封闭改造三个月才有一个雏形版本，任何一家公司都可以引用一种技术类型，但是做的深浅会很不一样。

这篇就聊到这里，你有新的观点可以留言，感谢关注。