全鏈路壓測體系建設方案的思考與實踐

本文來自: PerfMa技術社區

PerfMa(笨馬網絡)官網

系統性能測試的幾個痛點

在金融、零售快消、物流、新能源等傳統行業，一般都會有一個相對獨立的測試團隊，其中包括了性能測試。

過去性能測試一般是開發自測、或以項目需求驅動的方式實施，也就是根據需求在測試環境驗證相應的性能目標，出具性能驗收報告後就算結束。但隨着業務系統的迭代速度不斷加快，這種作法也會存在諸多不足：

首先，測試環境得出的測試結果，能夠驗證程序級問題，但因環境和數據的差別，沒法驗證或得到業務系統在生產環境的性能指標。

其次，隨着業務需求變動的頻率不斷加快，發佈週期隨之縮短，不少緊急項目直接跳過性能測試就上生產。也造就了一個行業誤區：功能必定要測，性能能夠不測。舉個例子，好比說變動數據庫鏈接數則是一個反例。

第三，據瞭解過的大多企業，爲了生產系統的安全，平常水位很低，好比CPU利用率不到10%，高峯時期可能達到20%。之因此資源利用率低，也是由於對生產容量的不肯定性所形成。

另外，以項目需求驅動測試的作法，測試結果將會是數據孤島，很難作到可持續的性能基線跟蹤和風險識別，容易引起累積雪崩性問題。

性能測試成熟階段

目前業內並無針對性能評測的成熟度的評估模型，根據過往的行業實踐經驗，大體可將其定位爲五個階段。

第一階段，以開發自測爲主，初創型企業在該階段居多，沒有獨立的性能測試團隊，系統開發完成後，開發人員自行用開源工具針對核心接口進行壓測，缺少專業的測試方法。

第二階段，以項目需求驅動爲主，測試團隊被動領活幹，測試團隊基於項目需求設計測試場景對被測系統進行相應評測，測試需求與測試目標大多依賴人工評審。

第三階段，以瀑布模式爲主，擁有獨立的性能測試團隊，並制定統一的的性能准入/準出標準和規範，經過組織形式推廣整個IT部門，實施規範化的性能測試驗收過程。

第四階段，化被動爲主動，用平臺化方式對關鍵業務變動造成一套完整的性能迴歸體系，打通持續集成，依託迭代性能評測數據創建可持續的性能基線跟蹤機制，識別頻繁迭代變動帶來的性能隱患。

第五階段，測試左右賦能，向左賦能於研發，提早識別潛在性能風險，向右賦能於運維，爲生產容量、穩定性提供有效保障手段。

壓測方法逐步演進

從最初的線下單系統、單模塊以及短鏈路壓測，轉變爲生產全鏈路壓測。

線下壓測階段

最先在螞蟻金服，壓力測試是在測試環境進行，且是針對一些重點項目，好比餘額寶、花唄、借唄等明星型項目，因爲項目的重要性，將會由專職的性能測試專家介入參與評估。後因爲公司的核心業務日益增多，逐步開始在測試環境進行迭代變動迴歸測試，並造成多版本性能對比評估機制。這種測試手段，難以用測試環境得出的結果推導生產真實容量。

引流壓測階段

隨着業務量的不斷增加，考慮到線下測試結果的準確性，開始嘗試生產壓測，這種壓測手段，咱們稱之爲引流壓測。事實上沒有真正的模擬放大壓力進行測試，而是一種經過縮小在線服務集羣數的方式來放大單機處理量。好比一個業務系統的集羣有100個節點，將其中90個節點模擬下線或轉發流量到剩餘的10個節點上實施壓測，如圖所示。

引流壓測的弊端在於，DB承受壓力不變，上下游系統的壓力不變。壓測結果僅能表明單個應用的性能，但每每沒法識別鏈路和架構級的隱患，並且在引流過程當中假若出現異常或突如其來的業務高峯，很容易形成生產故障。

全鏈路壓測

隨着壓測技術和手段的不斷演進，在2014年初，全鏈路壓測的方法開始誕生，其目標是但願在大型促銷活動來臨前，能夠在生產環境上模擬路演進行驗證總體容量和穩定性。由此，出現了全鏈路壓測方法所涉及的公網多地域流量模擬、全鏈路流量染色、全鏈路數據隔離、全鏈路日誌隔離、全鏈路風險熔斷等關鍵技術。

多地域流量模擬技術是指，經過全國各地CDN節點模擬向生產系統施加壓力，並在壓測過程當中對生產系統健康度進行實時監控，快速識別壓測對生產業務帶來的風險，當即做出流量調節或熔斷決策。

全鏈路壓測改造的四大核心能力

