简介： 性能测试 PTS（Performance Testing Service）是一款阿里云 SaaS 化的性能测试工具，到当初曾经走过了 10 个年头。每年反对全团体范畴的几万次压测工作，是阿里外部双十一技术架构的 ” 提前验证者 ”。

作者 ​| 笛墨

引言

性能测试 PTS（Performance Testing Service）是一款阿里云 SaaS 化的性能测试工具，从最早为了精准模仿双十一流量洪峰诞生，到当初曾经走过了 10 个年头。每年反对包含双十一在内的全团体范畴的几万次压测工作，是阿里外部双十一技术架构的 ” 提前验证者 ”。

作为 SaaS 化的性能压测工具，PTS 反对按需发动压测工作，可提供百万并发、千万 TPS 流量发动能力。同时还能 100% 兼容 JMeter。提供的场景编排、API 调试、流量定制、流量录制等性能，可疾速创立业务压测脚本，通过全国上百城市笼罩各运营商节点，可精准模仿不同量级用户拜访业务零碎，帮忙业务疾速晋升零碎性能和稳定性，已广泛应用在批发、金融、在线教育等多个畛域。

明天 PTS 能力再次降级。压测协定的降级，进一步扩充了压测协定反对的范畴以及实用场景，让您无需再为不同的技术架构无奈压测懊恼；推出的低门槛的海量流量自助施压能力，让压测工具团队免去开发、运维的懊恼，点击启动压测，轻松就具备百万并发的自助压测能力；平安、无侵入的生产环境写压测的产品化能力，只需简略接入探针即可具备生产环境写压测能力，让每一个业务场景在生产环境压测时都不“落伍”，更全面精确的评估零碎性能、容量。

新公布 / 降级性能如下:

1. 反对 HTTP 2 协定。
2. 反对流媒体 RTMP/HLS 协定。
3. 反对 Websocket 协定。
4. 反对 MQTT 协定。
5. 反对 SpringCloud/Dubbo 微服务协定。
6. 最大 100W 并发自助压测能力。
7. 平安、无侵入的生产环境写压测。

压测反对协定降级

协定作为利用零碎交换的“语言”，明天在面对多样化的场景时，不同类型零碎采纳的协定正悄悄产生扭转。HTTP 协定作为利用最为宽泛传输协定，次要传输的是文本内容，承载了过来互联网的支流流量。当咱们明天面对多样化富文本的内容时，HTTP 协定显然不再是咱们技术服务惟一的抉择了。流媒体相干协定承当了你看视频内容的搬运工角色，看视频的时候看敲下“YYDS”的跟服务端走的是 Websocket 协定，你手上戴的智能化手表、家里的智能电气，没准是通过 MQTT 协定跟云端的服务在放弃着数据同步，哪怕你还是在浏览文本内容，搬运工交换的服务协定也正从 HTTP 1.1 到 HTTP 2、到 HTTP 3 等协定在产生转变。

作为技术、开发、测试人员，在面对疾速业务迭代的时候，要去了解每一个交互协定自身是个很头痛的事件。压测场景也同样相似，咱们显然无奈承受为每个零碎定制一个压测工具的老本。PTS 作为压测工具，在压测反对协定方面，为大家带来了全新降级，具体如下:

• 反对 HTTP 2 协定。
• 反对流媒体 RTMP/HLS 协定。
• 反对 Websocket 协定。
• 反对 MQTT 协定。
• 反对 SpringCloud/Dubbo 微服务协定。

1、反对 HTTP 2 压测

间隔 1997 年 HTTP 1.X 协定版本公布到当初，咱们的零碎应用 HTTP 1.x 提供内容服务曾经有相当长一段时间了。近十年互联网内容、互联网用户数呈爆发式增长，HTTP 1.x 曾经无奈满足古代网络的需要，越来越多的公司也开始从原来的 HTTP 1.X 降级到 HTTP 2，以换取更好的网页加载性能、安全性。大家能够通过以下图片感触 HTTP 2 协定带来的性能晋升。

