全鍊路壓測分析（純幹貨）

最近網傳，微信支付崩了，哈羅出了問題，部分公司性能測試架構師招聘又開始火熱起來，現在都叫做全鍊路壓測，那什麼是全鍊路壓測呢，跟傳統壓測差別是啥呢？全鍊路最早是阿裡提出來的，在2012年的雙11，零點的時候，系統交易成功率不足50%，下單報錯，購物車報錯，并伴随着大量超賣，後來提出了全鍊路壓測，這篇文章就來聊聊全鍊路壓測的關鍵點。

面試過很多公司，性能測試有很多形态，一般的公司還在工具使用階段，做下簡單的監控，然後出報告，結束，這樣的做法基本就是走個形式，也有的開發團隊相對負責，會在壓測的過程中協助診斷，看看有沒有優化點，一般來說多少會發現一些問題，會有些效果，但是往往大促，又會出現其他問題，leader問不是做過壓測了嗎？你覺得做過，但好像又做得不夠.....

1.什麼是線上全鍊路性能測試：

基于真實的使用者場景，實際線上環境，按照既定流量，對各個業務鍊路進行壓力測試的過程。

2.為什麼要做全鍊路性能測試：

很多公司有線下性能測試，為啥還要做全鍊路呢，能解決一般性能測試的什麼問題呢？我認為在每個環境做性能測試是互相補充的過程，線上下的性能測試，由于機器監控，部署迅速以及相應的權限充足，我們可以迅速定位到一些性能bug，如記憶體洩漏，死鎖，超賣等問題，但是線下的機器達到的名額不能準确的回報到線上的實際情況，我們并不能簡單通過一些充滿大量經驗值的公式去推算，這樣的結果和拍腦袋也沒啥太大差異，再加上線下環境大多以分鍊路，子產品壓測為主，是以全鍊路壓測在這樣的背景下就誕生了，我們的前提是線上下已經子產品壓測完成，無明顯瓶頸的情況下開展，線上上進行鍊路的充分模拟壓測。

3.全鍊路壓測的核心是什麼？

無論何種測試，核心的東西一定是需求分析，那全鍊路性能需求分析的要點是啥呢，和傳統線下性能測試有啥差別呢？

請求資料源：

在傳統線下性能測試，一般我們拿到接口參數便開始調試，寫腳本，按照場景進行測試，而線上我們需要根據實際資料源統計，包含web端，app端，小程式端等，這個是我們的用戶端資料來源，還有我們的營運商帶寬占用情況，cdn節點的分布，這樣就涉及到外網的壓測，外網的壓測政策和内網細節上的差别還是比較大的，本文不作具體讨論。

架構拓撲分析：

線上的部署結構往往比我們測試環境要複雜很多，測試環境往往是線上很小的一個分支，線上各種微服務的依賴叢集，中間件，db需要調研的非常清楚，多少伺服器，伺服器上部署執行個體的情況，每個細節都會影響到壓測的結果，以及分析的準确性。

資料分析：

資料分析可以分很多層次，在一般的性能壓測中，我們一般會關注參數化資料和db資料，全鍊路壓測中，還需要關注，redis資料，mq堆積，以及key的大小對實際帶寬的影響，這些都跟中間件相關，一旦出現問題，對網站的影響往往是毀滅性的，帶寬這塊往往也是線下區域網路測試不能覆寫的，線上會跨機房調用，是以尤其需要關注這塊。

監控分析：

大多是情況下，我們會做硬體層的監控包括cpu，帶寬，記憶體，磁盤等，然後用戶端進行資料采集，名額一般也通過壓測資料采集，但這些在全鍊路壓測中還是顯得還有基礎，我們需要去通過更多伺服器次元監控，包含各服務叢集的業務名額資料，db層的實時下單資料，容器級别資源監控資料等内容，以及結合健康度名額等，線上上壓測需要設定門檻值，盡可能規避線上風險，防止造成使用者流失。

壓測目标的設定：

我們很多公司線上下壓測的時候因無參考資料，可能壓到拐點作為首選目标，而成熟的網際網路公司一定會做線上的容量評估，一般會根據以往業績以及流量相結合，會有一定比例增長的預估，還有通過推送轉化率去評估，個人覺得可以長期做模型去進行資料積累，達到經驗值的參考。