电商大促，性能测试都在做什么？

自从09年阿里开启了双十一活动，近几年各大电商平台的促销活动如火如荼。电商大促期间剧增的流量，对电商平台相关的软件系统也带来了更严峻的挑战。

比如秒杀抢购活动要求高并发处理能力，核心业务流程要求更好的可用性以及稳定性，为了大促需要精确的对线上服务扩容做容量规划等等。

对于性能测试工程师来说，无论是前期的核心业务梳理、线上流量评估、场景建模，还是测试实施阶段的监控分析、调优验证，乃至线上的容量规划，每个环节都需要做很多工作。

且这些工作都需要运维、开发、产品甚至BI团队的协同配合，才能保质高效的完成。这篇博客，来聊聊电商大促期间，性能测试工程师都在做哪些事情。。。

PS：由于某些原因，这篇博客延期了将近一个月才发布，不过即将为双十一做准备，到时候会更一篇更详细的博客来说明具体的细节。。。

一、核心业务梳理

电商业务相对来说比较复杂，以我司来说，今年618是第一次大规模的进行促销活动。由于时间紧任务重，为了保证在大促期间系统能稳定运行，需要梳理出核心的业务。如下图：

当然，这里需要注意的的有两个方面：

①、电商业务核心业务流程，在大促期间的流量相较于日常时间段，是相对较高的，且持续时间在一周到半个月不等。因此在业务梳理时，就该考虑到这部分的高可用和稳定性。

②、除了核心业务流程，还有大促时会有一些抢购秒杀抽奖等活动，这类型的业务一般具有短时间内流量剧增，商品优惠券数量有限下的超卖现象，因此需要考虑高并发和超卖问题。

PS：在梳理核心业务流程时可以遵循这三点来梳理：核心业务、高频业务、基础业务。

二、线上流量评估

只有精确合理的对线上的访问流量进行监控评估，才能计算出较有参考意义的预期性能指标。以我司来说，所有的流量都来自于移动端APP，因此流量评估方式采用了如下方式：

1、听云监控

根据听云监控获取各核心业务功能对应服务/接口的调用次数（rpm），获取维度为近一周平均rpm以及峰值rmp，然后以计算出的数据扩容3-10倍；

2、BI埋点监控

通过BI部门同事提供的埋点监控数据，得到DAU、高峰时间段内的流量占比，同样，根据本次大促的力度，进行流量倍增；

3、往期活动峰值流量

像淘宝天猫，因为已经举办过多次的类似活动，因此有较为丰富的往期数据做参考。对于我司来说，第一次大力度的大促，只能通过高峰流量来进行倍增预估，然后做好随时扩容的准备。

4、渠道引流转化量

鉴于业务特性以及商务合作方面，有时候会有其他合作渠道的引流。关于这点，基于个人认知以及和业务运营同事讨论后，根据合作方提供的引流量及转化率，可以计算得出新增流量。

三、场景建模

通过上面的核心业务梳理结合流量评估，进行场景建模，这样可以在压测前明确要做哪些准备工作。场景建模思路如下：

1、业务场景建模

什么是业务场景？简单来说就是什么人（用户）在什么时候（活动期间）做什么事情（商品搜索、添加购物车、下单支付、抢券抽奖）。

业务场景建模的目的是尽可能将不同的业务做拆分解耦，这样能方便压测的实施以及性能瓶颈的分析监控。

关于业务配比，首先要尽可能排除非核心低频业务，交易配比模型的建立，可以参考如下几点：

2、压测场景建模

完成业务场景建模后，基于其进行压测场景建模，这里要考虑到采用的测试策略，当然，测试策略的制定需要结合系统架构（需要梳理清各服务间的依赖和调用关系）和业务特点来说。

比如抽奖抢券秒杀场景，就需要采用并发测试以及超卖验证等测试策略。

考虑到业务配比的情况，我们还需要进行单接口的基准测试以及单机混合场景容量测试。

核心业务流程，其特性要求系统具备高可用和稳定性，那么测试策略就需要采用高可用测试和稳定性测试。

3、数据场景建模

数据场景建模，很多时候往往被忽视，但实际上数据场景建模更加重要。如果测试过程中所采用的数据不完整不准确，那么测试结果往往出现较大的偏差。关于测试所需数据，可参考如下几点：

