独家揭秘 | 阿里怎么作双11全链路压测？

阿里妹导读：#技术双11系列#全链路压测是阿里的独创，咱们将从工做内容、操做过程、运行总结等多个方向来介绍下阿里内部典型电商活动（如双11准备），以给你们展现一个完整的压测流程，帮助更多的企业和用户更好的完成性能测试。

前言

关于性能测试的重要性及必要性已是个老生常谈的问题了，现分别从技术角度和业务战略角度总结以下：

而性能测试的目的也就是为了解决大型营销活动中洪峰流量引发的系统表现不肯定性，一个理想的营销活动周期应该是有以下闭环流程：

• PS：1和2之间再加一个步骤。环境改造和基础数据准备。强调必须在生产环境。
• 压测环境准备：须要复用真实的线上环境，压测结果和问题暴露才都是最真实状况。可经过压测流量全局识别、透传（数据进影子区域）。
• 基础数据准备：以电商场景为例，构造知足大促场景的核心基础相关数据（如买家、卖家、商品信息），以线上数据为数据源，进行采样、过滤和脱敏，并保持同等量级。

能够看出，性能测试经过真实、高效的压测方式进行容量评估/瓶颈定位&解决，最终来保障活动稳定进行；每个环节的内容都很是重要，以阿里双11活动为例，咱们除了技术上的准备、执行、保障以外，还会有一些流程及分工细节。如下将逐一介绍。

关于流程及管理

阿里巴巴全链路压测从2013年到如今也已是第7个年头了，在这7年中间咱们不断的积累、总结、优化进步，从开始的200多人参与、通宵压测的大规模全员项目活动到后来仅仅几我的白天压测、更智能化的压测方式，这样一种大规模的项目活动，离不开有效的流程把控及分工管理。

阿里巴巴在多年双十一大促保障——全链路压测项目中，有着严格的流程把控及分工管理模式与经验，总结以下：

说明：该图中时间点为模拟时间点，仅作前后顺序的参考。

好的流程规划与管理，能够大大提高团队协做效率。叠加上工具平台的智能化功能，能够将参与的200人力通宵压测缩减至10人之内白天压测，有效的方案 + 充足的准备 + 靠谱的平台技术产品 = 成功的压测。

下面将结合主题系列前几回的文章，介绍下在数据准备、架构改造、流量安全策略（环境及流量隔离）、压测实施、问题定位分析这几方面，阿里巴巴在双十一压测这个项目上具体是怎么作的。

压测环境改造

数据准备的同时，须要考虑压测环境（即压测对象的部署环境）是哪里，不一样环境就须要作不一样的准备。

整个阿里经济体的压测环境，包括双十一压测，所有选择的是线上环境，此时须要评估若是要进行全链路压测，是否直接可使用现有环境、同一个API屡次压测是否会被拦截、是否会有脏数据影响、若是有影响应该如何改造避免等。以上这些问题总结下来即为两类问题：业务问题和数据传递问题。问题比较明确，咱们就根据这两类问题来作逐一的改造。

改造分为2方面：业务改造和中间件改造，这些在内部全链路压测1.0 时代就已经完成了，对于外部客户来讲，能够做为一个技术改造上的参考点。同时咱们已经有成熟的产品化方案提供一站式的能力，免去复杂的改造和维护成本。

业务改造

业务改造即为了解决压测过程当中的业务异常问题，或者压测请求没法正常被执行的问题。举例以下：

• 流量区分与识别：压测流量和业务流量的区分，并可在全链路系统中识别出来；
• 流量单一性问题：好比下单，同一我的执行一次下单后再重复执行就会失败；
• 流量的限流拦截：若是平常有限制，须要改造为接入流量降级能实时生效调整配置；
• 剔除压测数据对报表的影响
• 动态校验
• ......

业务改造涉及的内容没法一一穷举，须要根据不一样的业务模型、业务架构及配置，一一梳理。通常梳理改造以后，后续全部新应用都按照规范去开发，每一年的压测前进行基础的查漏补缺便可。

中间件改造

中间件做为衔接业务应用之间的组件，在压测中有个相当重要的功能就是将流量标识传递下去，一直到最终的数据库层面。虽然咱们在13年开始，从核心应用使用到的中间件已经升级改造完成，中间咱们踩过很多坑，诸如改造全面性、改造带来的业务代码修改为本、版本兼容问题等。

