网站开发后服务费,wordpress修改登录框字体,网站系统升级中,php网页设计实例代码简介#xff1a; PTS 结合 10 多年来阿里的全链路压测的经验#xff0c;让阿里云的用户可以如同享用满汉全席般的享用全套标准的全链路压测#xff0c;也可以根据自己的需求#xff0c;选择最适合自己的方式。
作者#xff1a;子矜
客户的故事
全链路压测被誉为大促备战…简介 PTS 结合 10 多年来阿里的全链路压测的经验让阿里云的用户可以如同享用满汉全席般的享用全套标准的全链路压测也可以根据自己的需求选择最适合自己的方式。
作者子矜
客户的故事
全链路压测被誉为大促备战的 “核武器” 如果之前有关注过阿里双 11 相关的技术总结对 “全链路压测” 一定不会陌生这个词的出场率几乎 100%。从对双 11 稳定性的价值来看用 “核武器” 来形容全链路压测毫不为过。
在某知名电商大促中该电商平台也想用全链路压测来为自己的大促提前排除风险。但是他遇到几个困难:
全链路压测是一个需要多角色参与的活动业务方测试运维研发数据库都需要参与进来。然而能够像阿里具备成熟的组织体系可以强有力的推动各种不同的角色都是需要较长时间来积累的。 全链路压测常常涉及到框架的改造而该电商平台的业务复杂做结构梳理与业务改造并不现实。
那这个知名电商平台有什么办法可以在 1 个星期之内不进行业务改造不改变业务部署就能够用上全链路压测呢
接下来的内容我们会从全链路压测的原理开始并引入基于同样原理的 “敏捷版” 全链路压测让该知名电商平台能够在 2 周之内就能用上全链路压测的方案。
全链路压测
首先我们来看看阿里的全链路压测到底解决了什么问题
全链路压测实际上解决的问题是在线上的压测。线上压测能够最快、最直接的发现线上的问题。然而线上压测会带来数据污染的问题如何把压测数据和真实数据区分开来是压测里至关重要的一点。那么阿里是怎么做的呢我们一起来看下图 阿里的全链路压测具有一套成熟又复杂的系统压测的梳理、构建、准备、发送。然而这套体系对于一个云上的用户是需要长期建设得到的。那我们如何能够让用户快速敏捷的享受这套技术呢
在这里PTS 把整个流程进行沉淀都以标准化的输出来提供给云上的用户。用户可以直接享用一整套的全链路压测体系也可以在压测的关键环节例如场景梳理、请求构建、压测环境、压测等步骤中根据自己的需求来定制自己想要的压测效果。
场景梳理
业务场景即对应的是压测的输入请求。这是压测第一步也是最重要的一步。最常见的是把涉及到业务的 URL 进行梳理汇总。例如下图就是一个常见的场景汇总 然而这是不够的。当若干个 URL 汇总成一个场景之后URL 之间的比例、时间间隔也是影响业务场景的关键。用常见的场景打一个比方一个用户的下单可能背后蕴含着 10 个用户登录每个用户平均浏览了 4 个商品每个商品中平均被浏览了 5 个评价最后一个用户在 10 点大促开始的时候购买了一个商品。
这些 URL 之间的关系、时间点需要人员有丰富的业务知识才能梳理清楚。为此PTS 提供服务端流量录制的功能方便用户来录制流量并且轻松的得到其中不同维度的比例关系: 如上图所示用户可以清晰的得到 URL 之间的比例关系、用户 URL 之间的时间行为等等。基于这个梳理好的数据模型用户可以在这个基础上进行裁剪。
测试数据构造
接下来就是构造用户数据了。这一步涉及的角色最多也最为繁琐。整个数据构造由三个步骤构成如下图所示 首先是数据发现。通常我们可以通过人工业务梳理得到该业务所涉及到的所有表并进行分析。PTS 为免除这个烦恼和DMS打通提供表结构预览让测试人员方便的看清楚和场景相关联的结构大大的提升效率。 如果还是觉得太复杂PTS将提供数据录制工具安装了这个 agent 之后该业务所涉及的表都会被完整的记录下来 有了这些工具测试人员就可以无须 DBA 的协助轻松的得到场景关联的表信息了。
数据闭包
有了这些数据表并且在这基础之上分析出来数据闭包后我们可以开始制作压测数据了。通常我们制作影子表的方式有三种:
影子库 – 全量的进行影子库映射。该方法的优势是简单劣势是消耗资源多 影子表 – 将表闭包里的表通过一定规则进行名字关联。该方法的优势是节省资源劣势是需要对表进行充分梳理并且一一对应 不新建表在同一张表内将影子数据进行大位移偏移。这个将在后面的敏捷版内进行介绍。这三种方式可以根据需求组合使用。
数据导入/混扰
有了这些前提之后我们可以利用 DMS 来数据导入进行数据制作了。 到这里我们完成了全链路压测中最复杂的两个步骤压测场景梳理、压测数据制作。
接下来我们通过数据加工把这两个元素最终加工为压测数据。
数据加工
此时我们对压测数据做最后一个步骤进行数据加工。即我们把业务场景、压测数据按照我们的业务模型进行最后的调整与加工:
到这里我们可以看到全链路压测的压测请求都已经成型了。接下来我们可以开始设计压测流量在压测对象中的行为了。
测试环境
压测可以在仿真环境、线上环境中进行。不同的环境选取数据制造数据都有不同的考量。如下图所示 简单的说测试环境关注的是单个组件例如微服务、接口、但协议SQLRedis等压测预发环境通常是VPC环境则关注链路整合生产环境则最逼近真实场景。在这里我们只讨论线上生产环境。
传统全链路压测
下图简单的诠释了传统全链路压测的运作方式 我们看到传统的全链路压测主要通过流量打标来区分压测流量和真实流量做到这一点需要保证这个压测标能够被层层的透传下去。而当流量到了 “写” 的这层部署好的 agent 根据压测标来决定 “写” 的行为是写到真实的数据库呢还是写到影子区域道理很简单但是实施的时候还是会碰到不少的难点。其中主要涉及的问题是
如果应用使用到的框架不标准则需要进行适配 推动开发安装 agent 的流程复杂 验证 agent 的覆盖面复杂。
敏捷版的全链路压测
如果我们不想要改造业务也不想要挂载 agent我们能如何去做到这一点呢
我们来看一下抽样测试的原理。在测试的时候通常有一种手段即通过选取几个特定的真实用户数据来进行测试来验证程序的正确性如果我们把这些真实用户数据变成假用户那么需要满足下面这个关键条件假用户以及假用户在这个业务场景下涉及到的业务数据以及业务场景下相关的数据都能够被识别出来。
例如我们模拟一个假用户购买某个假商品这里的用户商品都能够有一个特定的特征这个假用户生成的浏览记录、购买记录在数据库的表现中都有该用户的 ID在这个前提下我们是能够把脏数据从真实数据中识别出来的 这种压测需要盘点出以下两点:
完整的找出业务涉及到的数据表 – 参考上一章节里面的PTS SQL录制功能 制作影子数据 – 和传统全链路压测不一样这里我们选取的是第三种方式即在一张表里做大位移而不是制作影子表或者影子库。压测结束后根据影子数据的特征巡检数据库并且进行清理
这种方式是基于使用者对业务有清晰的了解制作出来的压测数据有明显的压测标识比正常数据大的多的偏移量所有涉及的写压测都带有这些偏移量这样所有压测产生的数据都能够被识别出来。压测结束之后根据这个数据特征来清理压测数据
流量引擎的选择
为了更好的模拟用户的行为我们常常会使用压测地域的定制。但是把压测引擎部署到全国各地是不现实的而PTS 可以方便的让用户选择地域的发起如下图所示: 总结
PTS 结合 10 多年来阿里的全链路压测的经验让阿里云的用户可以如同享用满汉全席般的享用全套标准的全链路压测也可以根据自己的需求选择最适合自己的方式。
原文链接 本文为阿里云原创内容未经允许不得转载。
