作者：赵佳佳

每年双十一、圣诞、春节大促的消费狂欢中，我们可以看到在高峰时段品牌直播间同时容纳着几百万人线上发弹幕、抢货、抢红包，在品牌店铺中又有着同样规模的咨询、加购、下单、支付等等。愈发庞大的用户体量、愈发高频的交互动作以及不规律的脉冲流量场景，对于应用服务而言有着不小的挑战。

在面对性能挑战前，我们先简单梳理零售电商的用户旅程与业务逻辑。以电商网站 & APP 为例，应用服务面对骤然涌入的用户，会遇到这样的场景：有的用户在不断查询商品信息，有的用户在注册账号，有的用户在修改购物车信息，有的用户在下单付款等等。而电商平台包括 Web 应用、中间件和数据库等组成部分。其中，前端 Web 应用负责接收并处理来自用户的 HTTP 请求，并生成 Web 页面反馈给用户，与用户产生交互；中间件应用负责执行其中的业务逻辑；后台数据库、存储负责读取、存储用户、产品信息及状态。为提升访问体验与服务性能，有的电商平台会在数据库前部署数据缓存设备。外围部署负载均衡，负责在海量用户访问与多台服务器间进行负载分担。正如前面所讲，高峰时段品牌直播间要同时容纳几百万人线上发弹幕、抢货、抢红包，如果服务宕机，会造成严重的后果，给用户带来巨大困扰。而且用户体量越大，影响的波及面就越广，不仅影响用户口碑，也直接影响业务收入。

压测筹备时，我们会遇到什么挑战？

（1）难以预估的流量规模

电商网站的应用服务通常包括两部分，一是推荐&搜索， 主要为用户推荐各种商品，为用户挑选商品带来便利 ；二是交易支付， 即加购、下单、支付等环节。两部分的流量模型截然不同，推荐&搜索部分流量呈现为慢慢上涨的曲线，对于服务而言，流量压力是逐步增加的；而交易部分流量却是陡然上升的，特别在双十一抢购活动中，压力会瞬间增长到顶点，产研、服务没有任何迟疑时间，这也是电商产品可用性能力要求比其他互联网产品高的重要原因。

但顶点会是多少，又会在什么时候到来，产研团队在事前难以通过业务团队的表述进行预测。如果想进行模拟真实用户进行测试，不同压力测试造成的成本又不一样，定高了成本高，定低了没效果。因此，活动筹备过程中对流量的预估非常重要。这也是历年双十一备战过程中最大的困难：如何评估从用户登录到完成购买的整个链条中，核心页面和交易支付的实际承载能力。 自 2009 年第一次双十一以来，每年双十一业务规模飞速增长，零点峰值流量带来的不确定性越来越大。

（2）多样化的场景压测

在预估流量规模之后，如何基于用户真实使用流程形成最接近真实业务场景是第二个挑战。电商应用服务通常有很多服务接口，用户在使用流程中会调用其中某几个接口。一种压测方式就是针对所有接口进行统一压测，增加相同压力测算出服务容量，再根据服务容量情况扩展到相关集群。另一种压测方式就是进行场景化压测，由于每个用户使用流程都不一样，不同服务接口承载的压力不尽相同，实现用最少服务资源支撑最大流量。

如何选择与业务特征最匹配的压测方案

压测方案设计与选择时，常遇到两个问题：压测会影响线上业务，对正常访问系统的用户造成影响。压测会污染线上数据，将压测数据写入线上数据库。为了解决这 2 个问题，一般业内采用如下几种方案，以以下方案各有优缺点，适用场景也不尽相同，可以根据业务所处阶段灵活选择。

构建压测脚本与压力模型

在选定压测方案之后，就可以开始配置压测脚本与压力模型。业内常用压测工具包括 JMeter、性能测试 PTS 等。 这些工具无一例外都需要将压测业务 API 编排为压测脚本。这一步工作的重点在确认压测的 API，不要有遗漏，且 API 编排顺序符合用户使用逻辑。对于电商业务压测而言，如果脚本中遗漏登录鉴权 API，那后续订单、物流、库存等 API 都会在权限校验这步报错，无法执行正常业务逻辑，也就无法模拟真实的业务场景。

