简介：PTS结合了阿里巴巴10多年的全链路压测经验，让阿里云用户如同身临其境一样享受全套标准的全链路压测。享受一个完整的宴会。您也可以根据自己的需要选择最适合自己的方法。作者：紫金客户故事全链路压测被誉为备战大促的“核武器”。如果你之前关注过阿里巴巴双11相关的技术总结，想必对“全链路压测”并不陌生。这句话的出现率几乎是100%。从价值到双11的稳定性来看，用“核武器”来形容全链路压测也不为过。某知名电商平台在大促期间，电商平台也想通过全链路压测，为自己的大促提前排除风险。然而，他遇到了几个困难：全链路压测是一项需要多方角色参与的活动：业务方、测试、运维、研发、数据库都需要参与。但是，能够像阿里一样拥有成熟的组织体系，能够强力推动各种角色，需要长时间的积累。全链路压测往往涉及到框架的改造：而电商平台业务复杂，做结构梳理和业务改造不太现实。那么这个知名电商平台，有没有什么办法可以做到一周内全链路压测，不做任何业务改造，不改变业务部署？在接下来的内容中，我们将从全链路压测原理入手，介绍基于相同原理的“敏捷版”全链路压测，让知名电商平台使用全链路压测。2周内链接链接压力测试的解决方案。全链路压测首先我们来看一下阿里的全链路压测。它解决了什么问题？全链路压测实际解决的问题是：线上压测。线上压测可以最快最直接的发现线上问题。但是线上压测会带来数据污染：如何区分压测数据和真实数据是压测的一个重点。那么，阿里是怎么做到的呢？我们看下图：阿里的全??链路压测有一套成熟复杂的体系：压测整理、构建、准备、发送。但是这个系统对于一个用户在云端需要长期的建设。那么怎样才能让用户又快又快的享受到这项技术呢？在这里，PTS沉淀了整个流程，并在云端为用户提供标准化的输出。用户可以直接享受一套完整的全链路压测系统，也可以在压测的关键环节：如场景整理、请求构建、压测环境、压测等，根据自己的需求定制自己想要的.压力测量效果。场景梳理业务场景，对应压测的输入请求。这是压力测试的第一步，也是最重要的一步。最常见的是对与业务相关的网址进行梳理和归纳。例如下图是一个常见的场景总结：然而，这还不够。当多个URL聚合成一个场景时，URL之间的比例和时间间隔也是影响业务场景的关键。以一个常见的场景为例：一个用户下单后可能有10个用户登录，每个用户平均浏览4个商品，每个商品平均收到5条评论，最后一个用户在10点开始积分促销时，我买了一个产品。这些URL之间的关系和时间点，需要有丰富业务知识的人员才能梳理清楚。为此，PTS提供了服务器端流量记录的功能，方便用户记录流量，轻松获取不同维度的比例关系：如上图，用户可以清晰的获取URL之间的比例关系以及用户URL之间的关系。时间行为等。基于这个梳理好的数据模型，用户可以在此基础上进行裁剪。测试数据构建下一步是构建用户数据。这一步涉及的角色最多，也最繁琐。整个数据结构包括三个步骤，如下图所示：首先是数据发现。通常，我们可以手动将业务涉及的所有表整理出来，并进行分析。为了避免这个麻烦，PTS对接了DMS，提供了表结构的预览，让测试人员可以很方便的看到场景关联的结构，大大提高了效率。如果还是觉得太复杂，PTS会提供数据记录工具。安装此代理后，业务涉及的表将被完整记录：通过这些工具，测试人员可以轻松获取与场景关联的表信息。数据闭包有了这些数据表，分析完基于此的数据闭包，我们就可以开始做压测数据了。通常，我们制作影子表的方式有以下三种：影子库-全影子库映射。这种方法的优点是简单，缺点是消耗资源多；影子表——表闭包中的表通过一定的规则与名称相关联。这种方式的优点是节省资源，缺点是需要对表格进行全面整理，一一对应；在不创建新表的情况下，阴影数据在同一张表中移动了一个大位移。这个会在后面的敏捷版本中引入。这三种方法可以根据需要结合使用。DataImport/Scrambling有了这些前提条件，我们就可以使用DMS来导入数据和制作数据了。至此，我们完成了全链路压测中最复杂的两个步骤：整理压测场景和制作压测数据。接下来，通过数据处理，将这两个要素最终处理成压力测量数据。数据处理至此，我们将对压测数据进行最后一步，数据处理。也就是我们根据我们的业务模型对业务场景和压测数据进行最后的调整和处理：至此，我们可以看到全链路压测的压测请求已经形成。接下来，我们就可以开始设计压测对象中压测流量的行为了。测试环境压力测试可以在模拟环境或在线环境中进行。不同的环境、数据选择和制造数据有不同的考虑。如下图所示：简单来说，测试环境主要针对单个组件：微服务、接口、协议（SQL、Redis）等压力测试；预发布环境（一般为VPC环境）侧重于链路集成；制作环境最接近真实场景。这里，我们只讨论在线生产环境。传统全链路压测下图简单说明了传统全链路压测的运行模式；至此，需要保证测压目标能够层层透传。并且当流量到达“写”层时，部署的代理根据压测标准确定“写”行为。它会写入真实的数据库吗？还是写到阴影区？道理很简单，但实施起来还是有很多困难。其中，涉及的主要问题是：如果应用使用的框架不标准，需要进行适配；代理开发安装推广过程复杂；验证代理的覆盖面很复杂。敏捷版全链路压测如果我们不想改造业务，也不想挂载代理，怎么办？我们先来看看抽样检测的原理。测试时，通常有一种手段可以通过选择几个特定的??真实用户数据进行测试来验证程序的正确性；如果我们把这些真实的用户数据变成虚假用户，那么我们需要满足如下关键条件：虚假用户和这个业务场景涉及的业务数据，以及业务场景中的相关数据是可以识别的。例如，我们模拟假用户购买假货。这里的用户和产品可以具有特定的功能。这个假用户产生的浏览记录和购买记录在数据库性能中都有用户的ID。;在此前提下，我们可以从真实数据中识别出脏数据；这种压测需要盘点以下两点：彻底摸清业务涉及的数据表——参考上一章PTSSQL记录功能；制作影子数据——与传统的全链路压测不同，这里我们选择第三种方式，即在一张表中做大位移，而不是制作影子表或影子库。压力测试结束后，根据影子数据的特点，对数据库进行巡检和清理；这种方式是基于用户对业务的清晰认识，产生的压测数据有明显的压测标记（比正常数据大很多offset），所有涉及的写压测都有这些offset；这样就可以识别出所有压力测试产生的数据。压测结束后，根据数据特征清理压测数据；流量引擎的选择常用于自定义压测区域，以更好地模拟用户行为。但是，将压力测试引擎部署到全国各地是不现实的；而PTS可以方便的让用户选择区域上线，如下图：总结PTS和阿里巴巴10多年的全链路压测经验，让阿里云用户享受全套标准的全链路压力测试犹如大饱眼福，也可根据自身需求选择最合适的方式。原文链接本文为阿里云原创内容，未经许可不得转载。
