阿里云性能测试服务 PTS 新面貌 - 压测协议、施压能力全新升级

2021 年 11 月 09 日
本文字数：6895 字
阅读完需：约 23 分钟

作者：笛墨审核 &校对：风云编辑 &排版：雯燕

引言

性能测试 PTS（Performance Testing Service）是一款阿里云 SaaS 化的性能测试工具，从最早为了精准模拟双十一流量洪峰诞生，到现在已经走过了 10 个年头。每年支持包括双十一在内的全集团范围的几万次压测任务，是阿里内部双十一技术架构的"提前验证者"。

作为 SaaS 化的性能压测工具，PTS 支持按需发起压测任务，可提供百万并发、千万 TPS 流量发起能力。同时还能 100% 兼容 JMeter。提供的场景编排、API 调试、流量定制、流量录制等功能，可快速创建业务压测脚本，通过全国上百城市覆盖各运营商节点，可精准模拟不同量级用户访问业务系统，帮助业务快速提升系统性能和稳定性，已广泛应用在零售、金融、在线教育等多个领域。

今天 PTS 能力再次升级。压测协议的升级，进一步扩大了压测协议支持的范围以及适用场景，让您无需再为不同的技术架构无法压测烦恼；推出的低门槛的海量流量自助施压能力，让压测工具团队免去开发、运维的烦恼，点击启动压测，轻松就具备百万并发的自助压测能力；安全、无侵入的生产环境写压测的产品化能力，只需简单接入探针即可具备生产环境写压测能力，让每一个业务场景在生产环境压测时都不“掉队”，更全面准确的评估系统性能、容量。

新发布/升级功能如下:

支持 HTTP 2 协议。
支持流媒体 RTMP/HLS 协议。
支持 Websocket 协议。
支持 MQTT 协议。
支持 SpringCloud/Dubbo 微服务协议。
最大 100W 并发自助压测能力。
安全、无侵入的生产环境写压测。

压测支持协议升级

协议作为应用系统交流的“语言”，今天在面对多样化的场景时，不同类型系统采用的协议正悄然发生改变。HTTP 协议作为应用最为广泛传输协议，主要传输的是文本内容，承载了过去互联网的主流流量。当我们今天面对多样化富文本的内容时，HTTP 协议显然不再是我们技术服务唯一的选择了。流媒体相关协议承担了你看视频内容的搬运工角色，看视频的时候看敲下“YYDS”的跟服务端走的是 Websocket 协议，你手上戴的智能化手表、家里的智能电气，没准是通过 MQTT 协议跟云端的服务在保持着数据同步，哪怕你还是在浏览文本内容，搬运工交流的服务协议也正从 HTTP 1.1 到 HTTP 2、到 HTTP 3 等协议在发生转变。

作为技术、开发、测试人员，在面对快速业务迭代的时候，要去理解每一个交互协议本身是个很头痛的事情。压测场景也同样类似，我们显然无法接受为每个系统定制一个压测工具的成本。PTS 作为压测工具，在压测支持协议方面，为大家带来了全新升级，具体如下:

支持 HTTP 2 协议。
支持流媒体 RTMP/HLS 协议。
支持 Websocket 协议。
支持 MQTT 协议。
支持 SpringCloud/Dubbo 微服务协议。

支持 HTTP 2 压测

距离 1997 年 HTTP 1.X 协议版本发布到现在，我们的系统使用 HTTP 1.x 提供内容服务已经有相当长一段时间了。近十年互联网内容、互联网用户数呈爆发式增长，HTTP 1.x 已经无法满足现代网络的需求，越来越多的公司也开始从原来的 HTTP 1.X 升级到 HTTP 2，以换取更好的网页加载性能、安全性。大家可以通过以下图片感受 HTTP 2 协议带来的性能提升。

HTTP 2 相比于 HTTP/1.1，主要的改进点包括以下几点:

使用二进制传输。
Header 压缩。
多路复用。
Server Push。
提升安全性。

通过前面的效果图可以看到，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 协议，以此来保证压测场景的真实性。

支持流媒体协议压测

