告別傳統壓測：全鏈路壓測在中通的實踐分享

中通快遞作為國內知名綜合物流服務企業，已連續5年穩坐行業市場份額榜首。受雙11、618等大促活動影響，井噴式的業務流量對中通的系統穩定性提出了更高的要求，過去的壓測方案已經無法滿足業務發展的需求。測試環境等比縮放導致壓測失真、龐大且複雜的系統鏈路梳理等都是棘手的問題，讓我們一起看看中通是如何利用大促系統穩定性保障利器Takin來完成這項艱鉅的任務的。

背景

目前在中通效能測試主要分為線上和線下壓測兩種方案，在反覆實踐過程中我們漸漸發現這兩種方案都有著各自不足之處，且為壓測工作帶來了很多不便。以下就線上和線下壓測的不足分析，談談中通是如何一步步改進壓測方案並解決問題。

1. 線下壓測方案中的不足

線上下壓測試過程中，為了減少與真實環境物理資源上的差異，公司採取的是針對CPU與記憶體進行等比縮放的策略，如果是計算密集型應用，線上環境總的CPU核數為80，線下壓測環境總CPU核數為8核，則為10:1的線上線下等比縮放策略，如果是IO（目前只看記憶體）密集型應用，線上記憶體總量如果為80G，線下壓測環境記憶體總量為8G，也同樣是10:1的線上線下等比縮放策略。
很明顯這種等比縮放策略在高TPS目標的壓測場景下會失真，TPS目標越高，則失真越嚴重，因為我們並不能對網路、中介軟體、資料庫等一系列的因子也同樣做出等比縮放。

1. 線上壓測方案中的不足

線上上壓測時，多以讀介面為主，只有相當少量的寫介面會做線上壓測，這少量的寫介面通常也需要被壓應用的開發人員進行程式碼改造，以避免大量的壓測資料對業務資料造成汙染。
所以這種線上壓測方式無法大範圍應用，同時這種對程式碼硬改造的方式，也增加了壓測成本與風險，導致大家通常不願意面對線上壓測，更不用提聯合上下游一起進行線上全鏈路壓測了，而這種不敢線上上大量壓測的思維，也導致更多壓測被放線上下以等比縮放的方式進行，其後果則是壓測結果的失真，在2012年，某廠正是因為測試環境等比縮放壓測，導致網路流量資料失真，引發了線上故障，才促使其下決心走上了線上全鏈路壓測的道路。

1. 引入技術解決方案

因為有上述問題，公司引入了線上全鏈路壓測產品，其特點是使用壓測JavaAgent探針以位元組碼方式植入應用，這樣業務應用則無須硬編碼，就可以自動識別和相容壓測流量，並進行分流，將快取和儲存資料儲存到影子區域，實現物理隔離壓測資料，避免造成生產資料汙染，就技術方案上看，線上全鏈路壓測產品最核心的功能其實就是兩點：流量染色與保障資料安全，示意圖如下：

全鏈路壓測部署&核心配置

1. 線上全鏈路壓測agent安裝部署

• 將pradar-agent.zip包上傳到需要接入應用所對應的伺服器/home/admin目錄下，並直接解壓.
• 修改對應應用的啟動指令碼( 通常在釋出平臺中修改)，將修改後的後面這個命令新增到java -jar xxx.jar 的-jar之前（ -javaagent:/home/admin/pradar-agent/agent/pradar-core-ext-bootstrap-1.0.0.jar -Dpradar.project.name=該應用應用名 ）
• 重新啟動應用
  在pradar-web操作頁面的應用管理頁，檢視是否成功上報：
  

agent安裝完全成後，在具體實施時，如果壓測入口是http介面，則在請求頭中帶上“User-Agent：PerfomanceTest”，如果入口是dubbo介面，則在AttachementArgs中帶上“p-pradar-cluster-test：true”，agent會將這類請求自動識別為壓測流量，它會將壓測標識向下遊應用傳遞，並將資料分流到應用所配置的影子資源中，例如redis的影子key、影子資料庫（表）、rocketmq上配置的影子TOPIC及消費組等等，由此將壓測資料與正式資料進行隔離，避免了壓測資料對正式業務資料的汙染。

