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

# 引言

效能測試 PTS（Performance Testing Service）是一款阿里雲 SaaS 化的效能測試工具，從最早為了精準模擬雙十一流量洪峰誕生，到現在已經走過了 10 個年頭。每年支援包括雙十一在內的全集團範圍的幾萬次壓測任務，是阿里內部雙十一技術架構的"提前驗證者"。

作為 SaaS 化的效能壓測工具，PTS 支援按需發起壓測任務，可提供百萬併發、千萬 TPS 流量發起能力。同時還能 100% 相容 JMeter。提供的場景編排、API 除錯、流量定製、流量錄製等功能，可快速建立業務壓測指令碼，透過全國上百城市覆蓋各運營商節點，可精準模擬不同量級使用者訪問業務系統，幫助業務快速提升系統效能和穩定性，已廣泛應用在零售、金融、線上教育等多個領域。

今天 PTS 能力再次升級。壓測協議的升級，進一步擴大了壓測協議支援的範圍以及適用場景，讓您無需再為不同的技術架構無法壓測煩惱；推出的低門檻的海量流量自助施壓能力，讓壓測工具團隊免去開發、運維的煩惱，點選啟動壓測，輕鬆就具備百萬併發的自助壓測能力；安全、無侵入的生產環境寫壓測的產品化能力，只需簡單接入探針即可具備生產環境寫壓測能力，讓每一個業務場景在生產環境壓測時都不“掉隊”，更全面準確的評估系統效能、容量。

新發布/升級功能如下:

1. 支援 HTTP 2 協議。
2. 支援流媒體 RTMP/HLS 協議。
3. 支援 Websocket 協議。
4. 支援 MQTT 協議。
5. 支援 SpringCloud/Dubbo 微服務協議。
6. 最大 100W 併發自助壓測能力。
7. 安全、無侵入的生產環境寫壓測。

# 壓測支援協議升級

協議作為應用系統交流的“語言”，今天在面對多樣化的場景時，不同型別系統採用的協議正悄然發生改變。HTTP 協議作為應用最為廣泛傳輸協議，主要傳輸的是文字內容，承載了過去網際網路的主流流量。當我們今天面對多樣化富文字的內容時，HTTP 協議顯然不再是我們技術服務唯一的選擇了。流媒體相關協議承擔了你看影片內容的搬運工角色，看影片的時候看敲下“YYDS”的跟服務端走的是 Websocket 協議，你手上戴的智慧化手錶、家裡的智慧電氣，沒準是透過 MQTT 協議跟雲端的服務在保持著資料同步，哪怕你還是在瀏覽文字內容，搬運工交流的服務協議也正從 HTTP 1.1 到 HTTP 2、到HTTP 3 等協議在發生轉變。

作為技術、開發、測試人員，在面對快速業務迭代的時候，要去理解每一個互動協議本身是個很頭痛的事情。壓測場景也同樣類似，我們顯然無法接受為每個系統定製一個壓測工具的成本。PTS 作為壓測工具，在壓測支援協議方面，為大家帶來了全新升級，具體如下:

- 支援 HTTP 2 協議。
- 支援流媒體 RTMP/HLS 協議。
- 支援 Websocket 協議。
- 支援 MQTT 協議。
- 支援 SpringCloud/Dubbo 微服務協議。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/99e59f6820814370b4bcd4e9d6ea51e6~tplv-k3u1fbpfcp-zoom-1.image)

### 支援 HTTP 2 壓測

距離 1997 年 HTTP 1.X 協議版本釋出到現在，我們的系統使用 HTTP 1.x 提供內容服務已經有相當長一段時間了。近十年網際網路內容、網際網路使用者數呈爆發式增長，HTTP 1.x 已經無法滿足現代網路的需求，越來越多的公司也開始從原來的 HTTP 1.X 升級到 HTTP 2，以換取更好的網頁載入效能、安全性。大家可以透過以下圖片感受 HTTP 2 協議帶來的效能提升。

![2.gif](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0f98c0acbe7c410ea55030dc744aa020~tplv-k3u1fbpfcp-zoom-1.image)

HTTP 2 相比於 HTTP/1.1，主要的改進點包括以下幾點:
 
1. 使用二進位制傳輸。
2. Header 壓縮。
3. 多路複用。
4. Server Push。
5. 提升安全性。