改造完成以后，压测流量的模型图能够参考以下：

环境的改造，须要结合业务场景具体分析、设计。云上高可用解决方案，提供了全链路压测解决方案的服务。

数据准备

大促活动肯定以后，会对业务模型进行一次评审，即肯定该业务模式对应的技术架构应用有哪些，须要作压测的业务范围有哪些、以及数据量级、数据形式是什么样的。因此数据准备包括准备业务模型数据和压测流量数据两部分。
数据的准备，主要分为两部分：业务模型的创建和基础数据的构造。

业务模型数据

业务模型数据，即压测的业务模型相关的数据，包括涉及到哪些API，这些API之间的压测量级是什么样的或者有什么样的比例关系等。业务模型的构造准确度，直接影响了压测结果的可参考性。

模型设计的目的主要是将业务进行采集并抽象成可执行的压测模型，并对各个子模型中的元素进行预测和设计，最终产生能够执行的压测模型。在双十一大促前，咱们会肯定好相关的业务，进行场景分类。

• 已有业务场景：采集以往数据并作处理，做为预测数据，造成一个模型雏形，结合新的业务玩法，造成已有业务的模型；
• 新业务场景：直接按照新的业务，模型配比，造成一个新业务模型。

最终会将两种业务场景类型进行组合，造成最终的终态业务模型。如下图做为示例：

在组装业务模型数据的时候，须要注意一些关键因素，好比修改具体的电商业务模型关键因素：

• 1对N ：上游业务一个请求对应下游业务接口是否会存在调用屡次的状况；
• 业务属性的比例：根据历史数据计算不一样类型业务的比例关系；

业务模型组装以后，单一事务中的业务模型，应该是一个漏斗状的。而每层之间的漏斗比例，是根据不一样的层级、不一样的玩法、不一样的规则会有不同的比例关系。在一次大促活动中，这个比例关系理论上是不会变化的。漏斗模型参考以下：

业务模型在压测时对应的就是压测量级，淘宝大促用的所有都是RPS模式压测，即从服务端角度出发每一个API之间是漏斗比例关系、可以很好地应用于容量规划上。商业化产品PTS（性能测试服务，Performance Testing Service）中也很好的支持了RPS模式。

压测基础数据

若是说业务模型对应的是肯定要压测的接口/API的话，那压测流量数据，就是肯定这些压测API到底压测的是什么内容，好比：登陆哪些用户、查看哪些商品和店铺、购买哪些商品，甚至是付款价格是什么。

流量数据中，有一部分为上述业务模型对应具体RPS值，模型体现的是比例关系，而流量数据即有每次压测具体的RPS值。

流量数据中最重要的部分，即为真实的压测数据，咱们能够称之为基础数据，好比交易的买家、卖家、商品数据等。全链路压测的目的是为了模拟双11，因此模拟的真实性很是重要，基础数据的真实性就是相当重要的一环。全链路压测会以线上数据做为数据源，通过采样、过滤、脱敏等操做，造成可做为压测使用的数据。

线上数据拿出来使用的时候，特别涉及到写数据的时候，避免形成脏数据，咱们落地或者读取的时候，采用影子表的形式。当识别到压测流量，则读写影子表，不然就读写线上正式表。影子表的产生为的是压测流量安全。

淘宝内部系统使用的压测体系，数据平台和压测平台是两套平台。数据平台管理/提供压测数据（包括模型数据和流量数据），压测平台提供施压能力，即保证压测请求可以以指定的“协议”、指定的量级速率、从全国各地发送出来。商业化产品PTS（性能测试服务，Performance Testing Service）中提供的数据工厂能力，很好的将内部的数据平台和压测平台结合起来，产出为统一的一个压测系统，只需用户构造好压测数据以文件/自定义的形式定义好参数，在使用处配置便可。

流量安全策略

流量安全策略主要是为了保证可以正常的施压流量且数据不错乱，安全地、符合预期地进行。这里面就包括了两层考虑：

测试数据和正常数据的严格隔离，即非法流量的监控和保护机制；

• 手段：影子表数据。影子表为和线上结构一致，可是处于隔离位置的可写压测数据表。
• 效果：数据隔离，避免了数据错乱。

