丰富的线上&线下活动，深入探索云世界
做任务，得社区积分和周边
最真实的开发者用云体验
让每位学生受益于普惠算力
让创作激发创新
资深技术专家手把手带教
遇见技术追梦人
技术交流，直击现场
海量开发者使用工具、手册，免费下载
极速、全面、稳定、安全的开源镜像
开发手册、白皮书、案例集等实战精华
为开发者定制的Chrome浏览器插件
关于性能测试的重要性及必要性已经是个老生常谈的问题了，现分别从技术角度和业务战略角度总结如下：
而性能测试的目的也就是为了解决大型营销活动中洪峰流量引起的系统表现不确定性，一个理想的营销活动周期应该是有如下闭环流程：
可以看出，性能测试通过真实、高效的压测方式进行容量评估/瓶颈定位&解决，最终来保障活动稳定进行；每一个环节的内容都非常重要，以阿里双11活动为例，我们除了技术上的准备、执行、保障之外，还会有一些流程及分工细节。以下将逐一介绍。
阿里巴巴全链路压测从2013年到现在也已经是第7个年头了，在这7年中间我们不断的积累、总结、优化进步，从开始的200多人参与、通宵压测的大规模全员项目活动到后来仅仅几个人白天压测、更智能化的压测方式，这样一种大规模的项目活动，离不开有效的流程把控及分工管理。
阿里巴巴在多年双十一大促保障——全链路压测项目中，有着严格的流程把控及分工管理模式与经验，总结如下：
好的流程规划与管理，可以大大提升团队协作效率。叠加上工具平台的智能化功能，可以将参与的200人力通宵压测缩减至10人以内白天压测，有效的方案+充足的准备+靠谱的平台技术产品=成功的压测。
数据准备的同时，需要考虑压测环境（即压测对象的部署环境）是哪里，不同环境就需要做不同的准备。
整个阿里经济体的压测环境，包括双十一压测，全部选择的是线上环境，此时需要评估如果要进行全链路压测，是否直接可以使用现有环境、同一个API多次压测是否会被拦截、是否会有脏数据影响、如果有影响应该如何改造避免等。以上这些问题总结下来即为两类问题：业务问题和数据传递问题。问题比较明确，我们就根据这两类问题来做逐一的改造。
改造分为2方面：业务改造和中间件改造，这些在内部全链路压测1.0时代就已经完成了，对于外部客户来说，可以作为一个技术改造上的参考点。同时我们已经有成熟的产品化方案提供一站式的能力，免去复杂的改造和维护成本。
业务改造
业务改造即为了解决压测过程中的业务异常问题，或者压测请求无法正常被执行的问题。举例如下：
业务改造涉及的内容无法一一穷举，需要根据不同的业务模型、业务架构及配置，一一梳理。一般梳理改造之后，后续所有新应用都按照规范去开发，每年的压测前进行基础的查漏补缺即可。
中间件改造
中间件作为衔接业务应用之间的组件，在压测中有个至关重要的功能就是将流量标识传递下去，一直到最终的数据库层面。虽然我们在13年开始，从核心应用使用到的中间件已经升级改造完成，中间我们踩过不少坑，诸如改造全面性、改造带来的业务代码修改成本、版本兼容问题等。
改造完成之后，压测流量的模型图可以参考如下：
环境的改造，需要结合业务场景具体分析、设计。云上高可用解决方案，提供了全链路压测解决方案的服务。
大促活动确定之后，会对业务模型进行一次评审，即确定该业务模式对应的技术架构应用有哪些，需要做压测的业务范围有哪些、以及数据量级、数据形式是什么样的。所以数据准备包括准备业务模型数据和压测流量数据两部分。数据的准备，主要分为两部分：业务模型的建立和基础数据的构造。
业务模型数据
最终会将两种业务场景类型进行组合，形成最终的终态业务模型。以下图作为示例：
在组装业务模型数据的时候，需要注意一些关键因素，比如修改具体的电商业务模型关键因素：
业务模型组装之后，单一事务中的业务模型，应该是一个漏斗状的。而每层之间的漏斗比例，是根据不同的层级、不同的玩法、不同的规则会有不一样的比例关系。在一次大促活动中，这个比例关系理论上是不会变化的。漏斗模型参考如下：
业务模型在压测时对应的就是压测量级，淘宝大促用的全部都是RPS模式压测，即从服务端角度出发每个API之间是漏斗比例关系、能够很好地应用于容量规划上。商业化产品PTS（性能测试服务，PerformanceTestingService）中也很好的支持了RPS模式。
压测基础数据
流量数据中，有一部分为上述业务模型对应具体RPS值，模型体现的是比例关系，而流量数据即有每次压测具体的RPS值。
流量数据中最重要的部分，即为真实的压测数据，我们可以称之为基础数据，比如交易的买家、卖家、商品数据等。全链路压测的目的是为了模拟双11，所以模拟的真实性非常重要，基础数据的真实性就是至关重要的一环。全链路压测会以线上数据作为数据源，经过采样、过滤、脱敏等操作，形成可作为压测使用的数据。
线上数据拿出来使用的时候，特别涉及到写数据的时候，避免造成脏数据，我们落地或者读取的时候，采用影子表的形式。当识别到压测流量，则读写影子表，否则就读写线上正式表。影子表的产生为的是压测流量安全。
淘宝内部系统使用的压测体系，数据平台和压测平台是两套平台。数据平台管理/提供压测数据（包括模型数据和流量数据），压测平台提供施压能力，即保证压测请求能够以指定的“协议”、指定的量级速率、从全国各地发送出来。商业化产品PTS（性能测试服务，PerformanceTestingService）中提供的数据工厂能力，很好的将内部的数据平台和压测平台结合起来，产出为统一的一个压测系统，只需用户构造好压测数据以文件/自定义的形式定义好参数，在使用处配置即可。
流量安全策略主要是为了保证能够正常的施压流量且数据不错乱，安全地、符合预期地进行。这里面就包括了两层考虑：
测试数据和正常数据的严格隔离，即非法流量的监控和保护机制；
压测流量的安全过滤，即不被识别为攻击流量；
此处，涉及到第三方的系统，诸如支付宝、短信等服务，因业务特殊性需要做压测系统的打通。13年淘宝实现了第一次全链路压测，但是未能打通下游业务链路。在14年双十一压测前，和支付宝、物流环节等打通了全面的压测系统。对于外部客户来说，支付宝、短信等都有对应的挡板服务可提供，用来供用户做全链路压测时使用。
说明：此处未介绍首次改造之后的单链路压测调试，这部分基本由开发同学自行操作验证，故不在此特殊阐述。
关于系统预热这里说的预热，未包含我们内部提到的预跑。预热是为了该缓存的数据提前缓存好，达到大促缓存态的状态，也更好地实现我们缓存的目的。大促缓存的使用应该利用到极致，故需要通过预热来进行。
对外部客户来说，可以通过先一轮、低量级的全链路压测，来提前预热系统，包括在真正大促活动之前也可这样操作，即提前缓存住需要缓存的数据。
正式压测：一般正式压测会按照压测计划，执行多种压测策略。淘宝的双11大促压测，一般包含这样几步：
1）峰值脉冲：即完全模拟0点大促目标峰值流量，进行大促态压测，观察系统表现。
2）系统摸高：取消限流降级保护功能，抬高当前压测值（前提是当前的目标压测值已经达到，则可以进行摸高测试），观察系统的极限值是多少。可进行多轮提升压力值压测，直到系统出现异常为止。
3）限流降级验证：即验证限流降级保护功能是否正常。（AHAS引入）商业化产品AHAS(应用高可用服务，ApplicationHighAvailabilityService）提供了全面的限流降级能力，可进行全链路的降级保护。
4）破坏性测试：这个主要是为了验证预案的有效性，类似于容灾演练时的预案执行演练。即为持续保持大促态压测，并验证预案的有效性，观察执行预案之后对系统的影响。
对外部客户来说，可以配置不同的压测量级数据，来进行多轮压测，并观察其系统表现。压测不应该是一次性的操作，而应该是反复的、多轮验证的操作。
商业化产品PTS（性能测试服务，PerformanceTestingService）的压测报告，有详细统计数据及趋势图数据，采样日志以及添加了的监控数据。后续PTS还会提供架构监控，帮助性能测试执行同学，更好地从系统架构角度判定压测过程中系统是否正常，大致瓶颈点。
阿里巴巴全链路压测已经进入第7个年头，从开始的摸着石头过河，发展到现在更智能化形态。其中部分功能也会体现在商业化产品中，大家敬请期待。
阿里巴巴将全链路压测进行到第7个年头，中间经历了太多的磨练与积累，随着新技术的出现，我们也将不断的完善自己，做到更好。同时，更希望能将这么多年的经验，能赋能到外部客户，比我们少踩坑、完美的度过每一轮大促活动，并将全链路压测应用到更多的日常场景中。