PTS 3.0：開啓智能化的壓測瓶頸分析

作者：拂衣

PTS 簡介

性能測試 PTS（Performance Testing Service）是阿里雲上一款簡單易用，具備強大的分佈式壓測能力的 SaaS 壓測平臺。PTS 可以模擬複雜的業務場景，並快速精準地調度不同規模的流量，同時提供壓測過程中多維度的監控指標和日誌記錄。用戶無需準備資源，即可按需發起壓測任務，監控壓測指標，獲取壓測報告，進而能夠高效率、全方位地驗證業務站點的性能、容量和穩定性。

阿里雲壓測平臺演進之路

阿里雲壓測平臺 PTS，由阿里雲可觀測團隊傾心打造，應雙十一穩定性和容量規劃的需求背景而誕生，隨高可用、中間件上雲而對外輸出產品能力。整體演進分以下 5 個階段：

2010 年-阿里巴巴容量規劃平臺

在此之前，阿里巴巴大促活動的容量規劃主要通過人工估算的方式來完成的。各個系統的負責同學聚在一起開個會，將信息彙總到一起，按專家經驗就把容量規劃的機器預算給定下來了。而且，各個系統通常都留了比較大的機器冗餘，即使估算的不準也不會造成大的業務影響。

此時，容量計算的公式被第一次提了出來，通過目標容量/單機容量上限，得到各應用需要的機器資源數，再加上一定比例的冗餘量，就是大促時需要的總資源數。

在阿里容量規劃平臺的 1.0 版本當中，通過對各業務系統線下環境單機壓測，來獲取各服務的單機容量上限，完成了從人工容量規劃到系統化容量規劃的過度。

2013 年-阿里巴巴全鏈路壓測-流量平臺

隨着雙十一業務規模快速拉昇，分佈式系統架構的技術組件越來越多，應用的上下游依賴關係也越來越複雜。雙十一當天 0 點到來的時候，從 CDN 到接入層、前端應用、後端服務、緩存、存儲、中間件整個鏈路上都面臨着巨大流量，這個時候應用的服務狀態除了受自身影響，還會受到依賴環境影響，並且影響面會繼續傳遞到上游，哪怕一個環節出現一點誤差，誤差在上下游經過幾層累積後會造成什麼影響誰都無法確定。由於各層依賴的不確定性，無法再基於單業務容量上限規劃全局容量。

所以我們建立了全鏈路壓測機制，通過全面仿真雙十一業務流量，我們的系統能夠提前經歷幾次“雙十一”，讓容量的不確定性問題提前暴露並解決。

流量平臺是全鏈路壓測的 CPU，能夠模擬出雙十一上億用戶的仿真流量，製造每秒數十萬次用戶行爲的超大規模流量。主要由兩大部件構成：1）全鏈路壓測操控中心，進行壓測的配置和操控、數據的監控以及對壓測引擎集羣的管控；2）壓測引擎，由控制檯統一管控，部署在外網 cdn 集羣，進行登陸、session 同步，發送各種協議的壓測請求、狀態統計。

2013 年之後，全鏈路壓測成爲雙十一、雙十二等大促備戰最重要的穩定性驗證工具，隨着業務的發展不斷進化，持續發揮着不可替代的作用。

2018 年-阿里雲 PTS 1.0：阿里雲壓測產品發佈

在雲計算的浪潮下，越來越多的用戶開始基於阿里雲上的基礎產品設計自己的架構。在 2018 年，我們正式發佈了阿里雲壓測產品：PTS，將阿里巴巴集團壓測平臺的技術架構遷移至阿里雲，對外部用戶提供 SaaS 化的壓測產品。PTS 1.0 核心能力包括：

無限接近真實的流量：業務場景中無論是高併發要求還是發起端的分散度，覆蓋三四線城市主要運營商的節點廣度都能做到真正模擬用戶行爲，客戶端到服務端間複雜的網絡瓶頸也能暴露無遺，壓測結果更加全面和真實可信。
操作簡單易上手：不需要專門的性能測試團隊或者測試背景的積累，完全面向開發的交互設計，開發自測試，投入產出比高。
多維度施壓：支持併發和 RPS 雙維度。
壓力動態調整：支持壓測能力動態修改。

2020 年-阿里雲 PTS 2.0：施壓能力、產品體驗再升級

隨着 PTS 1.0 用戶規模的不斷擴大，越來越多的用戶在不同的業務場景對 PTS 提出了支持超高併發的壓測需求，甚至超過了集團雙十一的併發量級，典型場景如：春晚紅包壓測、保險開門紅壓測、考試報名壓測等。PTS 2.0 通過優化資源調度和施壓引擎性能，提供了百萬併發、千萬 QPS 的壓測能力，連續支撐了多次春晚紅包活動等頂級流量壓測。

同時，PTS 2.0 升級了流量錄製和多協議場景化功能，提升了產品體驗：

流量錄製功能：允許錄製實際用戶操作，以便創建真實的用戶行爲模擬。
多協議支持：對流媒體、MQTT、RocketMQ、Kafka、JDBC、Redis、Dubbo 等協議支持白屏化壓測配置，擴寬測試場景。

2024 年-阿里雲 PTS 3.0：可觀測、智能化、開源加持的下一代壓測平臺

在 PTS 1.0 和 2.0 的持續演進中，PTS 在產品體驗、施壓能力都得到了大幅提升。要做一輪完整的容量規劃，用戶還需要解決以下問題：

評估壓測的影響範圍，確定壓測流量會經過哪些服務端應用，如何準確地掌控壓測的爆炸半徑。
洞察壓測和業務系統的全局監控指標，分析當前系統容量水位。
如果壓測結果不滿足預期，需要出分析整個系統的性能瓶頸點。

這些問題是每個測試團隊都需要面對的，在雲原生和可觀測技術的發展下，如何更好的解決這些問題？

針對以上挑戰，我們提出性能壓測可觀測化能力，分別針對以上問題提出壓測鏈路可觀測：

首先，在實施壓測前，先執行一次撥測，通過撥測發起一次請求來構建整個壓測鏈路拓撲，通過鏈路拓撲全局來看整個壓測的影響範圍。

其次，性能指標可觀測，獲取壓測鏈路所涉及的監控指標，自動生成壓測及各業務各實例水位大盤，邊壓邊觀測。

再次，聚合壓測請求各指標和調用鏈，通過調用鏈分析和智能化分析，實現性能瓶頸可觀測。

最後，通過前面提到的壓測指標和各服務實例資源水位，進行梯度壓測評估驗證系統服務容量。構建性能壓測可觀測，實現從壓測到數據分析。在此之上，我們構建了可觀測加持下的下一代阿里雲壓測平臺 PTS 3.0 ，通過打通阿里雲全棧可觀測生態，並集成雲原生大模型和多模型智能歸因算法，給用戶提供更專業、結論更清晰、更有洞察力的壓測報告，輔助用戶在 PTS 實現壓測瓶頸定位和根因分析。

同時 PTS 3.0 全面兼容開源 JMeter 壓測工具，只需 JMeter 腳本上傳到 PTS，即可自動補全依賴插件，一鍵發起壓測。