系統效能測試的幾個痛點
在金融、零售快消、物流、新能源等傳統行業，通常都會有一個相對獨立的測試團隊，其中包括了效能測試。
過去效能測試通常是開發自測、或以專案需求驅動的方式實施，也就是根據需求在測試環境驗證相應的效能目標，出具效能驗收報告後就算結束。但隨著業務系統的迭代速度不斷加快，這種做法也會存在諸多不足：
首先，測試環境得出的測試結果，可以驗證程式級問題，但因環境和資料的差異，無法驗證或獲得業務系統在生產環境的效能指標。
其次，隨著業務需求變更的頻率不斷加快，釋出週期隨之縮短，很多緊急專案直接跳過效能測試就上生產。也造就了一個行業誤區：功能一定要測，效能可以不測。舉個例子，比如說變更資料庫連線數則是一個反例。
第三，據瞭解過的大多企業，為了生產系統的安全，日常水位很低，比如CPU利用率不到10%，高峰時期可能達到20%。之所以資源利用率低，也是因為對生產容量的不確定性所造成。
另外，以專案需求驅動測試的做法，測試結果將會是資料孤島，很難做到可持續的效能基線跟蹤和風險識別，容易引發累積雪崩性問題。
效能測試成熟階段
目前業內並沒有針對效能評測的成熟度的評估模型，根據過往的行業實踐經驗，大致可將其定位為五個階段。
第一階段，以開發自測為主，初創型企業在該階段居多，沒有獨立的效能測試團隊，系統開發完成後，開發人員自行用開源工具針對核心介面進行壓測，缺乏專業的測試方法。
第二階段，以專案需求驅動為主，測試團隊被動領活幹，測試團隊基於專案需求設計測試場景對被測系統進行相應評測，測試需求與測試目標大多依賴人工評審。
第三階段，以瀑布模式為主，擁有獨立的效能測試團隊，並制定統一的的效能准入/準出標準和規範，通過組織形式推廣整個IT部門，實施規範化的效能測試驗收過程。
第四階段，化被動為主動，用平臺化方式對關鍵業務變更形成一套完整的效能迴歸體系，打通持續整合，依託迭代效能評測資料建立可持續的效能基線跟蹤機制，識別頻繁迭代變更帶來的效能隱患。
第五階段，測試左右賦能，向左賦能於研發，提前識別潛在效能風險，向右賦能於運維，為生產容量、穩定性提供有效保障手段。
壓測方法逐步演進
從最初的線下單系統、單模組以及短鏈路壓測，轉變為生產全鏈路壓測。
線下壓測階段
最早在螞蟻金服，壓力測試是在測試環境進行，且是針對一些重點專案，比如餘額寶、花唄、借唄等明星型專案，由於專案的重要性，將會由專職的效能測試專家介入參與評估。後由於公司的核心業務日益增多，逐步開始在測試環境進行迭代變更迴歸測試，並形成多版本效能對比評估機制。這種測試手段，難以用測試環境得出的結果推導生產真實容量。
引流壓測階段
隨著業務量的不斷增長，考慮到線下測試結果的準確性，開始嘗試生產壓測，這種壓測手段，我們稱之為引流壓測。事實上沒有真正的模擬放大壓力進行測試，而是一種通過縮小線上服務叢集數的方式來放大單機處理量。比如一個業務系統的叢集有100個節點，將其中90個節點模擬下線或轉發流量到剩餘的10個節點上實施壓測，如圖所示。
引流壓測的弊端在於，DB承受壓力不變，上下游系統的壓力不變。壓測結果僅能代表單個應用的效能，但往往無法識別鏈路和架構級的隱患，而且在引流過程中倘若出現異常或突如其來的業務高峰，很容易造成生產故障。
全鏈路壓測
隨著壓測技術和手段的不斷演進，在2014年初，全鏈路壓測的方法開始誕生，其目標是希望在大型促銷活動來臨前，可以在生產環境上模擬路演進行驗證整體容量和穩定性。由此，出現了全鏈路壓測方法所涉及的公網多地域流量模擬、全鏈路流量染色、全鏈路資料隔離、全鏈路日誌隔離、全鏈路風險熔斷等關鍵技術。
多地域流量模擬技術是指，通過全國各地CDN節點模擬向生產系統施加壓力，並在壓測過程中對生產系統健康度進行實時監控，快速識別壓測對生產業務帶來的風險，立即作出流量調節或熔斷決策。
全鏈路壓測改造的四大核心能力
- 全鏈路流量染色，通過壓測平臺對輸出的壓力請求打上標識（如圖），在訂單系統中提取壓測標識，確保完整的程式上下文都持有該標識。
- 全鏈路日誌隔離，當訂單系統向磁碟或外設輸出日誌時，若流量是被標記的壓測流量，則將日誌隔離輸出，避免影響生產日誌。
- 全鏈路風險熔斷，當訂單系統訪問會員系統時，通過RPC協議延續壓測標識到會員系統，兩個系統之間服務通訊將會有白黑名單開關來控制流量流入許可。該方案設計可以一定程度上避免下游系統出現瓶頸或不支援壓測所帶來的風險。
- 全鏈路資料隔離，當會員系統訪問資料庫時，在持久化層同樣會根據壓測標識進行路由訪問壓測資料表。資料隔離的手段有多種，比如影子庫、影子表，或者影子資料，三種方案的模擬度會有一定的差異。
如何做到全鏈路監控分析
全鏈路的監控和分析包括三個層面。第一層是使用者體驗監測，在雲壓測平臺中可以看到使用者的感受，比如響應時間是否隨著壓力的加大而變長。假如耗時突增引發業務下跌，我們將進入第二層監控，快速從使用者體驗側下鑽到生產系統後端鏈路，並快速識別出現問題的服務節點或介面。
依託於以上監控資訊，需要利用相關分析能力快速給出應急決策依據，比如通過重啟解決會有何影響？同時，在故障發生過程中，分析系統將會保留現場，也會繼續下鑽到第三層分析，比如深度追蹤某個介面或方法中的所有執行邏輯耗時，再比如為什麼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。
總結
第一，不能有了生產全鏈路壓測就不做線下壓測；
第二，不是有了生產影子表能力，就可以在生產隨意實施壓測。比如日誌也需要隔離，如果生產日誌和測試日誌混為一體，將會影響大資料分析（如使用者行為分析）。同時生產壓測本身是高風險的行為，所以壓測前中後的生產穩定性風險防控能力也至關重要。