HTTP 2 相比于 HTTP/1.1，次要的改良点包含以下几点:

1. 应用二进制传输。
2. Header 压缩。
3. 多路复用。
4. Server Push。
5. 晋升安全性。

通过后面的效果图能够看到，HTTP 2 的性能显著是要好于 HTTP 1.x 的。而晋升性能的要害个性在于二进制传输、Header 压缩、以及多路复用几个个性，上面来看下这三个个性的基本原理。

• 应用二进制传输

二进制协定相比纯文本模式解析起来更高效，再 HTTP 2.0 中，把原来的传输内容打散成 Frame 的形式，同域名下所有通信都在单个连贯上实现，把原来报文的构造做了打散，每个报文都又由一个或多个帧组成，多个帧之间能够乱序发送，依据帧首部的流标识能够从新组装，如下图所示：

• Header 压缩

在 HTTP 1.X 中，因为无状态的个性，导致大家发动申请的时候，常常须要带上一堆 Header，很多申请的 Header 甚至比 Body 更大。Header 内容过大，在肯定水平上减少了传输的老本。如果某个域名下的成千上万申请响应报文里有很多字段值都是反复的话，十分浪费资源。

因此在二进制传输的根底上，HTTP 2 协定减少了对 Header 的压缩能力，通过 HPACK 压缩算法，在客户端和服务器两端建设字典，用索引号示意反复的字符串，压缩效率能够达到 50%~90%。如下图两个申请所示，第一个申请发送了全副的 Header，第二个申请则只须要发送差别数据即可，以此来晋升效率:

• 多路复用

HTTP 2 中反对多路复用技术，多路复用很好的解决了浏览器同一个域名下申请数量的限度问题，同时升高了每次新开 TCP 申请的开销。在 HTTP 2 中，通过后面提到的二进制 Frame 的传输方式，并通过容许客户端和服务器将 HTTP 音讯合成为独立的帧，而后在另一端从新组装它们，从而实现残缺的申请和响应多路复用，如下图，客户端正在向服务器传输数据帧（Stream 5），而服务器正在向客户端传输流 1 和 3 的交织帧序列，有三个并行流在传输数据。

通过 HTTP 2 的二进制传输、以及多路复用技术，大家能够很好的看到以前浏览器对于同一个域名，TCP 长久连接数限度必须共用 TCP 管控而导致的同一时刻一个管道中只能解决一个申请的 Head-Of-Line Blocking，曾经不复存在了，这也是 HTTP 2 协定效率晋升的基本。

实践上 HTTP 2 是兼容 HTTP 1.x，如果客户端不反对 HTTP 2 协定，服务端会主动应用 HTTP 1.x 协定进行通信。而在咱们的性能压测场景中，大家通过上述例子能够看到  HTTP 2 跟 HTTP 1.x 性能体现是不统一的，如果压测引擎不反对 HTTP 2，压测时会间接降级成 HTTP 1.x。在明天支流漂泊器都反对 HTTP 2 协定的背景下，压测的理论后果会产生偏差。

因此咱们推出了 PTS HTTP 2 的反对，用户在 PTS 控制台创立场景之后，无需任何操作，在压测时会通过与服务端协商的后果来决定应用 HTTP 1.x 或者 HTTP 2 协定，以此来保障压测场景的真实性。

2、反对流媒体协定压测

随着这几年互联网直播类业务的衰亡，互联内容正在悄悄的产生天翻地覆的变动。从最后的电商直播、游戏直播，再到往年疫情的在线教育直播，基于流媒体内容，越来越多的直播模式也展示在了公众眼前。从技术的角度而言，不批准基于 HTTP 协定的后端服务，直播零碎是一种全新的零碎架构。如何能像模仿基于 HTTP 申请的用户行为一样模仿用户观看视频的场景，成了一个新的技术的难题。

首先咱们先看一张残缺的直播架构的模型图，咱们能够很分明地看到直播宏观上的架构模型图：

