壓測怎麼做？如何自動化？盤點各大公司全鏈路壓測方案與實踐

本文綜合盤點各大公司團隊的全鏈路壓測技術方案和實踐路徑，供大家參考。

一、什麼是全鏈路壓測？

全鏈路壓測指的是基於實際的生產業務場景、系統環境，模擬海量的使用者請求和資料對整個業務鏈進行壓力測試，並持續調優的過程。常用於複雜業務鏈路中，基於全鏈路壓力測試發現服務端效能問題。

一般來說，全鏈路壓測：

• 基於實際的生產業務場景、系統環境，基於真實資料模擬海量的使用者請求對整個業務鏈進行壓力測試，並持續調優的過程；
• 全鏈路的核心為：業務場景、資料鏈路、壓力模型和環境拓撲；
• 全鏈路壓測不僅僅是一種測試手段，更確切來說其是一種測試過程，該過程涉及自動化測試/效能測試/高可用測試技術以外，還覆蓋效能分析調優以及擴縮容解決方案等等。

全鏈路壓測與傳統壓測的區別：

哪些場景適合全鏈路壓測：

• 定時定期進行線上運營活動；
• 業務鏈路以及資料鏈路呼叫錯綜複雜，各子系統之間呼叫關係密切，均為業務核心呼叫鏈路；
• 真實業務流量與歷史流量對比預估有量的增長；
• 業務需求頻繁迭代，業務鏈路效能波動較大；
• 測試環境資料、系統版本等無法統一，且資源配置與線上差異較大。

行業內全鏈路壓測方案對比：

方案一：流量混布, 儲存隔離, 線上施壓

對線上服務壓測，壓測前根據容量預估和壓測目標，對線上服務進行擴容和 cpu、mem 等相關配置的變更。

壓測產生的資料與線上真實資料做隔離，採用影子庫表的方式，防止汙染線上真實儲存。

需構造壓測資料和壓測流量，透過壓測標記來區分流量屬性。

方案二：對資料本身做標記, 邏輯隔離，線上施壓

對線上服務施壓，與方案一的區別在於資料隔離上，不是透過影子庫表，而是在原表上增加標記，做邏輯隔離。

業務需要做適配工作來識別流量屬性。

方案三：映象環境 OR 線下壓測

此方案線上下進行壓測，部署線下測試環境或映象環境。

線下環境穩定性不高，硬體資源和壓測資料線上線下差異大，壓測結果參考價值有限。

二、全鏈路壓測的自動化

貨拉拉技術團隊的實現思路：

全鏈路壓測自動化的探索與實踐（點選看全文）

在構思初始方案時，我們在行業內尋找並比對類似的解決方案，但是發現相關資料較少。由於全鏈路壓測和壓測自動化都需要與公司業務和內部平臺頻繁互動，我們在考慮改造全鏈路壓測自動化時，決定結合公司業務特點和現有全鏈路壓測流程以及內部平臺特性進行改造。

為實現全鏈路壓測的自動化，主要目標是把人工操作的重複工作自動化。在確定整體方案後，我們詳細梳理了全鏈路壓測前、中、後的常見工作場景，並確認了對應的需求以及平臺服務支撐。以下是我們的整體改造思路圖。

梳理出改造場景中的重點和難點問題，我們需要著重完成以下功能：

• 模型建模與模型效果對比： 無論是在壓測場景和流量的配比，還是在壓測後的效果對比中，都需要我們找到一個適合的模型演算法，以確認壓測場景的模型以及對比壓測效果。

• 壓測任務編排： 在壓測任務中，一些任務有固定的時間順序或因果關係順序。這就要求我們需要有一個靈活的任務編排系統，方便自由地編排相關壓測任務。

• 壓測任務排程： 以貨拉拉貨運全鏈路壓測為例，每次涉及到超 70 個指令碼，300 餘臺壓測機，以及數百萬訂單的壓測目標流量。因此，如何對測試場景、指令碼和測試資料以及壓測流量進行有效的管理、分發和收集顯得尤為重要。

• 健全的熔斷機制： 既要檢測出系統瓶頸，又要在出現異常時及時停止壓測流量，以避免引發更大的生產問題，因此需要一個健全的熔斷機制。

B 站技術團隊的實現思路：

bilibili 全鏈路壓測改造之全鏈自動化測試實踐（點選看全文）

B 站在全鏈路壓測上的實踐（點選看全文）

B 站的全鏈路壓測方案，簡單來說主要為流量混部、線上壓測和儲存隔離三個部分：

流量混部

• 與線上叢集資源共用，在深夜低峰時期進行線上壓測
• 透過流量打標的方式對流量進行區分，壓測流量均帶有壓測標識，支援對 http 請求和 grpc 請求打標進行全鏈路壓測
• 服務接入壓測 sdk，對壓測流量進行識別、攔截和處理

線上壓測

• 透過公司的壓測平臺，進行壓測任務和場景設計、壓測資料構造以及壓測結果分析等，具體壓測平臺的設計及原理在 B 站壓測實踐一文 中有詳細介紹。