1. 主要影子資源的配置

快取redis的影子資源，在探針識別為壓測流量時，會自動對要寫入或者查詢的key前加上"PT_"字首來進行資料隔離，而MQ的TOPIC與消費組影子資源，需要在公司的ZMS配置中心，按業務TOPIC與消費組名稱，去新增出帶"PT_"字首的TOPIC與消費組名即可。資料庫資源的配置會複雜一些，下面單獨說明。
影子庫配置如下圖所示：

影子表配置如下圖所示，都是把業務表名前加上“PT_”來表示為影子表，多個表使用逗號分隔：

1. 擋板的配置

線上上壓測時，有可能會觸發到資金扣款或者簡訊傳送等敏感方法，如果大量的壓測觸發了這類方法，輕則造成騷擾，重則發生嚴重的資損，類似這樣的方法，我們則需要在梳理壓測鏈路時進行識別，併為此類方法加上擋板（Mock)，如下圖示例，如此當壓測探針識別到壓測請求(有壓測標)時，則會執行我們針對此方法所配置的Mock程式碼，如果是正式的業務流量（無壓測標），則仍然會執行原來的簡訊傳送方法而不受影響。

鏈路接入與壓測流程

做線上全鏈路壓測，很多人擔心的一個問題就是，線上生產環境就這麼直接壓，不怕出問題麼，那麼除了進行錯峰壓測以外，中通壓測團隊為了安全有序的進行線上全鏈路壓測，經過兩期接入專案的摸索，已經形成了一整套保障安全壓測的實施流程，流程圖如下:

全鏈路壓測可以大致分為三個階段：
1.需求定義與鏈路梳理階段；
2.測試環境部署及測試階段；
3.線上壓測及結果產出階段。

1. 需求定義與鏈路梳理

需求定義

• 明確壓測的具體業務鏈路與範圍邊界
• 明確壓測的目的，是達到指定效能指標，還是摸高進行容量規劃
• 具體的效能指標，tps(每秒請求數)/rt(響應時間)/成功率/SA(以99%為例，指99%的請求響應時間都在設定的rt範圍之類,也就是RT的達標率)

鏈路梳理
鏈路梳理是全鏈路壓測最為重要也是最核心的環節，通常這個環節的質量，將影響全鏈路壓測的整體實施效率。接下來詳細說一下，鏈路梳理的目的步驟與需要拿到的關鍵資訊

鏈路大圖
首先需要梳理出鏈路呼叫大圖，剛開始不需要太細，但需要對入口/出口/應用名/資料庫/快取/中介軟體/資金影響/郵件/簡訊等，類似這樣的一些關鍵資訊能梳理到，因為保密手冊的原因，具體的鏈路圖，這裡就不放出了，可以用本文最上面的《壓測流量鏈路示意圖》進行腦補。

詳細資訊收集操作手冊
根據上面梳理的梳路大圖，進一步明確具體細節，需要收集如下資訊：

• 應用基礎資訊與部署資訊
  
• 鏈路模組-指的是這次需求所確定的壓測鏈路
• 應用名-應用名稱，在jvm中設定時-Dpradar.project.name的value內容
• 應用負責人-一般為應用的主開發人員
• 運維-可以進行agent安裝包上傳與安裝，並檢視agent相關日誌的系統運維人員
• 測試負責人-此應用的測試人員
• DBA-可以進行資料鋪底，影子庫表建立，資料庫效能監控的DBA人員
• 效能指標-本次壓測的目標
• 應用的呼叫鏈型別與介面-指的是在全鏈路壓測中，本應用在整個鏈路呼叫中所經過的介面方法名，以及對應的介面型別，在瞭解這個資訊時，應該要了解清楚這些介面方法的作用與邏輯，以此判斷出是否需要對其加擋板(mock)，是否需要進行一些測試資料初始化的準備工作。
• 啟動容器-例如tomcat或者jar方式直接啟動
• 例項數量-主要是對測試環境與線上環境的例項實進行統計，需要所有例項全部安裝agent，不然可能導致壓測資料流入到正式的資料庫表中。
• 應用入口資訊與相關依賴資訊

