中通快遞作為國内知名綜合物流服務企業，已連續5年穩坐行業市場佔有率榜首。受雙11、618等大促活動影響，井噴式的業務流量對中通的系統穩定性提出了更高的要求，過去的壓測方案已經無法滿足業務發展的需求。測試環境等比縮放導緻壓測失真、龐大且複雜的系統鍊路梳理等都是棘手的問題，讓我們一起看看中通是如何利用大促系統穩定性保障利器Takin來完成這項艱巨的任務的。
背景
目前在中通性能測試主要分為線上和線下壓測兩種方案，在反複實踐過程中我們漸漸發現這兩種方案都有着各自不足之處，且為壓測工作帶來了很多不便。以下就線上和線下壓測的不足分析，談談中通是如何一步步改進壓測方案并解決問題。
- 線下壓測方案中的不足
線上下壓測試過程中，為了減少與真實環境實體資源上的差異，公司采取的是針對CPU與記憶體進行等比縮放的政策，如果是計算密集型應用，線上環境總的CPU核數為80，線下壓測環境總CPU核數為8核，則為10:1的線上線下等比縮放政策，如果是IO（目前隻看記憶體）密集型應用，線上記憶體總量如果為80G，線下壓測環境記憶體總量為8G，也同樣是10:1的線上線下等比縮放政策。
很明顯這種等比縮放政策在高TPS目标的壓測場景下會失真，TPS目标越高，則失真越嚴重，因為我們并不能對網絡、中間件、資料庫等一系列的因子也同樣做出等比縮放。
- 線上壓測方案中的不足
線上上壓測時，多以讀接口為主，隻有相當少量的寫接口會做線上壓測，這少量的寫接口通常也需要被壓應用的開發人員進行代碼改造，以避免大量的壓測資料對業務資料造成污染。
是以這種線上壓測方式無法大範圍應用，同時這種對代碼硬改造的方式，也增加了壓測成本與風險，導緻大家通常不願意面對線上壓測，更不用提聯合上下遊一起進行線上全鍊路壓測了，而這種不敢線上上大量壓測的思維，也導緻更多壓測被放線上下以等比縮放的方式進行，其後果則是壓測結果的失真，在2012年，某廠正是因為測試環境等比縮放壓測，導緻網絡流量資料失真，引發了線上故障，才促使其下決心走上了線上全鍊路壓測的道路。
- 引入技術解決方案
因為有上述問題，公司引入了線上全鍊路壓測産品，其特點是使用壓測JavaAgent探針以位元組碼方式植入應用，這樣業務應用則無須寫死，就可以自動識别和相容壓測流量，并進行分流，将緩存和存儲資料存儲到影子區域，實作實體隔離壓測資料，避免造成生産資料污染，就技術方案上看，線上全鍊路壓測産品最核心的功能其實就是兩點：流量染色與保障資料安全，示意圖如下：
全鍊路壓測部署&核心配置
- 線上全鍊路壓測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及消費組等等，由此将壓測資料與正式資料進行隔離，避免了壓測資料對正式業務資料的污染。
- 主要影子資源的配置
緩存redis的影子資源，在探針識别為壓測流量時，會自動對要寫入或者查詢的key前加上"PT_"字首來進行資料隔離，而MQ的TOPIC與消費組影子資源，需要在公司的ZMS配置中心，按業務TOPIC與消費組名稱，去新增出帶"PT_"字首的TOPIC與消費組名即可。資料庫資源的配置會複雜一些，下面單獨說明。
影子庫配置如下圖所示：
影子表配置如下圖所示，都是把業務表名前加上“PT_”來表示為影子表，多個表使用逗号分隔：
- 擋闆的配置
線上上壓測時，有可能會觸發到資金扣款或者短信發送等敏感方法，如果大量的壓測觸發了這類方法，輕則造成騷擾，重則發生嚴重的資損，類似這樣的方法，我們則需要在梳理壓測鍊路時進行識别，并為此類方法加上擋闆（Mock)，如下圖示例，如此當壓測探針識别到壓測請求(有壓測标)時，則會執行我們針對此方法所配置的Mock代碼，如果是正式的業務流量（無壓測标），則仍然會執行原來的短信發送方法而不受影響。
鍊路接入與壓測流程
做線上全鍊路壓測，很多人擔心的一個問題就是，線上生産環境就這麼直接壓，不怕出問題麼，那麼除了進行錯峰壓測以外，中通壓測團隊為了安全有序的進行線上全鍊路壓測，經過兩期接入項目的摸索，已經形成了一整套保障安全壓測的實施流程，流程圖如下:
全鍊路壓測可以大緻分為三個階段：
1.需求定義與鍊路梳理階段；
2.測試環境部署及測試階段；
3.線上壓測及結果産出階段。
- 需求定義與鍊路梳理
需求定義
- 明确壓測的具體業務鍊路與範圍邊界
- 明确壓測的目的，是達到指定性能名額，還是摸高進行容量規劃
- 具體的性能名額，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的方式繞開。
至此，整個鍊路的業務，技術，資料資訊都已經了解得基本清楚了，那麼在這個基礎上，則可以參考上一節中《全鍊路壓測部署&配置》相關的内容，在測試環境将整個全鍊路壓測環境給部署與配置妥當。
- 測試環境調試
全鍊路壓測，向上追述，一般總是能找到一個頁面或者APP入口，那麼必然對應着一個http的接口，是以為了表示這個請求是全鍊路壓測的影子請求，需要在http頭中增加User-Agent:PerfomanceTest，如果入口就直接是一個dubbo入口的話，則在dubbo的Attachment Args裡增加key:value為: p-pradar-cluster-test:true
當我們在測試環境觀察到壓測流量都按我們的預期，落入了相關的影子資源，而沒有發生資料落入正式資源的情況後，我們可以在測試環境進行少量資料的壓測，如果一切正常，我們就可以開始着手進入線上環境的壓測流程了。
- 線上壓測及結果産出階段
準備階段
- 提前準備線上必須的影子庫表，鋪底資料，影子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大促與淘寶&拼多多等大流量聯合線上壓測的場景，雖然初步能解決原來壓測中存在的問題，但也引入了一些新的問題。
- 組織與工作模式問題
先看看某大廠BU進行全鍊路線上壓測的簡化版組織及工作模式架構圖：
中通全鍊路線上壓測組織與工作模式圖：
全鍊路壓測系統接入幾乎牽扯到整個産研團隊的各個方面，需要開發、測試、運維及供應商等團隊充配置設定合協同工作。
圖一中某大廠由于訂單全鍊路壓測屬于公司級重點項目，由上至下的推動相關系統改造和統一協調資源，各項目由開發負責人挂帥，開發、測試、運維互相配合，性能團隊屬于支撐團隊，負責壓測方案評審、工具支援、壓測問題記錄與答疑。
圖二中我們的模式，全鍊路壓測屬于部門級項目，由性能測試團隊負責主導，對接各方推動接入工作，其他相關方屬于配合從業人員，性能測試團隊需要協調各方資源，工作難度較高。
- 其它問題