共计 3359 个字符，预计需要花费 9 分钟才能阅读完成。
作者：拂衣
PTS 简介
性能测试 PTS（Performance Testing Service）是阿里云上一款简略易用，具备弱小的分布式压测能力的 SaaS 压测平台。PTS 能够模仿简单的业务场景，并疾速精准地调度不同规模的流量，同时提供压测过程中多维度的监控指标和日志记录。用户无需筹备资源，即可按需发动压测工作，监控压测指标，获取压测报告，进而可能高效率、全方位地验证业务站点的性能、容量和稳定性。
阿里云压测平台演进之路
阿里云压测平台 PTS，由阿里云可观测团队倾心打造，应双十一稳定性和容量布局的需要背景而诞生，随高可用、中间件上云而对外输入产品能力。整体演进分以下 5 个阶段：
2010 年 - 阿里巴巴容量布局平台
在此之前，阿里巴巴大促流动的容量布局次要通过人工估算的形式来实现的。各个系统的负责同学聚在一起开个会，将信息汇总到一起，按专家教训就把容量布局的机器估算给定下来了。而且，各个系统通常都留了比拟大的机器冗余，即便估算的不准也不会造成大的业务影响。
此时，容量计算的公式被第一次提了进去，通过指标容量 / 单机容量下限，失去各利用须要的机器资源数，再加上肯定比例的冗余量，就是大促时须要的总资源数。
在阿里容量布局平台的 1.0 版本当中，通过对各业务零碎线下环境单机压测，来获取各服务的单机容量下限，实现了从人工容量布局到系统化容量布局的适度。
2013 年 - 阿里巴巴全链路压测 - 流量平台
随着双十一业务规模疾速拉升，分布式系统架构的技术组件越来越多，利用的上下游依赖关系也越来越简单。双十一当天 0 点到来的时候，从 CDN 到接入层、前端利用、后端服务、缓存、存储、中间件整个链路上都面临着微小流量，这个时候利用的服务状态除了受本身影响，还会受到依赖环境影响，并且影响面会持续传递到上游，哪怕一个环节呈现一点误差，误差在上下游通过几层累积后会造成什么影响谁都无奈确定。因为各层依赖的不确定性，无奈再基于单业务容量下限布局全局容量。
所以咱们建设了全链路压测机制，通过全面仿真双十一业务流量，咱们的零碎可能提前经验几次“双十一”，让容量的不确定性问题提前裸露并解决。
流量平台是全链路压测的 CPU，可能模拟出双十一上亿用户的仿真流量，制作每秒数十万次用户行为的超大规模流量。次要由两大部件形成：1）全链路压测操控核心，进行压测的配置和操控、数据的监控以及对压测引擎集群的管控；2）压测引擎，由控制台对立管控，部署在外网 cdn 集群，进行登陆、session 同步，发送各种协定的压测申请、状态统计。
2013 年之后，全链路压测成为双十一、双十二等大促备战最重要的稳定性验证工具，随着业务的倒退一直进化，继续施展着不可代替的作用。
2018 年 - 阿里云 PTS 1.0：阿里云压测产品公布
在云计算的浪潮下，越来越多的用户开始基于阿里云上的根底产品设计本人的架构。在 2018 年，咱们正式公布了阿里云压测产品：PTS，将阿里巴巴团体压测平台的技术架构迁徙至阿里云，对外部用户提供 SaaS 化的压测产品。PTS 1.0 外围能力包含：
- 有限靠近实在的流量：业务场景中无论是高并发要求还是发动端的分散度，笼罩三四线城市次要运营商的节点广度都能做到真正模仿用户行为，客户端到服务端间简单的网络瓶颈也能暴露无遗，压测后果更加全面和真实可信。
- 操作简略易上手：不须要专门的性能测试团队或者测试背景的积攒，齐全面向开发的交互设计，开发自测试，投入产出比高。
- 多维度施压：反对并发和 RPS 双维度。
- 压力动静调整：反对压测能力动静批改。
2020 年 - 阿里云 PTS 2.0：施压能力、产品体验再降级
随着 PTS 1.0 用户规模的不断扩大，越来越多的用户在不同的业务场景对 PTS 提出了反对超高并发的压测需要，甚至超过了团体双十一的并发量级，典型场景如：春晚红包压测、保险开门红压测、考试报名压测等。PTS 2.0 通过优化资源调度和施压引擎性能，提供了百万并发、千万 QPS 的压测能力，间断撑持了屡次春晚红包流动等顶级流量压测。
同时，PTS 2.0 降级了流量录制和多协定场景化性能，晋升了产品体验：
- 流量录制性能：容许录制理论用户操作，以便创立实在的用户行为模仿。
- 多协定反对：对流媒体、MQTT、RocketMQ、Kafka、JDBC、Redis、Dubbo 等协定反对白屏化压测配置，扩宽测试场景。
2024 年 - 阿里云 PTS 3.0：可观测、智能化、开源加持的下一代压测平台
在 PTS 1.0 和 2.0 的继续演进中，PTS 在产品体验、施压能力都失去了大幅晋升。要做一轮残缺的容量布局，用户还须要解决以下问题：
- 评估压测的影响范畴，确定压测流量会通过哪些服务端利用，如何精确地掌控压测的爆炸半径。
- 洞察压测和业务零碎的全局监控指标，剖析以后零碎容量水位。
- 如果压测后果不满足预期，须要出剖析整个零碎的性能瓶颈点。
这些问题是每个测试团队都须要面对的，在云原生和可观测技术的倒退下，如何更好的解决这些问题？
针对以上挑战，咱们提出性能压测可观测化能力，别离针对以上问题提出压测链路可观测：
首先，在施行压测前，先执行一次拨测，通过拨测发动一次申请来构建整个压测链路拓扑，通过链路拓扑全局来看整个压测的影响范畴。
其次，性能指标可观测，获取压测链路所波及的监控指标，主动生成压测及各业务各实例水位大盘，边压边观测。
再次，聚合压测申请各指标和调用链，通过 调用链分析和智能化剖析，实现性能瓶颈可观测。
最初，通过后面提到的压测指标和各服务实例资源水位，进行梯度压测评估验证零碎服务容量。构建性能压测可观测，实现从压测到数据分析。在此之上，咱们构建了可观测加持下的下一代阿里云压测平台 PTS 3.0，通过买通阿里云全栈可观测生态，并集成云原生大模型和多模型智能归因算法，给用户提供更业余、论断更清晰、更有洞察力的压测报告，辅助用户在 PTS 实现压测瓶颈定位和根因剖析。
同时 PTS 3.0 全面兼容开源 JMeter 压测工具，只需 JMeter 脚本上传到 PTS，即可主动补全依赖插件，一键发动压测。
PTS 3.0 外围性能
主动感知压测利用拓扑
PTS 与阿里云可观测链路 OpenTelemetry 买通，在发动压测之前，会通过拨测能力进行压测脚本测试和链路探测，能主动精确辨认申请链路所通过的组件，依据拨测申请建设链路拓扑图，不会波及失常申请所通过的链路，这样咱们就能够很直观的感知压测所通过的链路，明确压测波及的利用范畴和架构拓扑。
利用瓶颈剖析
压测性能瓶颈往往呈现在服务端应用层，最通过压测报告 - 全局监控 - 利用监控，能够观测到压测时段各服务端利用的正本数，以及 CPU、内存、磁盘等资源水位。配合谬误申请数、数据库错慢调用次数、FullGC 次数等指标，能够判断出哪些利用负载较高，须要优化性能或扩容。
对 JVM 内存透露等场景，能够通过 JVM 监控判断出问题景象，并配合 Profiling 剖析根因。
错慢申请根因剖析
定界瓶颈点在应用层，须要进一步剖析根因时，PTS 能够买通可观测链路 OpenTelemetry，获取到本次压测的错慢调用链，蕴含从施压端到数据库层的残缺链路。通过下钻剖析，能够定位到申请在调用链的哪里呈现了错慢景象，并能够通过堆栈剖析，判断出错慢的起因。
云资源瓶颈剖析
在云原生的架构体系中，零碎接入层、数据库、中间件、容器等根底资源都人造在云上，通过买通阿里云可观测监控 Prometheus，能够获取到负载平衡 SLB、RDS 数据库、ECS、容器等根底云资源的监控指标和大盘，辅助用户剖析云资源是否存在瓶颈。
智能洞察
性能测试 PTS 3.0 通过异样区间检测算法，主动发现应用层监控指标的异动，并通过多模型的智能归因算法，推理出异常现象的根因。
总结
PTS 3.0 以瓶颈剖析为外围场景，构建出可观测、智能化、开源加持的下一代压测平台。目前 PTS 3.0 已全面上线，新版控制台地址：https://ptsnext.console.aliyun.com/
PTS 2.0 用户能够通过概览页右上角的“体验 PTS 3.0”按钮，一键跳转新版，新版 PTS 和 JMeter 的场景与报告和 PTS 2.0 齐全兼容。
为了更好的满足中小企业上云验证、容量布局等性能测试需要，目前性能测试 PTS 推出 59.9 元根底版特惠资源包。
3 万 VUM 额度，最高 5 万虚构用户规模并发量，让性能测试更具性价比。
点击此处，立刻查看详情！