随着这几年互联网直播类业务的兴起，互联内容正在悄然的发生翻天覆地的变化。从最初的电商直播、游戏直播，再到今年疫情的在线教育直播，基于流媒体内容，越来越多的直播形式也展现在了大众眼前。从技术的角度而言，不同意基于 HTTP 协议的后端服务，直播系统是一种全新的系统架构。如何能像模拟基于 HTTP 请求的用户行为一样模拟用户观看视频的场景，成了一个新的技术的难题。

首先我们先看一张完整的直播架构的模型图，我们可以很清楚地看到直播宏观上的架构模型图：

从图中，我们可以清晰的看到直播类系统的三个主要模块:

推流端。
流媒体服务端。
播放端。

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

可以看到，连接这三个关键的模块的协议其实就是流媒体传输协议。而一般来说，一个流媒体服务端架构，并不需要强调协议一致性。目前主流的流媒体协议如下：

目前 PTS 已经支持 RTMP/HLS 协议，如何下图，结合 PTS 流程编排能力能够真实的模拟用户观看不同视频的场景。再结合 PTS 施压引擎地域定制特性，能轻松模拟大型直播的用户行为，来保障直播业务稳定性。

支持 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.1Host: server.pts.console.aliyun.comUpgrade: websocketConnection: UpgradeSec-WebSocket-Key: xxxxxxxxxxxxxxxxxxxxSec-WebSocket-Protocol: chat, superchatSec-WebSocket-Version: 13Origin: https://pts.console.aliyun.com

复制代码

可以看到每个建立一个 WebSocket 连接时，在握手阶段都会发起 HTTP 请求。通过 HTTP 协议协定好 WebSocket 支持的版本号、协议的字版本号、原始地址，主机地址等内容给服务端。报文的关键地方在于，Upgrade 的首部，用于告诉服务端把当前的 HTTP 请求升级到 WebSocket 协议，如果服务端支持，则返回的状态码必须是 101：

HTTP/1.1 101 Switching ProtocolsUpgrade: websocketConnection: UpgradeSec-WebSocket-Accept:xxxxxxxxxxxxxxxxxxxx

复制代码

有了上述返回，才 Websocket 连接已经建立，接下来就是完全按照 Websocket 协议进行了数据传输了。

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

PTS 通过支持 Websocket 协议，让这些场景也能够像基于 HTTP 请求的测场景一样，通过性能压测来快速验证系统的性能、容量。

支持 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 版进行压测，如下图，在控制台即可快速创建压测场景：

支持微服务相关协议（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 可以低成本的发起全国用户访问业务量级的流量，同时能覆盖全部线上包括写请求的压测场景，最真实的模拟类似双十一活动的场景。

海量流量施压能力

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

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

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

前面提到，阿里的全链路压测是通过通过应用系统改造使线上环境可以同时处理正常流量和测试流量，以支持线上不影响正常用户访问的集群读写压测，获得最真实的线上实际承载能力数据。

而在生产环境做写压测挑战点，主要是两个方面；一个方面是要保证写压测的安全性，避免污染线上数据；另外一个方面是要尽可能避免侵入业务代码，让业务做过多改造。

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

确保压测标记不丢失。压测流量在任何环节能够被正确的识别出来。在流量入口层带上压测标，中间件识别并继续往下传递压测标，保证整条链路上压测标不丢失，通过这种方式使得下游的应用和存储也能接收到压测标。
确保压测流程不中断。压测流量能够正常的调用下去，整个流程不被阻断，返回符合预期的业务结果。业务的应用层，要支持全链路也需要对应的改造，应用层在识别到压测标时，需要绕过参数校验、安全校验等校验逻辑，例如手机号格式校验、用户状态校验、以及一些其它特殊业务校验逻辑。
确保压测数据不污染。压测数据不对线上正常的业务造成数据污染。全链路场景往往包含多个读写场景，为了隔离压测数据，存储中间件识别到压测标之后，将数据写入影子库表，与真实的数据区分开。为了更加真实的模拟真实场景，影子库表中的基础数据（比如买家、卖家、商品、店铺等）是由真实数据加上固定偏移量构造而成，迁移过程中会进行采样、过滤、脱敏等操作保证数据安全，一般在数据量级上和真实数据保持一致。

PTS 发布的生产环境写压测探针已经具备以上三大能力。仅需将应用部署上探针，支持主流常用的中间件，配置好对应的规则即可，无需改动任何业务代码。如下图，结合 PTS 施压能力，即可再需要的时候发起生产环境压测。