阿里云性能測試服務(wù)PTS新面貌 - 壓測協(xié)議、施壓能力全新升級

性能測試PTS（Performance Testing Service）是一款阿里云SaaS化的性能測試工具，從最早為了精準模擬雙十一流量洪峰誕生，到現(xiàn)在已經(jīng)走過了10個年頭。每年支持包括雙十一在內(nèi)的全集團范圍的幾萬次壓測任務(wù)，是阿里內(nèi)部雙十一技術(shù)架構(gòu)的"提前驗證者"。

作為SaaS化的性能壓測工具，PTS支持按需發(fā)起壓測任務(wù)，可提供百萬并發(fā)、千萬TPS流量發(fā)起能力。同時還能100%兼容JMeter。提供的場景編排、API調(diào)試、流量定制、流量錄制等功能，可快速創(chuàng)建業(yè)務(wù)壓測腳本，通過全國上百城市覆蓋各運營商節(jié)點，可精準模擬不同量級用戶訪問業(yè)務(wù)系統(tǒng)，幫助業(yè)務(wù)快速提升系統(tǒng)性能和穩(wěn)定性，已廣泛應(yīng)用在零售、金融、在線教育等多個領(lǐng)域。

今天PTS能力再次升級。壓測協(xié)議的升級，進一步擴大了壓測協(xié)議支持的范圍以及適用場景，讓您無需再為不同的技術(shù)架構(gòu)無法壓測煩惱；推出的低門檻的海量流量自助施壓能力，讓壓測工具團隊免去開發(fā)、運維的煩惱，點擊啟動壓測，輕松就具備百萬并發(fā)的自助壓測能力；安全、無侵入的生產(chǎn)環(huán)境寫壓測的產(chǎn)品化能力，只需簡單接入探針即可具備生產(chǎn)環(huán)境寫壓測能力，讓每一個業(yè)務(wù)場景在生產(chǎn)環(huán)境壓測時都不“掉隊”，更全面準確的評估系統(tǒng)性能、容量。

新發(fā)布/升級功能如下:

支持HTTP 2協(xié)議。

支持流媒體RTMP/HLS協(xié)議。

支持Websocket協(xié)議。

支持MQTT協(xié)議。

支持SpringCloud/Dubbo微服務(wù)協(xié)議。

最大100W并發(fā)自助壓測能力。

安全、無侵入的生產(chǎn)環(huán)境寫壓測。

壓測支持協(xié)議升級

協(xié)議作為應(yīng)用系統(tǒng)交流的“語言”，今天在面對多樣化的場景時，不同類型系統(tǒng)采用的協(xié)議正悄然發(fā)生改變。HTTP協(xié)議作為應(yīng)用最為廣泛傳輸協(xié)議，主要傳輸?shù)氖俏谋緝?nèi)容，承載了過去互聯(lián)網(wǎng)的主流流量。當我們今天面對多樣化富文本的內(nèi)容時，HTTP協(xié)議顯然不再是我們技術(shù)服務(wù)唯一的選擇了。流媒體相關(guān)協(xié)議承擔了你看視頻內(nèi)容的搬運工角色，看視頻的時候看敲下“YYDS”的跟服務(wù)端走的是Websocket協(xié)議，你手上戴的智能化手表、家里的智能電氣，沒準是通過MQTT協(xié)議跟云端的服務(wù)在保持著數(shù)據(jù)同步，哪怕你還是在瀏覽文本內(nèi)容，搬運工交流的服務(wù)協(xié)議也正從HTTP 1.1到HTTP 2、到HTTP 3等協(xié)議在發(fā)生轉(zhuǎn)變。

作為技術(shù)、開發(fā)、測試人員，在面對快速業(yè)務(wù)迭代的時候，要去理解每一個交互協(xié)議本身是個很頭痛的事情。壓測場景也同樣類似，我們顯然無法接受為每個系統(tǒng)定制一個壓測工具的成本。PTS作為壓測工具，在壓測支持協(xié)議方面，為大家?guī)砹巳律?，具體如下:

支持HTTP 2協(xié)議。