透過前面的效果圖可以看到，HTTP 2 的效能明顯是要好於 HTTP 1.x 的。而提升效能的關鍵特性在於二進位制傳輸、Header 壓縮、以及多路複用幾個特性，下面來看下這三個特性的基本原理。

#### 使用二進位制傳輸

二進位制協議相比純文字形式解析起來更高效，再 HTTP 2.0 中，把原來的傳輸內容打散成 Frame 的方式，同域名下所有通訊都在單個連線上完成，把原來報文的結構做了打散，每個報文都又由一個或多個幀組成，多個幀之間可以亂序傳送，根據幀首部的流標識可以重新組裝，如下圖所示：

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4e03831f5c7240008ff06594eecd00d5~tplv-k3u1fbpfcp-zoom-1.image)

#### Header 壓縮

在 HTTP 1.X 中，由於無狀態的特性，導致大家發起請求的時候，經常需要帶上一堆 Header，很多請求的 Header 甚至比 Body 更大。Header 內容過大，在一定程度上增加了傳輸的成本。如果某個域名下的成千上萬請求響應報文裡有很多欄位值都是重複的話，非常浪費資源。

因而在二進位制傳輸的基礎上，HTTP 2 協議增加了對 Header 的壓縮能力，透過 HPACK 壓縮演算法，在客戶端和伺服器兩端建立字典，用索引號表示重複的字串，壓縮效率可以達到 50%~90%。如下圖兩個請求所示，第一個請求傳送了全部的 Header，第二個請求則只需要傳送差異資料即可，以此來提升效率:

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/cb5e4b52cd5541aa843ca32bf0cfddba~tplv-k3u1fbpfcp-zoom-1.image)

#### 多路複用

HTTP 2 中支援多路複用技術，多路複用很好的解決了瀏覽器同一個域名下請求數量的限制問題，同時降低了每次新開 TCP 請求的開銷。在HTTP 2中，透過前面提到的二進位制 Frame 的傳輸方式，並透過允許客戶端和伺服器將 HTTP 訊息分解為獨立的幀，然後在另一端重新組裝它們，從而實現完整的請求和響應多路複用，如下圖，客戶端正在向伺服器傳輸資料幀（Stream 5），而伺服器正在向客戶端傳輸流 1 和 3 的交錯幀序列，有三個並行流在傳輸資料。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5962d3649ceb41d093fa8aa0375e29a3~tplv-k3u1fbpfcp-zoom-1.image)

透過 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 請求的使用者行為一樣模擬使用者觀看影片的場景，成了一個新的技術的難題。

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

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f158d623e40b445c89cb7d3ad23f94d6~tplv-k3u1fbpfcp-zoom-1.image)

從圖中，我們可以清晰的看到直播類系統的三個主要模組:

1. 推流端。
2. 流媒體服務端。
3. 播放端。

推流端主要的作用在於採集主播的音影片資料推送到流媒體服務端。而流媒體服務端的主要作用在於把推流端傳遞過來的資料轉換成指定格式，同時推送到播放端方便不同播放端使用者觀看，當然目前雲產商也流媒體服務端的一整套解決方案。而播放端簡而言之就是拉取音影片進行播放，把相應的內容呈現給使用者。

可以看到，連線這三個關鍵的模組的協議其實就是流媒體傳輸協議。而一般來說，一個流媒體服務端架構，並不需要強調協議一致性。目前主流的流媒體協議如下：

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4b3805c1c0674e4c988ebc832fa73bc3~tplv-k3u1fbpfcp-zoom-1.image)

目前 PTS 已經支援 RTMP/HLS 協議，如何下圖，結合 PTS 流程編排能力能夠真實的模擬使用者觀看不同影片的場景。再結合 PTS 施壓引擎地域定製特性，能輕鬆模擬大型直播的使用者行為，來保障直播業務穩定性。

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c8f4789b24374b3ca7b9315250d16627~tplv-k3u1fbpfcp-zoom-1.image)

### 支援 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 請求的測場景一樣，透過效能壓測來快速驗證系統的效能、容量。

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f53e5ac871ce4ab692e7820611f9bb71~tplv-k3u1fbpfcp-zoom-1.image)

### 支援 MQTT 壓測

