最近網傳，微信支付崩了，哈羅出了問題，部分公司性能測試架構師招聘又開始火熱起來，現在都叫做全鏈路壓測，那什麼是全鏈路壓測呢，跟傳統壓測區別是啥呢？全鏈路最早是阿里提出來的，在2012年的雙11，零點的時候，系統交易成功率不足50%，下單報錯，購物車報錯，並伴隨著大量超賣，後來提出了全鏈路壓測，這篇文章就來聊聊全鏈路壓測的關鍵點。
面試過很多公司，性能測試有很多形態，一般的公司還在工具使用階段，做下簡單的監控，然後出報告，結束，這樣的做法基本就是走個形式，也有的開發團隊相對負責，會在壓測的過程中協助診斷，看看有沒有優化點，一般來說多少會發現一些問題，會有些效果，但是往往大促，又會出現其他問題，leader問不是做過壓測了嗎？你覺得做過，但好像又做得不夠.....
1.什麼是線上全鏈路性能測試：
基於真實的用戶場景，實際線上環境，按照既定流量，對各個業務鏈路進行壓力測試的過程。
2.為什麼要做全鏈路性能測試：
很多公司有線下性能測試，為啥還要做全鏈路呢，能解決一般性能測試的什麼問題呢？我認為在每個環境做性能測試是相互補充的過程，在線下的性能測試，由於機器監控，部署迅速以及相應的權限充足，我們可以迅速定位到一些性能bug，如內存洩漏，死鎖，超賣等問題，但是線下的機器達到的指標不能準確的反饋到線上的實際情況，我們並不能簡單通過一些充滿大量經驗值的公式去推算，這樣的結果和拍腦袋也沒啥太大差異，再加上線下環境大多以分鏈路，模塊壓測為主，所以全鏈路壓測在這樣的背景下就誕生了，我們的前提是在線下已經模塊壓測完成，無明顯瓶頸的情況下開展，在線上進行鏈路的充分模擬壓測。
3.全鏈路壓測的核心是什麼？
無論何種測試，核心的東西一定是需求分析，那全鏈路性能需求分析的要點是啥呢，和傳統線下性能測試有啥區別呢？
請求數據源：
在傳統線下性能測試，一般我們拿到接口參數便開始調試，寫腳本，按照場景進行測試，而線上我們需要根據實際數據源統計，包含web端，app端，小程序端等，這個是我們的客戶端數據來源，還有我們的運營商帶寬佔用情況，cdn節點的分佈，這樣就涉及到外網的壓測，外網的壓測策略和內網細節上的差別還是比較大的，本文不作具體討論。
架構拓撲分析：
線上的部署結構往往比我們測試環境要複雜很多，測試環境往往是線上很小的一個分支，線上各種微服務的依賴集群，中間件，db需要調研的非常清楚，多少服務器，服務器上部署實例的情況，每個細節都會影響到壓測的結果，以及分析的準確性。
數據分析：
數據分析可以分很多層次，在一般的性能壓測中，我們一般會關注參數化數據和db數據，全鏈路壓測中，還需要關注，redis數據，mq堆積，以及key的大小對實際帶寬的影響，這些都跟中間件相關，一旦出現問題，對網站的影響往往是毀滅性的，帶寬這塊往往也是線下局域網測試不能覆蓋的，線上會跨機房調用，所以尤其需要關注這塊。
監控分析：
大多是情況下，我們會做硬件層的監控包括cpu，帶寬，內存，磁盤等，然後客戶端進行數據採集，指標一般也通過壓測數據採集，但這些在全鏈路壓測中還是顯得還有基礎，我們需要去通過更多服務器維度監控，包含各服務集群的業務指標數據，db層的實時下單數據，容器級別資源監控數據等內容，以及結合健康度指標等，在線上壓測需要設置閾值，儘可能規避線上風險，防止造成用戶流失。
壓測目標的設定：
我們很多公司在線下壓測的時候因無參考數據，可能壓到拐點作為首選目標，而成熟的互聯網公司一定會做線上的容量評估，一般會根據以往業績以及流量相結合，會有一定比例增長的預估，還有通過推送轉化率去評估，個人覺得可以長期做模型去進行數據積累，達到經驗值的參考。
流量回放：
首先來說，能做到流量回放的公司很少，這個涉及到系統的改造，關鍵在於數據加工這塊，能達到流量回放，測試的很多前期準備工作會少很多，但同時前期的開發改造任務也非常繁重，在阿里也一個開發團隊封閉改造三個月才有一個雛形版本，任何一家公司都可以引用一種技術類型，但是做的深淺會很不一樣。
閱讀更多 測試開發圈子 的文章
