压力测试的六大核心要点：明确压测目标、梳理压测链路、设计压测方案、配置 压测环境、实施压测计划、解决压测问题。
明确压力测试最终需要达到的目标，是设计与实施整个压测方案的先决条件。目 前常见的压测目标可分为两类：一类是基于系统监控找水位，即在系统资源濒临阈值 时检查QPS以及对应RT，即为该系统的水位。一般用于评估业务系统可承受的 QPS，从而判断当前系统架构是否可满足业务需求。一类是基于预估压力判断业务是 否可正常运行，即在稳定的QPS下判断系统是否存在性能瓶颈，业务链路是否可正常 运行。一般是用于在大型运营活动前，基于预估QPS对系统进行压测，提前找出性能 瓶颈，保证运营活动正常运行。
对于大型赛事活动的压测一般是第二类，即首先由业务方预估赛时的压力情况， 再通过压测系统模拟该压力找到系统瓶颈。这里需要注意的是，业务方需要给定一个 明确的预估压力值，例如1000并发用户数、8万QPS等，如果没有最终目标，压测就 会进入不知道压到什么程度才算完成的尴尬局面。并且，这个压力值是基于业务层模 拟推导计算出来的，例如，冬奥通APP业务峰值是x万日活用户，对某个页面，根据 业务观察，每个用户平均每天会打开10次，打开一次该页面的请求数为5个，那么我 们考虑比较极端情况，假设所有用户的这10次请求都集中在某1个小时内，那么该页 面的QPS要求即为：xk * 10 * 5 / 3600 = x QPS。再例如，云展厅项目有一个高并 发的秒杀业务，预估用户数为8k，假设用户的一次点击产生一次请求，那么这个业 务的QPS要求即为8k QPS。
梳理目标系统整体的架构及业务链路，可以体系化的帮助理解当前系统的 业务链、业务链之间的依赖关系、功能点所在的业务位置等等，是后续抽象压 测模型、划分压测场景、设计压测方案、解决压测问题的关键依据。通常来 讲，链路梳理的越细致，后续的工作就会越流畅。
对于大型赛事而言，子系统繁多，链路间调用关系复杂，梳理起来对应的 工作内容会比较多。一个比较好的最佳实践是根据系统架构图来理解每条接口 链路情况，在下文冬奥通APP压测总结中我们将会看到，一个完整详细的系统 架构图对链路梳理起了非常大的帮助。
在梳理过程中也可以同时分析潜在的瓶颈点，并针对性的增加监控指标、 制定应急预案等。例如，负载均衡产品潜在高频问题为容量不足、建连失败 等，针对容量不足风险，可通过观察超限丢包指标来进行判断。数据库产品常 见问题为连接池耗尽、慢查询等，可通过连接池监控、SQL语句执行时间监控 等来进行判断。不同风险的判断指标需要落在压测方案中。
阿里云PTS产品团队总结的压测方案设计原则，要做到五个一样：一样的 线上环境，一样的用户规模，一样的业务场景，一样的业务量级，一样的流量 来源。
对于大型赛事而言，由于赛程是固定的，所以环境准备这部分其实比较容 易解决，因为一定是要在生产环境上线之前进行压测，这时还没有真实用户， 但环境已经搭建完毕，此时即为压测的最佳时段。但如果是已经线上运转的生 产环境，那么设计压测方案时要做一个取舍，生产环境和测试环境的压测方案 各有其优缺点：针对生产环境压测，其衡量的精准度较高，参考效果更好，但 是会有一些额外的成本，首先需要对相关的测试数据进行处理，包括压测时如何插入测试数据不会影响生产，以及压测结束后脏数据的清理，同时，也要谨慎考虑 压测流量对生产环境造成的影响，要尽量挑选在低峰期进行。针对单独的测试环境压 测，其难点在环境的构建上，规模和生产一致的成本也是最高的，所以一般而言为等 比构建(生产环境的1/2，1/4，1/8等)，甚至是生产环境中部分应用独立部署测试集 群，数据库共用的方式，此外测试环境需要从生产环境中导入脱敏的基础数据，例如 至少是最近半年或者1年的，保持其整体的数据关联性，这个对于压测的准确度和参 考性也很重要。
如何准确模拟用户规模、业务场景、业务量级、流量来源是一个比较大的课题。 从工具层面来讲，一般是通过专用压测工具如jmeter或直接购买压测服务来进行模 拟。使用jmeter等压测工具，需要针对业务场景有针对性的进行分布式部署，可部署 在三方的专用压测机云环境，但需要自行编写压测机压测脚本，对技术水平的要求比 较高，因为压测准确性很大程度上取决于脚本是否能完美模拟用户请求场景。当然也 可以使用专有的云上压测服务，阿里云有一个SaaS化的性能测试分布式云化压测服 务PTS(Performance Test Service)，其压力发起来源是遍布全国上百个城市和各运 营商的CDN节点，可分布式的模拟海量用户的真实业务场景，可以作为压测方案一 个轻量快速的选项。
要写出能准确模拟真实场景的压测脚本，需要深刻的了解系统的业务模型，系统 有很多业务，每种业务逻辑和业务量是不一样的，系统的基础数据、系统预热情况等 代表系统的状态。链路范围、链路的访问量级、链路的参数集合、基础数据、预热情 况一起构成了压测的业务模型。需要编写者非常了解在真实场景下，各个业务种类的 请求模型，及对应的业务占比，以进行不同的容量整体配比，精准地将流量落地。保 证压测结果可靠性的几个关键点在：业务逻辑改动要仿真业务场景，QPS配比要仿真 业务场景，入参满足业务仿真的需求，影子数据满足业务仿真的需求。
同时，压测方案中要包括需要监控的指标，包括压测机资源指标、业务指标、服 务端资源指标等。如果是对生产环境压测，也要设计对应的紧急问题的应急预案，如 数据回滚、数据清理等。
在预上线环境进行压测，需要注意的是测试数据的准备要和真实用户场景数据一 致，可使用生产数据例如人员ID、生产账号账密、生产日期、生产位置等真实数据进 行压测，但要注意数据清理和功能回归。
在生产环境进行压测，最核心的是线上写操作不能污染正常的业务数据。因此， 需要针对存储做影子库表，即正常业务库表的镜像，让压测流量的数据流转到影子库 表，正常业务流量流转到正常业务库表，在逻辑上隔离两种流量，使之互不影响。
另外一个关键点是配置完善的监控，没有完善的系统监控，将会导致性能分析无 从下手。
在真正实施压测时，要按照阶梯加压的原则进行，首先从小流量压力开始，按照 合理阈值逐段增压，同时关注各监控指标数据，在开始性能恶化时即为系统原始性能 基线数据与容量，以此为优化初值。
压测时一定会遇到具体的问题，这部分属于如何进行系统调优，将在下一小节讨 论。 以上即为压测通用方法论，无论压测的形式如何更改，其本质皆为这六大核心要 点，流程。