支持流媒體RTMP/HLS協(xié)議。

支持Websocket協(xié)議。

支持MQTT協(xié)議。

支持SpringCloud/Dubbo微服務(wù)協(xié)議。

1、支持HTTP 2壓測

距離1997年HTTP 1.X協(xié)議版本發(fā)布到現(xiàn)在，我們的系統(tǒng)使用HTTP 1.x提供內(nèi)容服務(wù)已經(jīng)有相當長一段時間了。近十年互聯(lián)網(wǎng)內(nèi)容、互聯(lián)網(wǎng)用戶數(shù)呈爆發(fā)式增長，HTTP 1.x已經(jīng)無法滿足現(xiàn)代網(wǎng)絡(luò)的需求，越來越多的公司也開始從原來的HTTP 1.X升級到HTTP 2，以換取更好的網(wǎng)頁加載性能、安全性。大家可以通過以下圖片感受HTTP 2協(xié)議帶來的性能提升。

HTTP 2相比于HTTP/1.1，主要的改進點包括以下幾點:

使用二進制傳輸。

Header壓縮。

多路復(fù)用。

Server Push。

提升安全性。

通過前面的效果圖可以看到，HTTP 2的性能明顯是要好于HTTP 1.x的。而提升性能的關(guān)鍵特性在于二進制傳輸、Header壓縮、以及多路復(fù)用幾個特性，下面來看下這三個特性的基本原理。

使用二進制傳輸

二進制協(xié)議相比純文本形式解析起來更高效，再HTTP 2.0中，把原來的傳輸內(nèi)容打散成Frame的方式，同域名下所有通信都在單個連接上完成，把原來報文的結(jié)構(gòu)做了打散，每個報文都又由一個或多個幀組成，多個幀之間可以亂序發(fā)送，根據(jù)幀首部的流標識可以重新組裝，如下圖所示：

Header壓縮

在HTTP 1.X中，由于無狀態(tài)的特性，導(dǎo)致大家發(fā)起請求的時候，經(jīng)常需要帶上一堆Header，很多請求的Header甚至比Body更大。Header內(nèi)容過大，在一定程度上增加了傳輸?shù)某杀?。如果某個域名下的成千上萬請求響應(yīng)報文里有很多字段值都是重復(fù)的話，非常浪費資源。

因而在二進制傳輸?shù)幕A(chǔ)上，HTTP 2協(xié)議增加了對Header的壓縮能力，通過HPACK壓縮算法，在客戶端和服務(wù)器兩端建立字典，用索引號表示重復(fù)的字符串，壓縮效率可以達到50%~90%。如下圖兩個請求所示，第一個請求發(fā)送了全部的Header，第二個請求則只需要發(fā)送差異數(shù)據(jù)即可，以此來提升效率:

多路復(fù)用

HTTP 2中支持多路復(fù)用技術(shù)，多路復(fù)用很好的解決了瀏覽器同一個域名下請求數(shù)量的限制問題，同時降低了每次新開TCP請求的開銷。在HTTP 2中，通過前面提到的二進制Frame的傳輸方式，并通過允許客戶端和服務(wù)器將HTTP消息分解為獨立的幀，然后在另一端重新組裝它們，從而實現(xiàn)完整的請求和響應(yīng)多路復(fù)用，如下圖，客戶端正在向服務(wù)器傳輸數(shù)據(jù)幀（Stream 5），而服務(wù)器正在向客戶端傳輸流1和3的交錯幀序列，有三個并行流在傳輸數(shù)據(jù)。

通過HTTP 2的二進制傳輸、以及多路復(fù)用技術(shù)，大家可以很好的看到以前瀏覽器對于同一個域名，TCP持久連接數(shù)限制必須共用TCP管控而導(dǎo)致的同一時刻一個管道中只能處理一個請求的Head-Of-Line Blocking，已經(jīng)不復(fù)存在了，這也是HTTP 2協(xié)議效率提升的根本。