关于几种数据类型的说明：

基础数据：也可以称之为铺底数据，铺底数据目的是让性能测试环境与线上保持一致（至少数量级一致），再结合线上数据增长率（半年&一年的数据量级），确认预埋数据量级及预埋方式；

涉及到压测时需要校验的数据，需要在铺底的时候就要精细化的设计，包括数据大小，数量，分布等。

热点数据：需要了解被测接口的实现逻辑，确认以下信息：

　　　　 是否有热点数据相关的操作：比如说所有用户秒杀同一件商品；

　　　　 不同类型数据处理逻辑有差异时，需通过测试数据多样化提高性能测试代码覆盖率；

缓存数据：要确认是否有缓存，缓存大小为多少（排除大key，一般来说142W的key占Redis一个G的内存）；

　秒杀抢购相关数据，一般来说都是进行队列处理，将该类型数据放入缓存中进行处理来应对高并发。

四、准备工作

准备工作在性能测试中，是最为耗时以及麻烦的，不仅需要各个团队协同配合，还需要不断验证，以确保相关的准备事项不会对性能测试结果造成较大影响。

以我司的性能测试流程来说，准备阶段的各事项以及对应责任人，如下图：

在准备阶段，性能测试童鞋（比如我），要尽可能承担起PM这一角色的职责，跨部门沟通，协调资源以及推动准备工作的快速落地，这样才能在有限时间内完成准备事项，为压测预留足够的时间。

五、压测监控

完成了前面的几项工作，就可以进入压测阶段了，这一阶段，可以分为两部分，压测 监控。

1、压测

压测工作主要有如下几种情景，按照预先制定的测试策略执行即可（不排除临时特殊情况，这里需灵活调整）。

①、单机单接口测试：该策略主要是为了验证单接口的性能基准，避免整个调用链路过程中某个服务/接口成为瓶颈；

②、单机多接口测试：相较于微服务架构的服务解耦，有时候某些服务间互相调用依赖的强关系可能会造成资源竞争等情况，需要通过这种方式来排查验证；

③、单机混合场景测试：这种测试方式的主要作用是得到一个单机混合场景下的最优性能表现，为服务扩容和线上容量规划提供参考数据；

④、多节点测试：现在大多数的互联网企业都采用的集群/分布式/微服务架构，在多节点部署时候，考虑到SLB的边际递减效应，需要进行多节点测试；

　　通过该种方式，来验证负载均衡递减比率，为生产扩容提供精确的参考依据；

⑤、高可用测试：高可用主要验证2点：服务异常/宕机是否可以恢复以及恢复到正常水平所耗费的时间（越短越好）。

⑥、稳定性测试：前面提到了核心业务流程必须保证稳定性，稳定性测试一般根据系统特点和业务类型，分为两类：5d*12h、7d*24h。

　　一般来说，稳定性测试的执行时间，12h即可（当然，24h或者更长也可以，根据具体情况灵活调整）。

2、监控

性能测试过程中，监控是很重要的一环，它可以帮助我们验证测试的结果是否满足预期指标，以及协助我们发现系统存在的问题。常见的监控指标如下：

那么如何监控这些指标呢？

如果采用的云服务器（比如阿里云），现在国内的云厂商都提供了监控大盘以及各种监控服务（比如阿里云的APM、ARMS、AHAS）。

如果是自建服务机房，可以借助运维搭建的监控体系，比如全链路追踪（pinpoint、cat、zipkin、skywalking），专业的监控工具比如Nmon、Zabbix等。

测试指标的监控，可以搭建基于开源组件的Grafana InfluxDB Jmeter Nmon2influxdb，或者ELK等监控体系。

限于篇幅，这里就不一一赘述，感兴趣的童鞋可以自行搜索相关资料或参考我之前写的关于监控部分的文章。

六、分析调优

1、性能分析

性能分析是一个复杂的话题，不同的系统架构设计、应用场景、业务逻辑、编程语言及采用的框架，都有一定的差异。抽象来说，有如下三种分析思路：

①、自上而下：即通过生成负载来观察被测系统的性能表现，比如通过对TPS、RT等指标的监控，从请求发起端到OS端层层剖析，从而找到系统性能瓶颈。