儲存隔離

• 我們採用儲存隔離的手段，對 db 建立影子表，redis 建立影子 key，mq 建立影子 topic，將壓測流量完全隔離
• 搭建全鏈路壓測配置控制檯，管理壓測規則，主要涉及對已接入全鏈路壓測的服務的以下幾點配置： △ 需要壓測的介面 △ 壓測介面依賴的下游介面的透傳/映象/Mock 規則 △ 資料庫表的透傳/映象/寫丟棄規則 △ 快取的透傳/映象規則 △ 訊息佇列的透傳/攔截/映象規則

直播的全鏈路壓測架構圖如下，可以看到整體鏈路，由壓測平臺施壓，被壓測的服務接入壓測 sdk，獲取到由壓測規則控制檯下發的壓測配置資訊，根據配置資訊對接收到的壓測流量做處理，如配置了映象規則的資料表，壓測資料寫入影子表，對配置了映象規則的 redis,壓測的快取資料寫入影子 key 等等。

針對此鏈路上如此多的服務改造點（SQL 改造、redis 改造、databus 改造、job 改造、context 改造、go channel 改造、sync/pipeline 改造...），如何能又快又好又全面的測試覆蓋，是我們設計全鏈自動化測試方案的初衷，我們將其主要分為三個階段。

第一階段，我們對各個新增節點分別做了測試保障，如 mirror sdk、壓測配置控制檯等，保正底層基礎能力的正確性。

第二階段，當基礎建設已完成，進入到了業務接入及全流程驗證階段。業務是不停迭代的，其中隨著基架的不斷演進，業務所涉及的服務也包含了部分歷史債，當此套框架真正接入業務後，我們往往在業務實際使用中會發現很多不適配的地方，包括框架設計不夠健壯或者業務的使用姿勢不規範等原因，需要修復或相容。這個階段的測試也是最繁瑣、測試量最大、重複性很高的地方，為此全鏈自動化測試全面應用於此階段，來提升效率及業務覆蓋度。

第三階段，主要應對於未來的擴充，隨著全鏈路壓測覆蓋的業務越來越多，當” 常態化 “的全鏈路壓測計劃提上日程，重複的工作和人力成本隨之增加。此時測試工具更需要平臺化及視覺化，為壓測前、壓測中、壓測後各個階段的重複工作提供有效的自動化支援。

三、盤點各公司團隊的全鏈路壓測方案

1. 位元組跳動是怎麼做全鏈路壓測的？（點選看全文）

主要介紹位元組跳動的服務端全鏈路壓測體系，以及位元組跳動各種業務的全鏈路壓測實踐。

2.美團--全鏈路壓測平臺（Quake）在美團中的實踐

美團--全鏈路壓測自動化實踐

全鏈路壓測是我們準確評估整個系統效能水平的必經之路。目前，美團內所有核心業務線都已接入全鏈路壓測。Quake（雷神之錘）作為公司級的全鏈路壓測平臺，它的目標是提供對整條鏈路進行全方位、安全、真實的壓測，來幫助業務做出更精準的容量評估。

3.滴滴 -- 全鏈路壓測模擬度量體系建設（點選看全文）

從 2020 年開始滴滴網約車壓測團隊開始重點建設壓測模擬度量體系，並實現工程化落地應用，本文將系統化介紹滴滴網約車全鏈路壓測模擬度量體系建設過程。

4.阿里淘寶--全鏈路壓測體系建設方案的思考與實踐（點選看全文）

阿里雲--PTS 3.0：開啟智慧化的壓測瓶頸分析（點選看全文）

5.得物 -- 壓測平臺在全鏈路大促壓測中的實踐（點選看全文）

得物壓測平臺一直在持續完善和提升中，希望本文能拋磚引玉，提供壓測平臺建設方面的一些參考經驗。

6.汽車之家 -- 全鏈路模擬壓測系統（點選看全文）

目前已多次支援公司級各類大型活動的模擬全鏈路壓測，為線上服務的穩定執行提供了強有力的質量保障。經過多年的打磨如今藉此機會與大家分享一下心路歷程，積極討論，歡迎提出意見，希望可以幫助我們進一步成長。（文中引用均為測試資料）

7.轉轉 -- 全鏈路壓測演進之迭代式壓測（點選看全文）

為推進常態化壓測更高效，更貼近業務進行壓測，且分化所有業務流量的焦點集中在大促壓測上，轉轉團隊把一些常規壓測操作前置到日常業務迭代需求專案上，根據中、大規模的需求專案試行迭代式壓測，提供更細緻、更小範圍的壓測方式，嘗試解決在壓測上的時效和人力問題。

8.高途 -- 全鏈路壓測之方案設計（點選看全文）

9.中國人壽業務穩定性保障：“1+1+N” 落地生產全鏈路壓測（點選看全文）

將於2024年7月20日在上海舉辦的 MTSC2024 第十三屆中國網際網路測試開發大會，7 折優惠購票限期發售中！ 瞭解詳情