从图中，咱们能够清晰的看到直播类零碎的三个次要模块:

1. 推流端。
2. 流媒体服务端。
3. 播放端。

推流端次要的作用在于采集主播的音视频数据推送到流媒体服务端。而流媒体服务端的次要作用在于把推流端传递过去的数据转换成指定格局，同时推送到播放端不便不同播放端用户观看，当然目前云产商也流媒体服务端的一整套解决方案。而播放端简而言之就是拉取音视频进行播放，把相应的内容出现给用户。

能够看到，连贯这三个要害的模块的协定其实就是流媒体传输协定。而一般来说，一个流媒体服务端架构，并不需要强调协定一致性。目前支流的流媒体协定如下：

目前 PTS 曾经反对 RTMP/HLS 协定，如何下图，联合 PTS 流程编排能力可能实在的模仿用户观看不同视频的场景。再联合 PTS 施压引擎地区定制个性，能轻松模仿大型直播的用户行为，来保障直播业务稳定性。

3、反对 Websocket 协定压测

通过后面 HTTP 相干协定的剖析，大家能够看到 HTTP 协定是一种无状态的、无连贯的、单向的应用层协定，它采纳了申请 / 响应模型。在 HTTP 2 协定前，通信申请只能由客户端发动，服务端对申请做出应答解决。在 HTTP 2 协定未大规模铺开之前，这种通信模型有一个弊病就是无奈实现服务器被动向客户端发动音讯。

而在一些实时性的场景中，这弊病无奈满足用户需要。在 Websocket 之前，为了保障信息的实时性，通常用以下两种办法：

• Ajax 轮询。
• Long pull。

Ajax 轮询 的原理非常简单，让浏览器隔个几秒就发送一次申请，询问服务器是否有新信息；Long poll 原理跟 ajax 轮询相似，都是采纳轮询的形式，只不过采纳的是阻塞模型，客户端发动连贯后，如果没音讯，就始终不返回 Response 给客户端，直到有音讯才返回，返回完之后，客户端再次建设连贯，周而复始。

从下面能够看出这两种形式，其实都是在一直地建设 HTTP 连贯，而后期待服务端解决，实质上并没扭转申请 / 响应模型。Websocket 的呈现正是为了解决下面的问题，通过 Websocket 协定，当服务端 / 客户端建设连贯后，服务端就能够被动推送信息给客户端，以此保障音讯的实时性、以及升高性能开销。

实质上 Websocket 是基于 TCP 协定的全双工通信的协定，跟 HTTP 齐全是不同协定，但握手的过程依赖 HTTP 协定。仔细的同学如果通过抓包剖析的话，很容易找到以下报文内容：

GET /chat HTTP/1.1
Host: server.pts.console.aliyun.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: xxxxxxxxxxxxxxxxxxxx
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: https://pts.console.aliyun.com

能够看到每个建设一个 WebSocket 连贯时，在握手阶段都会发动 HTTP 申请。通过 HTTP 协定协定好 WebSocket 反对的版本号、协定的字版本号、原始地址，主机地址等内容给服务端。报文的要害中央在于，Upgrade 的首部，用于通知服务端把以后的 HTTP 申请降级到 WebSocket 协定，如果服务端反对，则返回的状态码必须是 101：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept:xxxxxxxxxxxxxxxxxxxx

有了上述返回，才 Websocket 连贯曾经建设，接下来就是齐全依照 Websocket 协定进行了数据传输了。

后面咱们提到，Websocket 是为了解决申请 / 响应模型的实习性问题而衍生的新协定。在理论利用过程中，咱们发现 Websocket 广泛应用于在线有戏、股票基金、体育实况更新、聊天室、弹幕、在线教育等实时性要求十分高的场景。

PTS 通过反对 Websocket 协定，让这些场景也可能像基于 HTTP 申请的测场景一样，通过性能压测来疾速验证零碎的性能、容量。