1. 全鏈路流量染色，經過壓測平臺對輸出的壓力請求打上標識（如圖），在訂單系統中提取壓測標識，確保完整的程序上下文都持有該標識。
2. 全鏈路日誌隔離，當訂單系統向磁盤或外設輸出日誌時，若流量是被標記的壓測流量，則將日誌隔離輸出，避免影響生產日誌。
3. 全鏈路風險熔斷，當訂單系統訪問會員系統時，經過RPC協議延續壓測標識到會員系統，兩個系統之間服務通信將會有白黑名單開關來控制流量流入許可。該方案設計能夠必定程度上避免下游系統出現瓶頸或不支持壓測所帶來的風險。
4. 全鏈路數據隔離，當會員系統訪問數據庫時，在持久化層一樣會根據壓測標識進行路由訪問壓測數據表。數據隔離的手段有多種，好比影子庫、影子表，或者影子數據，三種方案的仿真度會有必定的差別。

如何作到全鏈路監控分析

全鏈路的監控和分析包括三個層面。第一層是用戶體驗監測，在雲壓測平臺中能夠看到用戶的感覺，好比響應時間是否隨着壓力的加大而變長。假如耗時突增引起業務下跌，咱們將進入第二層監控，快速從用戶體驗側下鑽到生產系統後端鏈路，並快速識別出現問題的服務節點或接口。

依託於以上監控信息，須要利用相關分析能力快速給出應急決策依據，好比經過重啓解決會有何影響？同時，在故障發生過程當中，分析系統將會保留現場，也會繼續下鑽到第三層分析，好比深度追蹤某個接口或方法中的全部執行邏輯耗時，再好比爲何CPU會忽然暴增、GC暫停時間長等。

三層分析能力的結合和聯動，比傳統APM相關技術監控粒度更深，同時具有分析和優化建議能力。同時，在生產環境的變動灰度、故障演練也均可以依託於壓測流量進行，這樣下降在生產流量下直接演練的風險。

線下環境壓測頗有必要

這一點，值得特別提出，2015年咱們曾犯過一個錯誤：有了生產壓測，線下壓測基本不作了，就由於這種心態，致使：

• 不少程序變動所引發的一些基本的程序級問題沒有獲得驗證。
• 致使生產壓測過程當中頻繁出現故障。

所以，咱們又從新把線下回歸體系撿了起來，甚至花了較大精力去完善這個線下回歸體系。

總而言之，線下壓測是無風險發現程序級問題，線上壓測是低風險實現線下補足和評估生產的容量。

全鏈路壓測體系落地實例

咱們有個合做企業「性能評測體系建設」的案例：這個企業一開始屬於前面講過的成熟度階段的5級中的第2-3級，每一年大概有200個左右的項目，團隊大，有幾十個性能測試人員，迴歸業務量很是大，迭代週期是雙週，當時用戶最大的挑戰是測試需求量大致使人力投入大，而且沒法在發佈前完成評測工做。在合做後，一方面依託平臺化能力，另外一方面優化組織協同模式、規範化、體系化，在爲期不到半年時間組織能效提高4-6倍，同時必定程度上提高了壓測環境資源的利用率，下降資源投入成本。

另外，還有一個生產全鏈路壓測的案例：在爲一個企業實施生產壓測時，偶發性出現用戶相應很慢，經過全鏈路下鑽深度分析，發現這些特定的用戶訪問時，Redis調用很是頻繁，當特定用戶集中訪問時，整個Redis達到容量瓶頸，最終影響到全部用戶。

最後，咱們再舉一個因開源組件BUG致使的CPU使用暴增引起的故障。在一次壓測過程當中，咱們發現一個服務節點上的某個CPU消耗100%，咱們利用平臺的深度熱點方法分析能力，發現CPU利用率排在第一的方法是通信框架Netty的內存清理邏輯。經排查，發現是Netty的BUG（高併發下出現死循環），咱們本想修復，後發如今其官方4.1.25版本已修復，升級後CPU佔滿的狀況徹底消退。最終不只解決了CPU利用率高的問題，業務的TPS也從2491提高到3040。

總結

第一，不能有了生產全鏈路壓測就不作線下壓測；

第二，不是有了生產影子表能力，就能夠在生產隨意實施壓測。好比日誌也須要隔離，若是生產日誌和測試日誌混爲一體，將會影響大數據分析（如用戶行爲分析）。同時生產壓測自己是高風險的行爲，因此壓測前中後的生產穩定性風險防控能力也相當重要。

一塊兒來學習吧：

PerfMa KO 系列課之 JVM 參數【Memory篇】

一次 JVM 進程退出分析