MQTT 是 IBM 開發的一個即時通訊協議，數目前物聯網的重要組成部分。該協議支援所有平臺，幾乎可以把所有聯網物品和外部連線起來，用來當做感測器和制動器的通訊協議。

MQTT 協議本身不區分客戶端（終端）與伺服器（雲端），按照 MQTT 模型，所有客戶端的通訊都是透過 pub/sub 的方式，由一個 MQTT broker 的角色進行轉發。實際 IoT 場景中的架構圖大致如下：

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6341ac19be5a4127837a17f2cb007208~tplv-k3u1fbpfcp-zoom-1.image)

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

- 低協議開銷。基於二進位制的傳輸協議，協議頭部可以短至 2 個位元組。
- 支援 Push 模式。
- 不穩定網路容忍度高。MQTT 協議原生支援 session 機制，連結斷開後能自動恢復，並確保訊息的質量。

結合以上幾個特性，MQTT 非常契合目前火熱發展的IoT領域。結合近年來的資料來看，MQTT 協議的佔比在 IoT 領域佔比正在逐漸增大，甚至已經超過了傳統 HTTP 協議。

因而為了解決 IoT 場景的壓測需求，PTS 專門推出了 MQTT 壓測場景，支援對自建 MQTT 服務和阿里雲微訊息佇列 MQTT 版進行壓測，如下圖，在控制檯即可快速建立壓測場景：

![11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2a4c177ad25940cf8da5340118905ea6~tplv-k3u1fbpfcp-zoom-1.image)

### 支援微服務相關協議（SpringCloud/Dubbo）壓測

對於單體應用架構而言，隨著業務的擴張，應用的部署和運維都會越來越慢、越來越複雜，應用開發過程中敏捷模式也無法隨著人員增多而施展開來。微服務架構就是用來解決上述問題的。

微服務架構從結構上來看，其實就是把一個應用提供的功能服務拆分成多個松耦合的服務，這些服務之間透過某種協議（RPC/HTTP等）來進行相互呼叫，完成單體架構到分散式架構的轉變，以提供更加靈活的開發、部署方式，降低開發、運維的複雜度。

以下圖某個業務為案例，可以看到使用者的請求透過 HTTP 協議進入到 store-web 應用後，會透過 RPC 的方式呼叫到 store-cart、store-product 等後端服務。

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c83fae318424465184efc2c5d90f553a~tplv-k3u1fbpfcp-zoom-1.image)

那麼試想下一個場景，在微服務架構的體系下，如果我們不從 store-web 發起流量，想要單獨給 store-cart、store-product 等後端服務做壓測，如果壓測工具不支援微服務相關協議的話，是無法單獨為此場景做壓測的；即使壓測工具支援微服務部分協議，也需要將壓測工具部署到微服務所在的 VPC 內才能壓測，整個過程費時費力。

為了解決上述問題，PTS 推出了新的微服務壓測能力，支援 SpringCloud/Dubbo 等主流微服務協議壓測，同時內自動打通使用者 VPC，方便快速對微服務做效能壓測。如下圖：

![13.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7a92802c00a54ba1b3150ef587f6a35a~tplv-k3u1fbpfcp-zoom-1.image)

# 施壓能力升級

PTS 的前生是阿里巴巴的全鏈路壓測。全鏈路壓測誕生的初衷就是為了真實的模擬雙十一零點全國使用者湧向天貓購買商品的真實場景。在 13 年之前，壓測基本上都是線上下環境進行模擬壓測。線下模擬壓測的優點在於實現相對簡單，風險低，並且也能夠發現一定的效能問題；而不足之處在於，呼叫場景跟線上真實的呼叫場景截然不同，資料和環境的真實性都得不到保障，因而無法做準確的評估系統效能。線下壓測通常適應於用來測試單系統是否用效能瓶頸，對於容量的計算參考價值不大，如果系統要具備能抗住雙十一零點峰值的能力，我們需要一種更精確的壓測模式來評估線上容量。