理論上HTTP 2是兼容HTTP 1.x，如果客戶端不支持HTTP 2協(xié)議，服務(wù)端會自動使用HTTP 1.x協(xié)議進行通信。而在我們的性能壓測場景中，大家通過上述例子可以看到HTTP 2跟HTTP 1.x性能表現(xiàn)是不一致的，如果壓測引擎不支持HTTP 2，壓測時會直接降級成HTTP 1.x。在今天主流流浪器都支持HTTP 2協(xié)議的背景下，壓測的實際結(jié)果會產(chǎn)生偏差。

因而我們推出了PTS HTTP 2的支持，用戶在PTS控制臺創(chuàng)建場景之后，無需任何操作，在壓測時會通過與服務(wù)端協(xié)商的結(jié)果來決定使用HTTP 1.x或者HTTP 2協(xié)議，以此來保證壓測場景的真實性。

2、支持流媒體協(xié)議壓測

隨著這幾年互聯(lián)網(wǎng)直播類業(yè)務(wù)的興起，互聯(lián)內(nèi)容正在悄然的發(fā)生翻天覆地的變化。從最初的電商直播、游戲直播，再到今年疫情的在線教育直播，基于流媒體內(nèi)容，越來越多的直播形式也展現(xiàn)在了大眾眼前。從技術(shù)的角度而言，不同意基于HTTP協(xié)議的后端服務(wù)，直播系統(tǒng)是一種全新的系統(tǒng)架構(gòu)。如何能像模擬基于HTTP請求的用戶行為一樣模擬用戶觀看視頻的場景，成了一個新的技術(shù)的難題。

首先我們先看一張完整的直播架構(gòu)的模型圖，我們可以很清楚地看到直播宏觀上的架構(gòu)模型圖：

從圖中，我們可以清晰的看到直播類系統(tǒng)的三個主要模塊:

推流端。

流媒體服務(wù)端。

播放端。

推流端主要的作用在于采集主播的音視頻數(shù)據(jù)推送到流媒體服務(wù)端。而流媒體服務(wù)端的主要作用在于把推流端傳遞過來的數(shù)據(jù)轉(zhuǎn)換成指定格式，同時推送到播放端方便不同播放端用戶觀看，當然目前云產(chǎn)商也流媒體服務(wù)端的一整套解決方案。而播放端簡而言之就是拉取音視頻進行播放，把相應(yīng)的內(nèi)容呈現(xiàn)給用戶。

可以看到，連接這三個關(guān)鍵的模塊的協(xié)議其實就是流媒體傳輸協(xié)議。而一般來說，一個流媒體服務(wù)端架構(gòu)，并不需要強調(diào)協(xié)議一致性。目前主流的流媒體協(xié)議如下：

目前PTS已經(jīng)支持RTMP/HLS協(xié)議，如何下圖，結(jié)合PTS流程編排能力能夠真實的模擬用戶觀看不同視頻的場景。再結(jié)合PTS施壓引擎地域定制特性，能輕松模擬大型直播的用戶行為，來保障直播業(yè)務(wù)穩(wěn)定性。

3、支持Websocket協(xié)議壓測

通過前面HTTP相關(guān)協(xié)議的分析，大家可以看到HTTP協(xié)議是一種無狀態(tài)的、無連接的、單向的應(yīng)用層協(xié)議，它采用了請求/響應(yīng)模型。在HTTP 2協(xié)議前，通信請求只能由客戶端發(fā)起，服務(wù)端對請求做出應(yīng)答處理。在HTTP 2協(xié)議未大規(guī)模鋪開之前，這種通信模型有一個弊端就是無法實現(xiàn)服務(wù)器主動向客戶端發(fā)起消息。

而在一些實時性的場景中，這弊端無法滿足用戶需求。在Websocket之前，為了保證信息的實時性，通常用以下兩種方法：

Ajax輪詢。

Long pull。

Ajax輪詢的原理非常簡單，讓瀏覽器隔個幾秒就發(fā)送一次請求，詢問服務(wù)器是否有新信息；Long poll原理跟ajax輪詢類似，都是采用輪詢的方式，只不過采用的是阻塞模型，客戶端發(fā)起連接后，如果沒消息，就一直不返回Response給客戶端，直到有消息才返回，返回完之后，客戶端再次建立連接，周而復(fù)始。