4、反对 MQTT 压测

MQTT 是 IBM 开发的一个即时通讯协定，数目前物联网的重要组成部分。该协定反对所有平台，简直能够把所有联网物品和内部连接起来，用来当做传感器和制动器的通信协议。

MQTT 协定自身不辨别客户端（终端）与服务器（云端），依照 MQTT 模型，所有客户端的通信都是通过 pub/sub 的形式，由一个 MQTT broker 的角色进行转发。理论 IoT 场景中的架构图大抵如下：

相比后面提到的 HTTP 协定，MQTT 具备如下个性:

• 低协定开销。基于二进制的传输协定，协定头部能够短至 2 个字节。
• 反对 Push 模式。
• 不稳固网络容忍度高。MQTT 协定原生反对 session 机制，链接断开后能主动复原，并确保音讯的品质。

联合以上几个个性，MQTT 十分符合目前炽热倒退的 IoT 畛域。联合近年来的数据来看，MQTT 协定的占比在 IoT 畛域占比正在逐步增大，甚至曾经超过了传统 HTTP 协定。

因此为了解决 IoT 场景的压测需要，PTS 专门推出了 MQTT 压测场景，反对对自建 MQTT 服务和阿里云微音讯队列 MQTT 版进行压测，如下图，在控制台即可疾速创立压测场景：

5、反对微服务相干协定（SpringCloud/Dubbo）压测

对于单体利用架构而言，随着业务的扩张，利用的部署和运维都会越来越慢、越来越简单，利用开发过程中麻利模式也无奈随着人员增多而施展开来。微服务架构就是用来解决上述问题的。

微服务架构从构造上来看，其实就是把一个利用提供的性能服务拆分成多个松耦合的服务，这些服务之间通过某种协定（RPC/HTTP 等）来进行互相调用，实现单体架构到分布式架构的转变，以提供更加灵便的开发、部署形式，升高开发、运维的复杂度。

以下图某个业务为案例，能够看到用户的申请通过 HTTP 协定进入到 store-web 利用后，会通过 RPC 的形式调用到 store-cart、store-product 等后端服务。

那么试想下一个场景，在微服务架构的体系下，如果咱们不从 store-web 发动流量，想要独自给 store-cart、store-product 等后端服务做压测，如果压测工具不反对微服务相干协定的话，是无奈独自为此场景做压测的；即便压测工具反对微服务局部协定，也须要将压测工具部署到微服务所在的 VPC 内能力压测，整个过程费时费力。

为了解决上述问题，PTS 推出了新的微服务压测能力，反对 SpringCloud/Dubbo 等支流微服务协定压测，同时内主动买通用户 VPC，不便疾速对微服务做性能压测。如下图：

施压能力降级

PTS 的前生是阿里巴巴的全链路压测。全链路压测诞生的初衷就是为了实在的模仿双十一零点全国用户涌向天猫购买商品的实在场景。在 13 年之前，压测基本上都是在线下环境进行模仿压测。线下模仿压测的长处在于实现绝对简略，危险低，并且也可能发现肯定的性能问题；而不足之处在于，调用场景跟线上实在的调用场景截然不同，数据和环境的真实性都得不到保障，因此无奈做精确的评估零碎性能。线下压测通常适应于用来测试单零碎是否用性能瓶颈，对于容量的计算参考价值不大，如果零碎要具备能抗住双十一零点峰值的能力，咱们须要一种更准确的压测模式来评估线上容量。

线上压测的概念早在 2010 年阿里外部就被提出来，通过单机引流的形式，使得咱们第一次具备在线上进行单机压测、准确获取单机性能极限的能力。而引流压测压测是基于单机的，对应的容量布局也是针对单个利用去评估。在大型分布式架构下，基于单利用计算容量的形式疏忽了整体调用关系和上下游依赖的影响, 咱们无奈评估从用户登录到实现购买的整个链条中，外围页面和交易领取的理论承载能力。此外，在机房、网络、中间件、存储等一系列环节同样充斥着各种不确定性。而全链路压测的呈现扭转了这一现状，全链路压测通过利用零碎革新使线上环境能够同时解决失常流量和测试流量，以反对线上不影响失常用户拜访的集群读写压测，取得最实在的线上理论承载能力数据。

