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

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

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

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

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

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

 

1、核心业务梳理

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

 固然，这里须要注意的的有两个方面：

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

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

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

 

2、线上流量评估

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

一、听云监控

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

二、BI埋点监控

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

三、往期活动峰值流量

像淘宝天猫，由于已经举办过屡次的相似活动，所以有较为丰富的往期数据作参考。对于我司来讲，第一次大力度的大促，只能经过高峰流量来进行倍增预估，而后作好随时扩容的准备。

四、渠道引流转化量

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

 

3、场景建模

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

一、业务场景建模

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

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

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

模型事项	说明
交易占比	测试交易笔数占总业务量的比例（可忽略占比不多的交易数据）
选取思路	1.1选取交易量最高时间段；1.2每种交易进行单独的数据统计
异常选择	1.1若是交易比例相似，则按生产配比进行转化； 1.2如比例差距大，则独立统计
交易配比	单交易统计后，基于各交易的RT，结合并发用户数，使总交易数达到交易占比数

二、压测场景建模

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

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

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

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

三、数据场景建模

数据场景建模，不少时候每每被忽视，但实际上数据场景建模更加剧要。若是测试过程当中所采用的数据不完整不许确，那么测试结果每每出现较大的误差。关于测试所需数据，可参考以下几点：

数据信息	说明
限制条件	用户操做权限、数据引用次数、数据过时设定（次数、绝对时间）
数据量	实际生产环境的数据量为多少，在性能测试环境如何等量代换
数据类型	基础数据、热点数据、缓存数据、特殊数据
数据特色	是否能够复用、是否具备惟一性、自增、加密、拼接、转义等
准备方式	copy真实环境数据、预埋铺底数据、脱敏生成数据
隔离方案	如何避免测试数据的污染？影子库？环境隔离？标记区分？

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

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

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

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

　　　　 是否有热点数据相关的操做：好比说全部用户秒杀同一件商品；

　　　　 不一样类型数据处理逻辑有差别时，需经过测试数据多样化提升性能测试代码覆盖率；

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

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

 

4、准备工做

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

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

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

 

5、压测监控

完成了前面的几项工做，就能够进入压测阶段了，这一阶段，能够分为两部分，压测+监控。

一、压测

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

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

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

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

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

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

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

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

　　通常来讲，稳定性测试的执行时间，12h便可（固然，24h或者更长也能够，根据具体状况灵活调整）。

二、监控

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

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

若是采用的云服务器（好比阿里云），如今国内的云厂商都提供了监控大盘以及各类监控服务（好比阿里云的APM、ARMS、AHAS）。

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

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

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

 

6、分析调优

一、性能分析

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

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

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

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

二、性能调优

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

性能优化的目的是：在保持和下降系统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的几率也越大，系统也就越不健壮。从另外一个方面来讲，异常流程处理代码也要考虑健壮性的问题，这就造成了无限循环。

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

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

 

7、容量规划

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

一、单机混合容量

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

获得单机最优容量数值，而后能够经过增长被测系统的服务节点，来验证容量是否随着服务节点的增长而线性增加。

二、多节点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：服务节点数量越多，那么递减效应越明显，建议经过测试多个服务节点的递减比率，来获得一个区间数。

三、告警阈值

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

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

四、Buffer机

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

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

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

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

 

以上内容，即为我本人在本次618大促期间，所作的一些工做，限于篇幅，有些内容没法详细描述，感兴趣的童鞋，可关注我博客或者公众号，有更多相关资料。。。