從上面可以看出這兩種方式，其實都是在不斷地建立HTTP連接，然后等待服務(wù)端處理，本質(zhì)上并沒改變請求/響應(yīng)模型。Websocket的出現(xiàn)正是為了解決上面的問題，通過Websocket協(xié)議，當服務(wù)端/客戶端建立連接后，服務(wù)端就可以主動推送信息給客戶端，以此保證消息的實時性、以及降低性能開銷。

本質(zhì)上Websocket是基于TCP協(xié)議的全雙工通訊的協(xié)議，跟HTTP完全是不同協(xié)議，但握手的過程依賴HTTP協(xié)議。細心的同學(xué)如果通過抓包分析的話，很容易找到以下報文內(nèi)容：

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連接時，在握手階段都會發(fā)起HTTP請求。通過HTTP協(xié)議協(xié)定好WebSocket支持的版本號、協(xié)議的字版本號、原始地址，主機地址等內(nèi)容給服務(wù)端。報文的關(guān)鍵地方在于，Upgrade的首部，用于告訴服務(wù)端把當前的HTTP請求升級到WebSocket協(xié)議，如果服務(wù)端支持，則返回的狀態(tài)碼必須是101：

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

有了上述返回，才Websocket連接已經(jīng)建立，接下來就是完全按照Websocket協(xié)議進行了數(shù)據(jù)傳輸了。

前面我們提到，Websocket是為了解決請求/響應(yīng)模型的實習性問題而衍生的新協(xié)議。在實際應(yīng)用過程中，我們發(fā)現(xiàn)Websocket廣泛應(yīng)用于在線有戲、股票基金、體育實況更新、聊天室、彈幕、在線教育等實時性要求非常高的場景。

PTS通過支持Websocket協(xié)議，讓這些場景也能夠像基于HTTP請求的測場景一樣，通過性能壓測來快速驗證系統(tǒng)的性能、容量。

4、支持MQTT壓測

MQTT是IBM開發(fā)的一個即時通訊協(xié)議，數(shù)目前物聯(lián)網(wǎng)的重要組成部分。該協(xié)議支持所有平臺，幾乎可以把所有聯(lián)網(wǎng)物品和外部連接起來，用來當做傳感器和制動器的通信協(xié)議。

MQTT協(xié)議本身不區(qū)分客戶端（終端）與服務(wù)器（云端），按照MQTT模型，所有客戶端的通訊都是通過pub/sub的方式，由一個MQTT broker的角色進行轉(zhuǎn)發(fā)。實際IoT場景中的架構(gòu)圖大致如下：

相比前面提到的HTTP協(xié)議，MQTT具備如下特性:

低協(xié)議開銷?；诙M制的傳輸協(xié)議，協(xié)議頭部可以短至2個字節(jié)。

支持Push模式。

不穩(wěn)定網(wǎng)絡(luò)容忍度高。MQTT協(xié)議原生支持session機制，鏈接斷開后能自動恢復(fù)，并確保消息的質(zhì)量。

結(jié)合以上幾個特性，MQTT非常契合目前火熱發(fā)展的IoT領(lǐng)域。結(jié)合近年來的數(shù)據(jù)來看，MQTT協(xié)議的占比在IoT領(lǐng)域占比正在逐漸增大，甚至已經(jīng)超過了傳統(tǒng)HTTP協(xié)議。

因而為了解決IoT場景的壓測需求，PTS專門推出了MQTT壓測場景，支持對自建MQTT服務(wù)和阿里云微消息隊列MQTT版進行壓測，如下圖，在控制臺即可快速創(chuàng)建壓測場景：

5、支持微服務(wù)相關(guān)協(xié)議（SpringCloud/Dubbo）壓測

對于單體應(yīng)用架構(gòu)而言，隨著業(yè)務(wù)的擴張，應(yīng)用的部署和運維都會越來越慢、越來越復(fù)雜，應(yīng)用開發(fā)過程中敏捷模式也無法隨著人員增多而施展開來。微服務(wù)架構(gòu)就是用來解決上述問題的。