②、自下而上：通过监控各硬件及操作系统相关指标（CPU、Memory、磁盘I/O、网络）来分析性能瓶颈。

③、从局部到整体：即通过性能表象结合工作经验做快速排除，确定可能存在瓶颈的局部所在，快速修改验证，避免大而全的全面分析带来的耗时，提高效率。

2、性能调优

性能调优主要关注三个方面：降低响应时间、提高系统吞吐量、提高服务的可用性。

性能优化的目的是：在保持和降低系统99%RT的前提下，不断提高系统吞吐量以及流量高峰时期的服务可用性。

性能调优建议遵循如下几点原则：

①、Gustafson定律：系统优化某组件所获得的系统性能的改善程度，取决于该部件被使用的频率，或所占总执行时间的比例。

②、Amdahl定律：S=1/(1-a a/n)

　　其中，a为并行计算部分所占比例，n为并行处理结点个数。这样，当1-a=0时，(没有串行，只有并行)最大加速比s=n；

　　当a=0时（只有串行，没有并行），最小加速比s=1；当n→∞时，极限加速比s→ 1/（1-a），这也就是加速比的上限。

③、最小可用原则：一般情况下，系统的代码量会随着功能的增加而变多，健壮性有时候也需要通过编写异常处理代码来实现，异常考虑越全面，异常处理的代码量就越大。

　　随着代码量的增大，引入BUG的概率也越大，系统也就越不健壮。从另一个方面来说，异常流程处理代码也要考虑健壮性的问题，这就形成了无限循环。

　　因此在系统设计和代码编写过程中，要求：一个功能模块如非必要，就不要；一段代码如非必写，则不写。

当然，具体的调优要根据性能瓶颈的具体表现来分析调优，更多调优方法，可参考我的另一篇文章：性能测试常见瓶颈分析及调优方法

七、容量规划

性能测试的最终目的是保证线上服务的可用性，及时响应并满足业务需求。而容量规划，是对线上服务在峰值流量冲击下稳定运行的最佳保障。这里提供如下几种容量规划时的思路：

1、单机混合容量

这里的容量指的是在单台服务器下，混合场景压测的最优性能表现（而不是最高）。比如一台4C8G的服务器，对核心业务场景进行按业务配比混合压测，示例如下图：

得到单机最优容量数值，然后可以通过增加被测系统的服务节点，来验证容量是否随着服务节点的增加而线性增长。

2、多节点SLB容量

以上面的示例图来说，单机最优TPS≈450，然后通过增加服务节点数量，再次压测，通过扩容后的压测数值除以服务节点数量，然后和单机混合容量对比，就可以得到多节点SLB的递减比率。

举例：扩容后的压测数值为R，服务节点数量为N，单机混合容量为D，那么多节点SLB的递减比率计算公式为：SLB%=(R/N)/D。

以前面的例子来说，单机混合容量为450，服务节点扩展到2台，得到测试结果为750，那么SLB%=(750/2)/450≈83.33%。

以此类推，如果预期线上性能指标要求TPS≥5000，那么通过计算，我们可以得到线上服务节点最少需要扩容到14台，才能满足需要。

PS：服务节点数量越多，那么递减效应越明显，建议通过测试多个服务节点的递减比率，来得到一个区间数。

3、告警阈值

这里的告警阈值，指的是运维同事对各个服务状态及相关资源指标进行监控时，设定的提醒和告警阈值。

前面所说的单机混合容量的最优值，建议结合运维设定的阈值来综合评估（比如运维告警设定的阈值是CPU使用率达到80%，那么就以单机CPU80%耗用下的容量数值作为计算基准）。

4、Buffer机

文章的开头已经说过，系统不仅要具有高可用和稳定性，还要具有容灾机制。比如某个或某部分服务不可用，服务器宕机，需要预留的机器来随时补上来。

本文所说的Buffer机，即作为预留容灾的机器。按照我个人的实践经验来说，以线上扩容机器数量的30%来作为预留Buffer机，已经能满足绝大部分情况（适合中小型团队）。

当然，有些特殊场景（比如2019年春节联欢晚会，百度承包的口令红包场景），就需要综合考虑更多的影响因素。

除了容量规划，我们还可以通过服务降级、网关限流甚至熔断等机制，来保证系统在峰值流量的冲击下保持服务可用。