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

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

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

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

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

支持HTTP 2協(xié)議。

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

支持Websocket協(xié)議。

支持MQTT協(xié)議。

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

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

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

壓測(cè)支持協(xié)議升級(jí)

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

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

支持HTTP 2協(xié)議。

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

支持Websocket協(xié)議。

支持MQTT協(xié)議。

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

1、支持HTTP 2壓測(cè)

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

HTTP 2相比于HTTP/1.1，主要的改進(jìn)點(diǎn)包括以下幾點(diǎn):

使用二進(jìn)制傳輸。

Header壓縮。

多路復(fù)用。

Server Push。

提升安全性。

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

使用二進(jìn)制傳輸

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

Header壓縮

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

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

多路復(fù)用

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

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

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

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

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

隨著這幾年互聯(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請(qǐng)求的用戶行為一樣模擬用戶觀看視頻的場(chǎng)景，成了一個(gè)新的技術(shù)的難題。

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

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

推流端。

流媒體服務(wù)端。

播放端。

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

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

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

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

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

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

Ajax輪詢。

Long pull。

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

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

本質(zhì)上Websocket是基于TCP協(xié)議的全雙工通訊的協(xié)議，跟HTTP完全是不同協(xié)議，但握手的過程依賴HTTP協(xié)議。細(xì)心的同學(xué)如果通過抓包分析的話，很容易找到以下報(bào)文內(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

可以看到每個(gè)建立一個(gè)WebSocket連接時(shí)，在握手階段都會(huì)發(fā)起HTTP請(qǐng)求。通過HTTP協(xié)議協(xié)定好WebSocket支持的版本號(hào)、協(xié)議的字版本號(hào)、原始地址，主機(jī)地址等內(nèi)容給服務(wù)端。報(bào)文的關(guān)鍵地方在于，Upgrade的首部，用于告訴服務(wù)端把當(dāng)前的HTTP請(qǐng)求升級(jí)到WebSocket協(xié)議，如果服務(wù)端支持，則返回的狀態(tài)碼必須是101：

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

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

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

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

4、支持MQTT壓測(cè)

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

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

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

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

支持Push模式。

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

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

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

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

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

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

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

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

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

施壓能力升級(jí)

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

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

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

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

1、海量流量施壓能力

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

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

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

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

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

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

確保壓測(cè)標(biāo)記不丟失。

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

確保壓測(cè)流程不中斷。

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

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

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

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