微服務(wù)架構(gòu)從結(jié)構(gòu)上來看，其實就是把一個應(yīng)用提供的功能服務(wù)拆分成多個松耦合的服務(wù)，這些服務(wù)之間通過某種協(xié)議（RPC/HTTP等）來進行相互調(diào)用，完成單體架構(gòu)到分布式架構(gòu)的轉(zhuǎn)變，以提供更加靈活的開發(fā)、部署方式，降低開發(fā)、運維的復(fù)雜度。

以下圖某個業(yè)務(wù)為案例，可以看到用戶的請求通過HTTP協(xié)議進入到store-web應(yīng)用后，會通過RPC的方式調(diào)用到store-cart、store-product等后端服務(wù)。

那么試想下一個場景，在微服務(wù)架構(gòu)的體系下，如果我們不從store-web發(fā)起流量，想要單獨給store-cart、store-product等后端服務(wù)做壓測，如果壓測工具不支持微服務(wù)相關(guān)協(xié)議的話，是無法單獨為此場景做壓測的；即使壓測工具支持微服務(wù)部分協(xié)議，也需要將壓測工具部署到微服務(wù)所在的VPC內(nèi)才能壓測，整個過程費時費力。

為了解決上述問題，PTS推出了新的微服務(wù)壓測能力，支持SpringCloud/Dubbo等主流微服務(wù)協(xié)議壓測，同時內(nèi)自動打通用戶VPC，方便快速對微服務(wù)做性能壓測。如下圖：

施壓能力升級

PTS的前生是阿里巴巴的全鏈路壓測。全鏈路壓測誕生的初衷就是為了真實的模擬雙十一零點全國用戶涌向天貓購買商品的真實場景。在13年之前，壓測基本上都是在線下環(huán)境進行模擬壓測。線下模擬壓測的優(yōu)點在于實現(xiàn)相對簡單，風險低，并且也能夠發(fā)現(xiàn)一定的性能問題；而不足之處在于，調(diào)用場景跟線上真實的調(diào)用場景截然不同，數(shù)據(jù)和環(huán)境的真實性都得不到保障，因而無法做準確的評估系統(tǒng)性能。線下壓測通常適應(yīng)于用來測試單系統(tǒng)是否用性能瓶頸，對于容量的計算參考價值不大，如果系統(tǒng)要具備能抗住雙十一零點峰值的能力，我們需要一種更精確的壓測模式來評估線上容量。

線上壓測的概念早在2010年阿里內(nèi)部就被提出來，通過單機引流的方式，使得我們第一次具備在線上進行單機壓測、精確獲取單機性能極限的能力。而引流壓測壓測是基于單機的，對應(yīng)的容量規(guī)劃也是針對單個應(yīng)用去評估。在大型分布式架構(gòu)下，基于單應(yīng)用計算容量的方式忽略了整體調(diào)用關(guān)系和上下游依賴的影響,我們無法評估從用戶登錄到完成購買的整個鏈條中，核心頁面和交易支付的實際承載能力。此外，在機房、網(wǎng)絡(luò)、中間件、存儲等一系列環(huán)節(jié)同樣充斥著各種不確定性。而全鏈路壓測的出現(xiàn)改變了這一現(xiàn)狀，全鏈路壓測通過應(yīng)用系統(tǒng)改造使線上環(huán)境可以同時處理正常流量和測試流量，以支持線上不影響正常用戶訪問的集群讀寫壓測，獲得最真實的線上實際承載能力數(shù)據(jù)。

今天，我們再站在雙十一的這個特殊的時間點來回顧，每年雙十一零點全國用戶涌向通茂購買商品的場景，從技術(shù)的維度，背后是幾千萬級別的HTTP請求瞬間到達系統(tǒng)。之所以阿里的系統(tǒng)能夠抗住如此大規(guī)模的流量洪峰，跟雙十一前的全鏈路壓測預(yù)演密不可分。

