不管是大小公司多少都會有一些效能問題，因為效能這個事情本身就不是絕對的，伴隨著效能事故，總有些效能測試崗位招聘的很急，至少我的職場經歷經常就是剛入職時候壓力特別大，現在的效能測試叫做全鏈路壓測，那什麼是全鏈路壓測呢，跟傳統壓測區別是啥呢？全鏈路最早是阿里提出來的，在2012年的雙11，零點的時候，系統交易成功率不足50%，下單報錯，購物車報錯，並伴隨著大量超賣，後來提出了全鏈路壓測，這篇文章就來聊聊全鏈路壓測的關鍵點。
面試過很多公司，效能測試有很多形態，一般的公司還在工具使用階段，做下簡單的監控，然後出報告，結束，這樣的做法基本就是走個形式，也有的開發團隊相對負責，會在壓測的過程中協助診斷，看看有沒有優化點，一般來說多少會發現一些問題，會有些效果，但是往往大促，又會出現其他問題，leader問不是做過壓測了嗎？你覺得做過，但好像又做得不夠.....
1.什麼是線上全鏈路效能測試：
基於真實的使用者場景，實際線上環境，按照既定流量，對各個業務鏈路進行壓力測試的過程。
2.為什麼要做全鏈路效能測試：
很多公司有線下效能測試，為啥還要做全鏈路呢，能解決一般效能測試的什麼問題呢？我認為在每個環境做效能測試是相互補充的過程，線上下的效能測試，由於機器監控，部署迅速以及相應的許可權充足，我們可以迅速定位到一些效能bug，如記憶體洩漏，死鎖，超賣等問題，但是線下的機器達到的指標不能準確的反饋到線上的實際情況，我們並不能簡單通過一些充滿大量經驗值的公式去推算，這樣的結果和拍腦袋也沒啥太大差異，再加上線下環境大多以分鏈路，模組壓測為主，所以全鏈路壓測在這樣的背景下就誕生了，我們的前提是線上下已經模組壓測完成，無明顯瓶頸的情況下開展，線上上進行鏈路的充分模擬壓測。
3.全鏈路壓測的核心是什麼？
無論何種測試，核心的東西一定是需求分析，那全鏈路效能需求分析的要點是啥呢，和傳統線下效能測試有啥區別呢？
請求資料來源：
在傳統線下效能測試，一般我們拿到介面引數便開始除錯，寫指令碼，按照場景進行測試，而線上我們需要根據實際資料來源統計，包含web端，app端，小程式端等，這個是我們的客戶端資料來源，還有我們的運營商頻寬佔用情況，cdn節點的分佈，這樣就涉及到外網的壓測，外網的壓測相對於內網來說，會增加更多的鏈路或者策略，如白名單機制，防火牆，f5等等，一旦QPS和內網差別較大，這些都需要重點分析。
架構拓撲分析：
線上的部署結構往往比我們測試環境要複雜很多，測試環境往往是線上很小的一個分支或者按照模組進行壓測，但線上各種微服務的依賴叢集，中介軟體，db需要調研的非常清楚，多少伺服器，伺服器上部署例項的情況，這也是做容量測試的基礎之一，每個細節都會影響到壓測的結果，以及分析的準確性，在做效能壓測之前，建議按照模組做好線下鏈路的壓測，不要把重大效能bug留線上上去暴露,舉個例子，如nginx反響代理到gateway再到服務端和資料庫，這是一個基本流程，那在這個基礎上繼續深入，比如你的gateway服務有幾個節點，這麼多節點部署在哪兒，是在一臺伺服器還是多臺伺服器上都是需要考慮的點，下面是我畫的簡圖，略去了ip和節點數量，如果你在企業中實踐，這些都是必備要素，如果你對這些一無所知，基本上還沒有達到效能測試的門檻；
資料分析：
資料分析可以分很多層次，在一般的效能壓測中，我們一般會關注引數化資料和db資料，全鏈路壓測中，還需要關注，redis資料，mq堆積，以及key的大小對實際頻寬的影響，這些都跟中介軟體相關，一旦出現問題，對網站的影響往往是毀滅性的，頻寬這塊往往也是線下區域網測試不能覆蓋的，線上會跨機房呼叫，所以尤其需要關注這塊，下面我在分層說資料分析這塊
1)基礎資料量分析
一般來說基礎資料量我們指的的資料庫預埋量，這個量級一般會參考線上的量級，資料庫資料量10w量級和1000w量級會是一個截然不同的效能表現，很多公司也出現過效能測試環境指標很好，上線之後效能表現很差，就是因為索引缺失在效能環境因為基礎資料太少沒有發現，而上線後才發現的情況。
2)壓測資料量分析
在寫入操作中，資料庫的資料量級會隨著壓測時間不斷增加，我們需要預估好每次效能測試寫入的量級，一般來說可以通過tps*場景執行時間，對資料庫資料量的激增有相應的監控和兜底方案；
3)引數化的資料分析
引數化的資料首先需要參考的就是業務規則，需要什麼樣子的業務資料，從哪兒獲取，取值範圍是什麼，能不能重複，這些點都是需要你一步步去確認的，舉個例子，我們需要不一樣的訂單號，我們通過什麼樣的規則去造，有的同學會用時間戳去代替，那這個規則能不能完全保證不重複呢，這都是需要思考的問題。
效能測試場景分析:
我重點說下，如何將業務模型轉化為效能測試模型；
解釋一下我說的業務模型是啥，一般在效能測試中就是業務中各個介面的訪問量，如下圖a
圖a
這是一個模組中各個介面的呼叫比例，剛開始我們一般只能拿到一個特定時間區域內的訪問量，通過換算才能拿到比例，那拿到比例後，很顯然我們不需要對所有業務都進行效能測試，有很多介面訪問量非常低，但有一種情況，雖然介面訪問量很低，但是很重要，要確定萬無一失，我們也會把他納入到效能的綜合場景執行中，所以根據上面兩個原則，我們去篩選介面組合成為效能綜合場景，一般來說，我們會選取前80%的介面，如果剩餘的20%有非常重要的介面也會納入，組和成為效能測試模型，如下圖b
注意點：
剛剛我說了，我說選取特定的時間點，那這個時間點如何選取呢，大家可能會不假思索的說選區業務訪問高峰唄，在我們實際操作過程中，可能會存在多個業務高峰，按此時，我們就需要把這些業務高峰值都記錄下來，因為他們的比例不可能全部一致，我們需要把每個業務高峰的比例都計算一遍，通過求同存異的原則去篩選，舉個例子，雙11零點的時候，前十分鐘和後十分鐘業務量都很大，而前十分鐘可能新增購物車，瀏覽商品佔絕大多數，零點一過，就是瘋狂的下單操作，我們不太可能用同一套模型去做效能測試，上文中，我還提到選取前80%的介面，這個每家公司的情況不太一樣，具體可以根據實際情況決定，說到這裡，我提一點，很多同學會說你這個場景很複雜，某某公司流量複製，一鍵解決，很顯然神化了，流量複製本身並不難，後面會有章節從測試的角度去做流量複製，難在我們的資料汙染以及系統改造，涉及到技術和文化環境，這些並不只取決於測試團隊。
監控分析：
大多是情況下，我們會做硬體層的監控包括cpu，頻寬，記憶體，磁碟等，然後客戶端進行資料採集，指標一般也通過壓測資料採集，但這些在全鏈路壓測中還是顯得還有基礎，我們需要去通過更多伺服器維度監控，包含各服務叢集的業務指標資料，db層的實時下單資料，容器級別資源監控資料等內容，以及結合健康度指標等，線上上壓測需要設定閾值，儘可能規避線上風險，防止造成使用者流失。
壓測目標的設定：
提到效能測試的目標，很多人會直觀想到不就是看最高處理能力嗎？其實這只是一個方面，我先基於這個方面闡述，對於處理能力我們一般看最重要的三個指標，tps，響應時間，和報錯率，經常會被問到這些指標應該怎麼定，其實這沒有統一的標準，指標是根據你所在公司的監控和實際活動摸索出來的，並不是直接拍腦袋就能決定，下面我說下行業的一些資料，大家對這些有個資料上的印象即可，並非作為標準；
Tps：我所經歷過的一線網際網路核心模組會在1w上下，絕大多數公司在100~1000不等；
響應時間:響應時間是伴隨著tps而變化的，我們在基準測試底線是200ms；
報錯率: 報錯率一般的計算方式是場景中失敗的事務數/事務總數
我們很多公司線上下壓測的時候因無參考資料，可能壓到拐點作為首選目標，而成熟的網際網路公司一定會做線上的容量評估，一般會根據以往業績以及流量相結合，會有一定比例增長的預估，還有通過推送轉化率去評估，個人覺得可以長期做模型去進行資料積累，達到經驗值的參考。
另外效能測試目的的需求也是多樣性的，比如是否超賣，有沒有併發死鎖，72小時穩定性如何，tps是否平穩等，並不是只追求最高處理能力。
流量回放：
首先來說，能做到流量回放的公司很少，這個涉及到系統的改造，關鍵在於資料加工這塊，能達到流量回放，測試的很多前期準備工作會少很多，但同時前期的開發改造任務也非常繁重，在阿里也一個開發團隊封閉改造三個月才有一個雛形版本，任何一家公司都可以引用一種技術型別，但是做的深淺會很不一樣。