明天，咱们再站在双十一的这个非凡的工夫点来回顾，每年双十一零点全国用户涌向通茂购买商品的场景，从技术的维度，背地是几千万级别的 HTTP 申请霎时达到零碎。之所以阿里的零碎可能抗住如此大规模的流量洪峰，跟双十一前的全链路压测预演密不可分。

PTS 站在全链路压测的肩膀上，把全链路压测海量流量施压能力、生产环境写压测两大能力做了产品化。通过 PTS 能够低成本的发动全国用户拜访业务量级的流量，同时能笼罩全副线上包含写申请的压测场景，最实在的模仿相似双十一流动的场景。

1、海量流量施压能力

面对日益增长的业务规模，置信很多的自建压测平台的用户都有一个懊恼，那就是如何发动超大型流动的流量。开源自建，环境保护老本高；自研引擎呈现施压机问题导致压力上不去。

如上图，PTS 按需流量发动能力，反对最大到 100W 级别并发自助压测。无论你是日常测试场景的小并发压测、还是须要模仿超大型流动的压测，点击发动流量即可，无需再为上述问题懊恼。

2、平安、无侵入的生产环境写压测能力产品化

后面提到，阿里的全链路压测是通过通过利用零碎革新使线上环境能够同时解决失常流量和测试流量，以反对线上不影响失常用户拜访的集群读写压测，取得最实在的线上理论承载能力数据。

而在生产环境做写压测挑战点，次要是两个方面；一个方面是要保障写压测的安全性，防止净化线上数据；另外一个方面是要尽可能防止侵入业务代码，让业务做过多革新。

联合阿里全链路压测多年的实践经验，咱们总结了保障生产环境写压测安全性前提：

1. 确保压测标记不失落。
   压测流量在任何环节可能被正确的辨认进去。在流量入口层带上压测标，中间件辨认并持续往下传递压测标，保障整条链路上压测标不失落，通过这种形式使得上游的利用和存储也能接管到压测标。
2. 确保压测流程不中断。
   压测流量可能失常的调用上来，整个流程不被阻断，返回合乎预期的业务后果。业务的应用层，要反对全链路也须要对应的革新，应用层在辨认到压测标时，须要绕过参数校验、平安校验等校验逻辑，例如手机号格局校验、用户状态校验、以及一些其它非凡业务校验逻辑。
3. 确保压测数据不净化。
   压测数据不对线上失常的业务造成数据净化。全链路场景往往蕴含多个读写场景，为了隔离压测数据，存储中间件辨认到压测标之后，将数据写入影子库表，与实在的数据辨别开。为了更加实在的模仿实在场景，影子库表中的根底数据（比方买家、卖家、商品、店铺等）是由实在数据加上固定偏移量结构而成，迁徙过程中会进行采样、过滤、脱敏等操作保障数据安全，个别在数据量级上和实在数据保持一致。

PTS 公布的生产环境写压测探针曾经具备以上三大能力。仅需将利用部署上探针，反对支流罕用的中间件，配置好对应的规定即可，无需改变任何业务代码。如下图，联合 PTS 施压能力，即可再须要的时候发动生产环境压测。

最初

上述能力是截止到云栖大会时 PTS 推出的新性能，对 PTS 感兴趣的同学欢送扫码进群交换。正值双十一狂欢，咱们不仅上线了 JMeter 的专属资源包，同时全线产品 88 折起，最低可到 0.99 元，欢送大家选购！

相干链接

• 阿里云 PTS
• https://pts.console.aliyun.com/#/overviewpage
• PTS 资源包购买
• https://common-buy.aliyun.com/?commodityCode=ptsbag#/buy

版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。