同时，根据实际业务场景选择最恰的压力模型，比如脉冲模型会模拟流量在瞬间突然增大，常用于秒杀、抢购业务场景；递增模型可以模拟在一定时间段内，用户量不断增大，常用于模拟有预热的业务场景。确定了压力值和递增模型后，还需要确定施压流量的地域分布，应尽量拟合真实的用户分布，才能保证测试结果真实可信。对于区域性的在线业务，施压机分布在当地的同一机房，是可以理解的。如果是全国性的在线业务，施压机也应该按照用户分布，在全国各地域部署。

压测过程中的可观测性

在完成以上筹备之后，就可以开始正式压测了。在这一过程中，我们关注三个核心指标：请求成功率，请求响应时间（RT），系统吞吐量（QPS）。 请求成功率不止要看全局的请求成功率，还要关注一些核心 API 的成功率，避免整体成功率达标，核心 API 成功率不足的情况。请求响应时间，需要关注 99、95、90、80… 等一些关键分位的指标是否符合预期，而平均响应时间没有太大的参考意义，因为压测需要保证绝大部分用户的体验，在不清楚离散程度的情况下，平均值容易造成误判。系统吞吐量是衡量系统能承受多大访问量的指标，是压测不可缺少的标准。

当三个核心指标遇到拐点时就可认为服务已出现性能瓶颈，可以停止压测，开始准备定位/分析性能问题了。如果三个核心指标在整个压测过程中非常平稳，说明服务已达到可用性预期。但我们还可以按照 10-20% 的比例不断加大压力值，为服务进行一次峰值“摸高”压测，观察服务极限值是多少，真正做到心里有底。

关于性能测试 PTS

可以看到，在整个压测过程需要提前筹备的事项非常多，为了帮助企业、开发者更高效、便捷的进行性能压测，阿里云推出了性能测试 PTS。 性能测试 PTS 历经多年双十一活动的淬炼，通过伸缩弹性，可轻松发起百万并发流量，免去机器、人力成本；通过全球地域的流量发起，以及对流量模型的精准控制，可真实模拟用户的流量来源 。利用零编码场景编排、流量录制等功能，可轻松模拟复杂的用户互动。压测后通过丰富的监控及问题诊断功能，帮助业务快速发现瓶颈，提升系统性能和稳定性。

全网粉丝量超千万的某彩妆品牌，过去在面临大促时，系统稳定性保障压力很大，第三方接口和一些慢 SQL 就可能导致严重的线上故障；系统大促时资源与日常资源相差较大，需要频繁扩缩容；此外压测与系统容量评估的工作非常频繁，需要健常态化的机制来支撑；为了解决这些问题，也为了支撑业务快速发展，客户充分利用了 PTS 对系统的单机能力和整体容量进行评估，对单机能承载的业务量、整体能承载的业务量做到提前预判，未来对业务的大促需求可以做出合理的资源规划和成本预测。

某银行机构举办手机 APP 直播活动，需要支持百万用户同时在线，并有频繁的连麦、点赞、红包等互动，对系统的性能、稳定性、应急反应等有极高的需求。客户利用 PTS 的流量录制和多协议压测能力，将手机用户的在线操作精准地模拟出来。其强大的施压和调速能力，可模拟终端用户的流量来源和模型。从而帮助客户精准的规划系统容量，对可能出现的突发事件进行排练，确保整个系统的稳定性。同时，PTS 大大缩短了压测引擎的准备时间，拉起模拟百万用户在线的引擎时间缩短到 40 秒；在压测过程中，提供多种压测流量监控手段，帮助定位问题；压测结束后，马上停止压测流量，提供多维度多角度的压测报告和问题诊断工具，大大提高了压测效率。PTS 助力客户顺利完成了直播盛典，当晚观看量突破 200 万，点赞数超过 1700 万。