• 入口-壓測的入口
• 資料庫jdbc連線資訊-主要是資料庫的型別，連線的域名（或者IP），埠，資料庫名稱，使用者名稱與密碼等相關的資訊。
• 用到的表-發起壓測後，呼叫流經到該資料庫時，會讀哪些表，會寫哪些表，資料邏輯是什麼，都需要搞清楚，以方便判斷怎麼造出測試資料，是用影子庫方式還是用影子表方式。
• 檔案路徑-是否會在讀寫檔案的相關資訊.
• redis預設值-發起壓測後，呼叫流經redis的業務與資料邏輯，比如面單的單號是從redis中讀取的，則我們可以根據壓測量，在單號存放的redis中預設（鋪底）一批測試單號資料，注意對於redis中預設測試資料，需要考慮過期時間，另外測試資料的key鍵是在正式的key值前加上PT_來作為影子key。
• mq的topic-如果涉及到mq，則需要建立影子topic與影子消費組，方法都是在正式的topic與消費組前增加PT_來作為影子topic與影子消費組，需要特別注意的是，影子topic/影子消費組與正式的topic/消費組都需要在同一個叢集。
• es索引-在正式的es索引前，加上PT_作為影子索引.
• hbase-正式表前加上PT_作為影子表.
• 不良影響-在明細資訊收集過程中，需要梳理出此應用是否會有產生實際的資金/電話簡訊郵件/網安資料上報等一系列，有可能因壓測而造成的不良影響，針對這些不良影響的呼叫方法，則需要以加擋板mock的方式繞開。

至此，整個鏈路的業務，技術，資料資訊都已經瞭解得基本清楚了，那麼在這個基礎上，則可以參考上一節中《全鏈路壓測部署&配置》相關的內容，在測試環境將整個全鏈路壓測環境給部署與配置妥當。

1. 測試環境除錯

全鏈路壓測，向上追述，一般總是能找到一個頁面或者APP入口，那麼必然對應著一個http的介面，所以為了表示這個請求是全鏈路壓測的影子請求，需要在http頭中增加User-Agent:PerfomanceTest，如果入口就直接是一個dubbo入口的話，則在dubbo的Attachment Args裡增加key:value為: p-pradar-cluster-test:true

當我們在測試環境觀察到壓測流量都按我們的預期，落入了相關的影子資源，而沒有發生資料落入正式資源的情況後，我們可以在測試環境進行少量資料的壓測，如果一切正常，我們就可以開始著手進入線上環境的壓測流程了。

1. 線上壓測及結果產出階段

準備階段

• 提前準備線上必須的影子庫表，鋪底資料，影子topic/影子消費組建立等需要DBA與運維部門支撐的前期事項。
• 提前在pradar-web操作頁面的應用管理頁對應用的相關配置進行配置操作。
• 按照《中通-全鏈路壓測上線計劃模板.xlsx》編寫上線計劃，並召集相關人員(運維，DBA，開發，測試，專案PM)評審，提前約定灰度上線，全量上線，試跑壓測用例，正式壓測的相關時間節點。
  

灰度驗證
將agent安裝包上傳到相關應用的其中一臺機器上，如果有預發機，最好是上傳到預發機器，然後由開發在釋出平臺中修改jvm配置，配置好agent相關的引數，重新啟動灰度機器，觀察12小時以上日誌，是否正常。

全量上線與試跑
如果灰度沒有問題，則通知運維，將agent安裝在應用的所有機器，全量重啟目標機器。
如果一切正常，則可以使用壓測指令碼進行線上試跑了，試跑方案應在上線計劃中提前規劃好：

正式壓測

• 壓測場景配置

注：壓測試場景配置最好在灰度釋出後，就開始進行
在pradar-web操作頁面的系統流程中建立一個流程（一個入口只需要建立一次）：

在操作頁面的“業務活動”中建立一個業務活動，並與上面的“系統流程”進行關聯

