作者：笛墨
稽核&校對：風雲
編輯&排版：雯燕
引言
性能測試 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 壓測
距離 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 級别并發自助壓測。無論你是日常測試場景的小并發壓測、還是需要模拟超大型活動的壓測，點選發起流量即可，無需再為上述問題煩惱。
安全、無侵入的生産環境寫壓測能力産品化
-
確定壓測标記不丢失。
壓測流量在任何環節能夠被正确的識别出來。在流量入口層帶上壓測标，中間件識别并繼續往下傳遞壓測标，保證整條鍊路上壓測标不丢失，通過這種方式使得下遊的應用和存儲也能接收到壓測标。
-
確定壓測流程不中斷。
壓測流量能夠正常的調用下去，整個流程不被阻斷，傳回符合預期的業務結果。業務的應用層，要支援全鍊路也需要對應的改造，應用層在識别到壓測标時，需要繞過參數校驗、安全校驗等校驗邏輯，例如手機号格式校驗、使用者狀态校驗、以及一些其它特殊業務校驗邏輯。
-
確定壓測資料不污染。
壓測資料不對線上正常的業務造成資料污染。全鍊路場景往往包含多個讀寫場景，為了隔離壓測資料，存儲中間件識别到壓測标之後，将資料寫入影子庫表，與真實的資料區分開。為了更加真實的模拟真實場景，影子庫表中的基礎資料（比如買家、賣家、商品、店鋪等）是由真實資料加上固定偏移量構造而成，遷移過程中會進行采樣、過濾、脫敏等操作保證資料安全，一般在資料量級上和真實資料保持一緻。