PTS站在全鏈路壓測的肩膀上，把全鏈路壓測海量流量施壓能力、生產(chǎn)環(huán)境寫壓測兩大能力做了產(chǎn)品化。通過PTS可以低成本的發(fā)起全國用戶訪問業(yè)務(wù)量級的流量，同時能覆蓋全部線上包括寫請求的壓測場景，最真實的模擬類似雙十一活動的場景。

1、海量流量施壓能力

面對日益增長的業(yè)務(wù)規(guī)模，相信很多的自建壓測平臺的用戶都有一個煩惱，那就是如何發(fā)起超大型活動的流量。開源自建，環(huán)境維護成本高；自研引擎出現(xiàn)施壓機問題導(dǎo)致壓力上不去。

如上圖，PTS按需流量發(fā)起能力，支持最大到100W級別并發(fā)自助壓測。無論你是日常測試場景的小并發(fā)壓測、還是需要模擬超大型活動的壓測，點擊發(fā)起流量即可，無需再為上述問題煩惱。

2、安全、無侵入的生產(chǎn)環(huán)境寫壓測能力產(chǎn)品化

前面提到，阿里的全鏈路壓測是通過通過應(yīng)用系統(tǒng)改造使線上環(huán)境可以同時處理正常流量和測試流量，以支持線上不影響正常用戶訪問的集群讀寫壓測，獲得最真實的線上實際承載能力數(shù)據(jù)。

而在生產(chǎn)環(huán)境做寫壓測挑戰(zhàn)點，主要是兩個方面；一個方面是要保證寫壓測的安全性，避免污染線上數(shù)據(jù)；另外一個方面是要盡可能避免侵入業(yè)務(wù)代碼，讓業(yè)務(wù)做過多改造。

結(jié)合阿里全鏈路壓測多年的實踐經(jīng)驗，我們總結(jié)了保證生產(chǎn)環(huán)境寫壓測安全性前提：

確保壓測標記不丟失。

壓測流量在任何環(huán)節(jié)能夠被正確的識別出來。在流量入口層帶上壓測標，中間件識別并繼續(xù)往下傳遞壓測標，保證整條鏈路上壓測標不丟失，通過這種方式使得下游的應(yīng)用和存儲也能接收到壓測標。

確保壓測流程不中斷。

壓測流量能夠正常的調(diào)用下去，整個流程不被阻斷，返回符合預(yù)期的業(yè)務(wù)結(jié)果。業(yè)務(wù)的應(yīng)用層，要支持全鏈路也需要對應(yīng)的改造，應(yīng)用層在識別到壓測標時，需要繞過參數(shù)校驗、安全校驗等校驗邏輯，例如手機號格式校驗、用戶狀態(tài)校驗、以及一些其它特殊業(yè)務(wù)校驗邏輯。

確保壓測數(shù)據(jù)不污染。

壓測數(shù)據(jù)不對線上正常的業(yè)務(wù)造成數(shù)據(jù)污染。全鏈路場景往往包含多個讀寫場景，為了隔離壓測數(shù)據(jù)，存儲中間件識別到壓測標之后，將數(shù)據(jù)寫入影子庫表，與真實的數(shù)據(jù)區(qū)分開。為了更加真實的模擬真實場景，影子庫表中的基礎(chǔ)數(shù)據(jù)（比如買家、賣家、商品、店鋪等）是由真實數(shù)據(jù)加上固定偏移量構(gòu)造而成，遷移過程中會進行采樣、過濾、脫敏等操作保證數(shù)據(jù)安全，一般在數(shù)據(jù)量級上和真實數(shù)據(jù)保持一致。

PTS發(fā)布的生產(chǎn)環(huán)境寫壓測探針已經(jīng)具備以上三大能力。僅需將應(yīng)用部署上探針，支持主流常用的中間件，配置好對應(yīng)的規(guī)則即可，無需改動任何業(yè)務(wù)代碼。如下圖，結(jié)合PTS施壓能力，即可再需要的時候發(fā)起生產(chǎn)環(huán)境壓測。