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

引言

功用测验 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.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 恳求的测场景一样，经过功用压测来快速验证体系的功用、容量。

支撑 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 施压才干，即可再需求的时分建议出产环境压测。

最后

上述才干是截止到云栖大会时 PTS 推出的新功用，对 PTS 感兴趣的同学欢迎扫码进群沟通。正值双十一狂欢，咱们不只上线了 JMeter 的专属资源包，一起全线产品 88 折起，最低可到 0.99 元，欢迎咱们选购！

相关链接

阿里云PTS pts.console.aliyun.com/#/overviewp…

PTS资源包购买 common-buy.aliyun.com/?commodityC…

钉钉扫码，加入 PTS 用户沟通群

了解更多相关信息，请搜索微信号（AlibabaCloud888）添加云原生小助手！获取更多相关资讯！

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

引言