作者：子矜
审核 & 校对：风波、雨芙
编辑 & 排版：雯燕
客户的故事
全链路压测被誉为大促备战的“核武器”，如果之前有关注过阿里双 11 相干的技术总结，对“全链路压测”肯定不会生疏，这个词的出场率简直 100%。从对双 11 稳定性的价值来看，用“核武器”来形容全链路压测毫不为过。
在某出名电商大促中，该电商平台也想用全链路压测来为本人的大促提前排除危险。然而他遇到几个艰难:
- 全链路压测是一个须要多角色参加的流动：业务方，测试，运维，研发，数据库，都须要参加进来。然而可能像阿里具备成熟的组织体系，能够强有力的推动各种不同的角色，都是须要较长时间来积攒的。
- 全链路压测，经常波及到框架的革新：而该电商平台的业务简单，做构造梳理与业务革新并不事实。
那这个出名电商平台，有什么方法能够在 1 个星期之内，不进行业务革新，不扭转业务部署，就可能用上全链路压测呢？
接下来的内容，咱们会从全链路压测的原理开始，并引入基于同样原理的“麻利版”全链路压测，让该出名电商平台可能在 2 周之内就能用上全链路压测的计划。
全链路压测
首先，咱们来看看阿里的全链路压测，到底解决了什么问题：
全链路压测实际上解决的问题是：在线上的压测。线上压测，可能最快、最间接的发现线上的问题。然而，线上压测会带来数据净化的问题：如何把压测数据和实在数据辨别开来，是压测里至关重要的一点。那么，阿里是怎么做的呢？咱们一起来看下图：
阿里的全链路压测具备一套成熟又简单的零碎：压测的梳理、构建、筹备、发送。然而，这套体系对于一个云上的用户是须要长期建设失去的。那咱们如何可能让用户疾速，麻利的享受这套技术呢？
在这里，PTS 把整个流程进行积淀，都以标准化的输入来提供给云上的用户。用户能够间接享受一整套的全链路压测体系，也能够在压测的关键环节：例如场景梳理、申请构建、压测环境、压测等步骤中，依据本人的需要来定制本人想要的压测成果。
场景梳理
业务场景，即对应的是压测的输出申请。这是压测第一步，也是最重要的一步。最常见的是把波及到业务的 URL 进行梳理，汇总。例如下图就是一个常见的场景汇总：
然而，这是不够的。当若干个 URL 汇总成一个场景之后，URL 之间的比例、工夫距离，也是影响业务场景的要害。用常见的场景打一个比如：一个用户的下单，可能背地蕴含着 10 个用户登录，每个用户均匀浏览了 4 个商品，每个商品中均匀被浏览了 5 个评估，最初一个用户在 10 点大促开始的时候，购买了一个商品。
这些 URL 之间的关系、工夫点，须要人员有丰盛的业务知识能力梳理分明。为此，PTS 提供服务端流量录制的性能，不便用户来录制流量，并且轻松的失去其中不同维度的比例关系:
如上图所示，用户能够清晰的失去 URL 之间的比例关系、用户 URL 之间的工夫行为等等。基于这个梳理好的数据模型，用户能够在这个根底上进行裁剪。
测试数据结构
接下来，就是结构用户数据了。这一步波及的角色最多，也最为繁琐。整个数据结构由三个步骤形成，如下图所示：
首先是数据发现。通常，咱们能够通过人工业务梳理，失去该业务所波及到的所有表，并进行剖析。PTS 为罢黜这个懊恼，和 DMS 买通，提供表构造预览，让测试人员不便的看清楚和场景相关联的构造，大大的晋升效率。
如果还是感觉太简单，PTS 将提供数据录制工具，装置了这个 agent 之后，该业务所波及的表，都会被残缺的记录下来：
有了这些工具，测试人员就能够毋庸 DBA 的帮助，轻松的失去场景关联的表信息了。
数据闭包
有了这些数据表，并且在这根底之上剖析进去数据闭包后，咱们能够开始制作压测数据了。通常，咱们制作影子表的形式有三种:
- 影子库 – 全量的进行影子库映射。该办法的劣势是简略，劣势是耗费资源多；
- 影子表 – 将表闭包里的表，通过肯定规定，进行名字关联。该办法的劣势是节俭资源，劣势是须要对表进行充沛梳理，并且一一对应；
- 不新建表，在同一张表内，将影子数据进行大位移偏移。这个将在前面的麻利版内进行介绍。
这三种形式能够依据需要组合应用。
数据导入 / 混扰
有了这些前提之后，咱们能够利用 DMS 来数据导入，进行数据制作了。
到这里，咱们实现了全链路压测中最简单的两个步骤：压测场景梳理、压测数据制作。
接下来咱们通过数据加工，把这两个元素最终加工为压测数据。
数据加工
此时，咱们对压测数据做最初一个步骤，进行数据加工。即咱们把业务场景、压测数据，依照咱们的业务模型进行最初的调整与加工:
到这里，咱们能够看到，全链路压测的压测申请，都曾经成型了。接下来，咱们能够开始设计压测流量在压测对象中的行为了。
测试环境
压测能够在仿真环境、线上环境中进行。不同的环境，选取数据，制作数据都有不同的考量。如下图所示：
简略的说，测试环境关注的是单个组件：例如微服务、接口、但协定（SQL，Redis）等压测；预发环境（通常是 VPC 环境）则关注链路整合；生产环境则最迫近实在场景。在这里，咱们只探讨线上生产环境。
传统全链路压测
下图简略的诠释了传统全链路压测的运作形式；
咱们看到，传统的全链路压测，次要通过流量打标，来辨别压测流量和实在流量，做到这一点，须要保障这个压测标可能被层层的透传下去。而当流量到了“写”的这层，部署好的 agent 依据压测标，来决定“写”的行为，是写到实在的数据库呢？还是写到影子区域？情理很简略，然而施行的时候还是会碰到不少的难点。其中，次要波及的问题是：
- 如果利用应用到的框架不规范，则须要进行适配；
- 推动开发装置 agent 的流程简单；
- 验证 agent 的覆盖面简单。
麻利版的全链路压测
如果咱们不想要革新业务，也不想要挂载 agent，咱们能如何去做到这一点呢？
咱们来看一下抽样测试的原理。在测试的时候，通常有一种伎俩，即通过选取几个特定的实在用户数据来进行测试，来验证程序的正确性；如果咱们把这些实在用户数据，变成假用户，那么须要满足上面这个要害条件：假用户以及假用户在这个业务场景下波及到的业务数据，以及业务场景下相干的数据，都可能被辨认进去。
例如，咱们模仿一个假用户，购买某个假商品，这里的用户，商品，都可能有一个特定的特色，这个假用户生成的浏览记录、购买记录，在数据库的体现中都有该用户的 ID；在这个前提下，咱们是可能把脏数据从实在数据中辨认进去的；
这种压测，须要盘点出以下两点:
- 残缺的找出业务波及到的数据表 – 参考上一章节外面的 PTS SQL 录制性能；
- 制作影子数据 – 和传统全链路压测不一样，这里咱们选取的是第三种形式，即在一张表里做大位移，而不是制作影子表或者影子库。压测完结后，依据影子数据的特色，巡检数据库并且进行清理；
这种形式，是基于使用者对业务有清晰的理解，制作进去的压测数据有显著的压测标识（比失常数据大的多的偏移量），所有波及的写压测，都带有这些偏移量；这样，所有压测产生的数据，都可能被辨认进去。压测完结之后，依据这个数据特色，来清理压测数据；
流量引擎的抉择
为了更好的模仿用户的行为，咱们经常会应用压测地区的定制。然而把压测引擎部署到全国各地是不事实的；而 PTS 能够不便的让用户抉择地区的发动，如下图所示:
总结
PTS 联合 10 多年来阿里的全链路压测的教训，让阿里云的用户能够如同享受满汉全席般的享受全套规范的全链路压测，也能够依据本人的需要，抉择最适宜本人的形式。
另外，PTS 最近价格上也做了“麻利”优化，更多的抉择，点击此处即可查看～