在“壓測管理”->“壓測場景”中，建立一個壓測場景，在業務活動中，將上一步中建立的業務活動增加進去，可以增加多個業務活動，以表明同時壓測多個活動的場景，如果有資料檔案且資料不可以重複使用的情況，可以選擇多個IP後，對此csv資料檔案勾選“拆分”操作，最後還需要關注的是正式壓測，需要使用“階梯遞增”模式，則您的Jmeter指令碼中需要以"bzm-Concurrency Thread Group"方式建立執行緒組。

• 壓測執行

確認了壓測時間與相關人員後，編寫壓測計劃，並通知到相關人員按計劃執行，同時要特別注意壓測入口域名是否受到CDN與防火牆的流量限制，如果有，需要提前找運維與網路的支撐人員將壓力機IP加入白名單。
一切準備就緒，則按計劃執行壓測即可，在“壓測場景”中點“啟動”，正式發起壓測。

壓測結果
以某場景為例得到如下壓測報告：

漏數檢測
除了一般效能測試都要進行的監控以外，進行全鏈路線上壓測試時，最大的區別是我們大量使用了影子資料庫表，影子資料庫表用於與正式資料庫表進行測試資料的隔離，且壓測資料我們都會加上識別標識，比如PT開頭的訂單號都是壓測資料，但因為各種原因，大量的壓測資料可能會導致部份或者全部壓測資料被錯誤的寫入了正式資料庫表，從而汙染了真實環境的資料，導致各種生產故障，因此有必要實時的檢測是否有測試資料被錯誤的寫入了正式資料庫表，以便及時的停止壓測行為，並快速對進入正式庫的錯誤資料進行清洗糾正，將損失降到最低。為此，我們自己基於對資料庫binlog的監聽，設計了一套能實時監控壓測資料對生產資料造成影響的工具，原理圖如下：

全鏈路壓測實踐的思考

使用壓測探針方式進行線上壓測以來，我們已經在訂單，運單，面單等多個業務共62個應用中進行了接入，成功支援了雙11&618大促與淘寶&拼多多等大流量聯合線上壓測的場景，雖然初步能解決原來壓測中存在的問題，但也引入了一些新的問題。

1. 組織與工作模式問題

先看看某大廠BU進行全鏈路線上壓測的簡化版組織及工作模式架構圖：

中通全鏈路線上壓測組織與工作模式圖：

全鏈路壓測系統接入幾乎牽扯到整個產研團隊的各個方面，需要開發、測試、運維及供應商等團隊充分配合協同工作。
圖一中某大廠由於訂單全鏈路壓測屬於公司級重點專案，由上至下的推動相關係統改造和統一協調資源，各專案由開發負責人掛帥，開發、測試、運維相互配合，效能團隊屬於支撐團隊，負責壓測方案評審、工具支援、壓測問題記錄與答疑。
圖二中我們的模式，全鏈路壓測屬於部門級專案，由效能測試團隊負責主導，對接各方推動接入工作，其他相關方屬於配合工作人員，效能測試團隊需要協調各方資源，工作難度較高。

1. 其它問題

手工操作過多，自動化程度太低，比如探針的版本控制與部署，施壓機的自動建立與分配等。
流程推進線下化，沒有形成統一管理的配置項、檢查項、評審等流程線上化推進。
測試指令碼與測試資料線上化統一管理及可複用程度底。基本靠壓測人員自行維護。
壓測所積累的結果資料，無法線上形成壓測基線自動化對比，無法達成壓測結果在時間線上的視覺化統計與分析。

最後

中通透過引入全鏈路壓測，的確解決了原來壓測環境等比縮放壓測的失真問題，但是，在面對整個在訂單，運單，面單等多個業務共62個應用的壓測，單從上下游資料層面互動就是一項複雜的工作，另外還需要各個環節的人員協作等、工作量及複雜度是可想而知的。因此，此項工程並非一天兩天能全部解決的，路漫漫其修遠兮，後面我們還將透過發起效能專項創新活動，將公司效能測試總體價值推向更高階的層次。