压测流量的安全过滤，即不被识别为攻击流量；

• 手段：将安全相关策略接入流控降级功能；针对压测适当放松安全策略，或根据特殊标记识别；
• 效果：压测流量不被断定为攻击流量，成功压测的同时保障线上业务的安全性。

此处，涉及到第三方的系统，诸如支付宝、短信等服务，因业务特殊性须要作压测系统的打通。13年淘宝实现了第一次全链路压测，可是未能打通下游业务链路。在14年双十一压测前，和支付宝、物流环节等打通了全面的压测系统。对于外部客户来讲，支付宝、短信等都有对应的挡板服务可提供，用来供用户作全链路压测时使用。

压测实施

根据最开始介绍到的流程管控，一切准备就绪以后，便可开始进行全链路压测。除常规理解的正式压测以外，咱们还有额外的两个预操做：系统预热、登陆准备。

说明：此处未介绍首次改造以后的单链路压测调试，这部分基本由开发同窗自行操做验证，故不在此特殊阐述。

关于系统预热 这里说的预热，未包含咱们内部提到的预跑。预热是为了该缓存的数据提早缓存好，达到大促缓存态的状态，也更好地实现咱们缓存的目的。大促缓存的使用应该利用到极致，故须要经过预热来进行。

对外部客户来讲，能够经过先一轮、低量级的全链路压测，来提早预热系统，包括在真正大促活动以前也可这样操做，即提早缓存住须要缓存的数据。

登陆准备：登陆准备主要是用于须要长链接保持、秒杀等场景，即用户都是逐步登陆上来，而后再进行业务操做的场景。故若是量级特别大的时候，能够提早作登陆的准备，一则来模拟真实用户登陆场景，二则是对登陆系统的保护。

正式压测：通常正式压测会按照压测计划，执行多种压测策略。淘宝的双11大促压测，通常包含这样几步：

1）峰值脉冲：即彻底模拟0点大促目标峰值流量，进行大促态压测，观察系统表现。

2）系统摸高：取消限流降级保护功能，抬高当前压测值（前提是当前的目标压测值已经达到，则能够进行摸高测试），观察系统的极限值是多少。可进行多轮提高压力值压测，直到系统出现异常为止。

3）限流降级验证：即验证限流降级保护功能是否正常。 （AHAS引入）商业化产品AHAS(应用高可用服务，Application High Availability Service）提供了全面的限流降级能力，可进行全链路的降级保护。

4）破坏性测试：这个主要是为了验证预案的有效性，相似于容灾演练时的预案执行演练。即为持续保持大促态压测，并验证预案的有效性，观察执行预案以后对系统的影响。

对外部客户来讲，能够配置不一样的压测量级数据，来进行多轮压测，并观察其系统表现。压测不该该是一次性的操做，而应该是反复的、多轮验证的操做。

问题定位分析

压测结束以后，会将压测过程当中的系统表现、监控数据等整理，进行压测复盘，分析当前系统瓶颈、后续改进修复计划及下一轮压测时间等。在分析定位问题时，因涉及的系统较多、子业务系统的形态不一，须要具体问题具体分析，其中难免须要一线研发的介入。

商业化产品PTS（性能测试服务，Performance Testing Service）的压测报告，有详细统计数据及趋势图数据，采样日志以及添加了的监控数据。后续PTS还会提供架构监控，帮助性能测试执行同窗，更好地从系统架构角度断定压测过程当中系统是否正常，大体瓶颈点。

智能化压测

阿里巴巴全链路压测已经进入第7个年头，从开始的摸着石头过河，发展到如今更智能化形态。其中部分功能也会体如今商业化产品中，你们敬请期待。

• 更多协议的支持
• 容量评估
• 问题自动发现
• 全链路功能测试&压测预演
• 压测常态化
• 弹性大促，边压边弹
• ......

将来

阿里巴巴将全链路压测进行到第7个年头，中间经历了太多的磨练与积累，随着新技术的出现，咱们也将不断的完善本身，作到更好。同时，更但愿能将这么多年的经验，能赋能到外部客户，比咱们少踩坑、完美的度过每一轮大促活动，并将全链路压测应用到更多的平常场景中。

---

本文做者： 牛兔

阅读原文

本文来自云栖社区合做伙伴“阿里技术”，如需转载请联系原做者。