作者：笛墨
審核&校對：風云
編輯&排版：雯燕

引言

性能測試 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
https://pts.console.aliyun.com/#/overviewpage

PTS資源包購買
https://common-buy.aliyun.com/?commodityCode=ptsbag#/buy

釘釘掃碼，加入 PTS 用戶交流群

了解更多相關信息，請搜索微信號（AlibabaCloud888）添加云原生小助手！獲取更多相關資訊！

總結

以上是生活随笔為你收集整理的阿里云性能测试服务 PTS 新面貌 - 压测协议、施压能力全新升级的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。