不管是大小公司多少都会有一些性能问题，因为性能这个事情本身就不是绝对的，伴随着性能事故，总有些性能测试岗位招聘的很急，至少我的职场经历经常就是刚入职时候压力特别大，现在的性能测试叫做全链路压测，那什么是全链路压测呢，跟传统压测区别是啥呢？全链路最早是阿里提出来的，在2012年的双11，零点的时候，系统交易成功率不足50%，下单报错，购物车报错，并伴随着大量超卖，后来提出了全链路压测，这篇文章就来聊聊全链路压测的关键点。
面试过很多公司，性能测试有很多形态，一般的公司还在工具使用阶段，做下简单的监控，然后出报告，结束，这样的做法基本就是走个形式，也有的开发团队相对负责，会在压测的过程中协助诊断，看看有没有优化点，一般来说多少会发现一些问题，会有些效果，但是往往大促，又会出现其他问题，leader问不是做过压测了吗？你觉得做过，但好像又做得不够.....
1.什么是线上全链路性能测试：
基于真实的用户场景，实际线上环境，按照既定流量，对各个业务链路进行压力测试的过程。
2.为什么要做全链路性能测试：
很多公司有线下性能测试，为啥还要做全链路呢，能解决一般性能测试的什么问题呢？我认为在每个环境做性能测试是相互补充的过程，在线下的性能测试，由于机器监控，部署迅速以及相应的权限充足，我们可以迅速定位到一些性能bug，如内存泄漏，死锁，超卖等问题，但是线下的机器达到的指标不能准确的反馈到线上的实际情况，我们并不能简单通过一些充满大量经验值的公式去推算，这样的结果和拍脑袋也没啥太大差异，再加上线下环境大多以分链路，模块压测为主，所以全链路压测在这样的背景下就诞生了，我们的前提是在线下已经模块压测完成，无明显瓶颈的情况下开展，在线上进行链路的充分模拟压测。
3.全链路压测的核心是什么？
无论何种测试，核心的东西一定是需求分析，那全链路性能需求分析的要点是啥呢，和传统线下性能测试有啥区别呢？
请求数据源：
在传统线下性能测试，一般我们拿到接口参数便开始调试，写脚本，按照场景进行测试，而线上我们需要根据实际数据源统计，包含web端，app端，小程序端等，这个是我们的客户端数据来源，还有我们的运营商带宽占用情况，cdn节点的分布，这样就涉及到外网的压测，外网的压测相对于内网来说，会增加更多的链路或者策略，如白名单机制，防火墙，f5等等，一旦QPS和内网差别较大，这些都需要重点分析。
架构拓扑分析：
线上的部署结构往往比我们测试环境要复杂很多，测试环境往往是线上很小的一个分支或者按照模块进行压测，但线上各种微服务的依赖集群，中间件，db需要调研的非常清楚，多少服务器，服务器上部署实例的情况，这也是做容量测试的基础之一，每个细节都会影响到压测的结果，以及分析的准确性，在做性能压测之前，建议按照模块做好线下链路的压测，不要把重大性能bug留在线上去暴露,举个例子，如nginx反响代理到gateway再到服务端和数据库，这是一个基本流程，那在这个基础上继续深入，比如你的gateway服务有几个节点，这么多节点部署在哪儿，是在一台服务器还是多台服务器上都是需要考虑的点，下面是我画的简图，略去了ip和节点数量，如果你在企业中实践，这些都是必备要素，如果你对这些一无所知，基本上还没有达到性能测试的门槛；
数据分析：
数据分析可以分很多层次，在一般的性能压测中，我们一般会关注参数化数据和db数据，全链路压测中，还需要关注，redis数据，mq堆积，以及key的大小对实际带宽的影响，这些都跟中间件相关，一旦出现问题，对网站的影响往往是毁灭性的，带宽这块往往也是线下局域网测试不能覆盖的，线上会跨机房调用，所以尤其需要关注这块，下面我在分层说数据分析这块
1)基础数据量分析
一般来说基础数据量我们指的的数据库预埋量，这个量级一般会参考线上的量级，数据库数据量10w量级和1000w量级会是一个截然不同的性能表现，很多公司也出现过性能测试环境指标很好，上线之后性能表现很差，就是因为索引缺失在性能环境因为基础数据太少没有发现，而上线后才发现的情况。
2)压测数据量分析
在写入操作中，数据库的数据量级会随着压测时间不断增加，我们需要预估好每次性能测试写入的量级，一般来说可以通过tps*场景执行时间，对数据库数据量的激增有相应的监控和兜底方案；
3)参数化的数据分析
参数化的数据首先需要参考的就是业务规则，需要什么样子的业务数据，从哪儿获取，取值范围是什么，能不能重复，这些点都是需要你一步步去确认的，举个例子，我们需要不一样的订单号，我们通过什么样的规则去造，有的同学会用时间戳去代替，那这个规则能不能完全保证不重复呢，这都是需要思考的问题。
性能测试场景分析:
我重点说下，如何将业务模型转化为性能测试模型；
解释一下我说的业务模型是啥，一般在性能测试中就是业务中各个接口的访问量，如下图a
图a
这是一个模块中各个接口的调用比例，刚开始我们一般只能拿到一个特定时间区域内的访问量，通过换算才能拿到比例，那拿到比例后，很显然我们不需要对所有业务都进行性能测试，有很多接口访问量非常低，但有一种情况，虽然接口访问量很低，但是很重要，要确定万无一失，我们也会把他纳入到性能的综合场景执行中，所以根据上面两个原则，我们去筛选接口组合成为性能综合场景，一般来说，我们会选取前80%的接口，如果剩余的20%有非常重要的接口也会纳入，组和成为性能测试模型，如下图b
注意点：
刚刚我说了，我说选取特定的时间点，那这个时间点如何选取呢，大家可能会不假思索的说选区业务访问高峰呗，在我们实际操作过程中，可能会存在多个业务高峰，按此时，我们就需要把这些业务高峰值都记录下来，因为他们的比例不可能全部一致，我们需要把每个业务高峰的比例都计算一遍，通过求同存异的原则去筛选，举个例子，双11零点的时候，前十分钟和后十分钟业务量都很大，而前十分钟可能添加购物车，浏览商品占绝大多数，零点一过，就是疯狂的下单操作，我们不太可能用同一套模型去做性能测试，上文中，我还提到选取前80%的接口，这个每家公司的情况不太一样，具体可以根据实际情况决定，说到这里，我提一点，很多同学会说你这个场景很复杂，某某公司流量复制，一键解决，很显然神化了，流量复制本身并不难，后面会有章节从测试的角度去做流量复制，难在我们的数据污染以及系统改造，涉及到技术和文化环境，这些并不只取决于测试团队。
监控分析：
大多是情况下，我们会做硬件层的监控包括cpu，带宽，内存，磁盘等，然后客户端进行数据采集，指标一般也通过压测数据采集，但这些在全链路压测中还是显得还有基础，我们需要去通过更多服务器维度监控，包含各服务集群的业务指标数据，db层的实时下单数据，容器级别资源监控数据等内容，以及结合健康度指标等，在线上压测需要设置阈值，尽可能规避线上风险，防止造成用户流失。
压测目标的设定：
提到性能测试的目标，很多人会直观想到不就是看最高处理能力吗？其实这只是一个方面，我先基于这个方面阐述，对于处理能力我们一般看最重要的三个指标，tps，响应时间，和报错率，经常会被问到这些指标应该怎么定，其实这没有统一的标准，指标是根据你所在公司的监控和实际活动摸索出来的，并不是直接拍脑袋就能决定，下面我说下行业的一些数据，大家对这些有个数据上的印象即可，并非作为标准；
Tps：我所经历过的一线互联网核心模块会在1w上下，绝大多数公司在100~1000不等；
响应时间:响应时间是伴随着tps而变化的，我们在基准测试底线是200ms；
报错率: 报错率一般的计算方式是场景中失败的事务数/事务总数
我们很多公司在线下压测的时候因无参考数据，可能压到拐点作为首选目标，而成熟的互联网公司一定会做线上的容量评估，一般会根据以往业绩以及流量相结合，会有一定比例增长的预估，还有通过推送转化率去评估，个人觉得可以长期做模型去进行数据积累，达到经验值的参考。
另外性能测试目的的需求也是多样性的，比如是否超卖，有没有并发死锁，72小时稳定性如何，tps是否平稳等，并不是只追求最高处理能力。
流量回放：
首先来说，能做到流量回放的公司很少，这个涉及到系统的改造，关键在于数据加工这块，能达到流量回放，测试的很多前期准备工作会少很多，但同时前期的开发改造任务也非常繁重，在阿里也一个开发团队封闭改造三个月才有一个雏形版本，任何一家公司都可以引用一种技术类型，但是做的深浅会很不一样。