線上壓測的概念早在 2010 年阿里內部就被提出來，透過單機引流的方式，使得我們第一次具備線上上進行單機壓測、精確獲取單機效能極限的能力。而引流壓測壓測是基於單機的，對應的容量規劃也是針對單個應用去評估。在大型分散式架構下，基於單應用計算容量的方式忽略了整體呼叫關係和上下游依賴的影響, 我們無法評估從使用者登入到完成購買的整個鏈條中，核心頁面和交易支付的實際承載能力。此外，在機房、網路、中介軟體、儲存等一系列環節同樣充斥著各種不確定性。而全鏈路壓測的出現改變了這一現狀，全鏈路壓測透過應用系統改造使線上環境可以同時處理正常流量和測試流量，以支援線上不影響正常使用者訪問的叢集讀寫壓測，獲得最真實的線上實際承載能力資料。

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

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

### 海量流量施壓能力

面對日益增長的業務規模，相信很多的自建壓測平臺的使用者都有一個煩惱，那就是如何發起超大型活動的流量。開源自建，環境維護成本高；自研引擎出現施壓機問題導致壓力上不去。

![14.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1d2a7536628049418989fe71490af248~tplv-k3u1fbpfcp-zoom-1.image)

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

### 安全、無侵入的生產環境寫壓測能力產品化

前面提到，阿里的全鏈路壓測是透過透過應用系統改造使線上環境可以同時處理正常流量和測試流量，以支援線上不影響正常使用者訪問的叢集讀寫壓測，獲得最真實的線上實際承載能力資料。

而在生產環境做寫壓測挑戰點，主要是兩個方面；一個方面是要保證寫壓測的安全性，避免汙染線上資料；另外一個方面是要儘可能避免侵入業務程式碼，讓業務做過多改造。

結合阿里全鏈路壓測多年的實踐經驗，我們總結了保證生產環境寫壓測安全性前提：

1. 確保壓測標記不丟失。
壓測流量在任何環節能夠被正確的識別出來。在流量入口層帶上壓測標，中介軟體識別並繼續往下傳遞壓測標，保證整條鏈路上壓測標不丟失，透過這種方式使得下游的應用和儲存也能接收到壓測標。

2. 確保壓測流程不中斷。
壓測流量能夠正常的呼叫下去，整個流程不被阻斷，返回符合預期的業務結果。業務的應用層，要支援全鏈路也需要對應的改造，應用層在識別到壓測標時，需要繞過引數校驗、安全校驗等校驗邏輯，例如手機號格式校驗、使用者狀態校驗、以及一些其它特殊業務校驗邏輯。

3. 確保壓測資料不汙染。
壓測資料不對線上正常的業務造成資料汙染。全鏈路場景往往包含多個讀寫場景，為了隔離壓測資料，儲存中介軟體識別到壓測標之後，將資料寫入影子庫表，與真實的資料區分開。為了更加真實的模擬真實場景，影子庫表中的基礎資料（比如買家、賣家、商品、店鋪等）是由真實資料加上固定偏移量構造而成，遷移過程中會進行取樣、過濾、脫敏等操作保證資料安全，一般在資料量級上和真實資料保持一致。

PTS 釋出的生產環境寫壓測探針已經具備以上三大能力。僅需將應用部署上探針，支援主流常用的中介軟體，配置好對應的規則即可，無需改動任何業務程式碼。如下圖，結合PTS 施壓能力，即可再需要的時候發起生產環境壓測。

![15.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6d226358366c4ed982d0e9a4c500c1da~tplv-k3u1fbpfcp-zoom-1.image)

# 最後

上述能力是截止到雲棲大會時 PTS 推出的新功能，對 PTS 感興趣的同學歡迎掃碼進群開始交流。正值雙十一狂歡，我們不僅上線了 JMeter 的專屬資源包，同時全線產品 88 折起，最低可到 0.99 元，歡迎大家選購！

![16.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8b7a5081186d427389b7a2207d464164~tplv-k3u1fbpfcp-zoom-1.image)

*相關連結*

*阿里雲PTS
https://pts.console.aliyun.com/#/overviewpage*

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

釘釘掃碼，加入 PTS 使用者交流群

![17.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bb08d040f472468d8f6bb271913338f9~tplv-k3u1fbpfcp-zoom-1.image)

瞭解更多相關資訊，請搜尋微訊號（AlibabaCloud888）新增雲原生小助手！獲取更多相關資訊！

阿里雲效能測試服務 PTS 新面貌 - 壓測協議、施壓能力全新升級

相關文章