相關背景

傳統效能測試更多的是以事務為核心，更多的是由單個或者多個事務構成業務場景進行壓測。全鏈路壓測指完全引入相關聯的系統，儘量真實模擬線上硬體環境，更多的是以請求為核心，完全模擬真實請求流量，通過引流等方式進行場景的模擬進行壓測，更多的適用於業務鏈路較長的交易。全鏈路一直是效能測試中的難點，其包含系統越多測試難度就越大，系統架構中每增加一層的監控內容就會給分析帶來幾何倍數的難度。因此，微服務架構下的效能測試的重要性就不言而喻了。

微服務架構下為什麼做全鏈路壓測

微服務系統系統間呼叫關係複雜，當出現業務流量暴漲的情況從CDN、閘道器接入、前端、快取、中介軟體、後端服務、資料庫整個交易鏈路都會面臨巨大的訪問壓力，此時業務系統除了收到自身的影響還會依賴其他關聯絡統的情況，如果某一點出現問題，系統會累加問題並影響到其他其他系統，到時候是哪個系統出問題誰也說不出清楚，比如黑少微服務商店，當某系統MQ開始出現積壓，下游系統處理能就可能會變慢，當MQ吃掉記憶體並造成宕機，整個鏈路交易都會停止。

微服務架構下全鏈路壓測的難點

如果在測試環境進行全鏈路壓測，最大難點在於無法評估使用者從客戶端登入到完成交易的整個鏈路中，系統能的最大承載能力是多少。如果無法承載生成中的流量造成系統宕機，就會有災難性的後果。所以在測試環境進行全鏈路要結合歷史生成流量，併合理做出業務增長預估，如果能滿足此流量可以判定為生產環境滿足效能要求。當然，這只是權宜之計，如果在生產環境做全鏈路壓測不會出現此情況。

另外，全鏈路壓測涉及的微服務模組多，開發組多，各組開發人員又各負責自己的模組，因為版本升級塊，業務層架構變化也快，很難能瞭解清楚最新的架構，如果漏掉一個系統的呼叫關係，分析就會變得非常困難。

軟體的版本控制問題，因為版本升級快，造成測試環境與生成環境程式碼版本不一致，資料庫表結構和索引不一致的情況。這種情況會造成測試結果不準確，重複測試。多系統更難控制此情況。

微服務架構下如何開展全鏈路測試

開展全鏈路壓測，除了傳統效能測試的需求調研、環境準備、指令碼開發、資料預埋、場景設計、場景執行、應用監控分析、瓶頸定位、瓶頸修復、迴歸測試、結果整理、輸出報告等環節外還要加入分析需壓測業務場景涉及系統和協調各個壓測系統資源兩個環節。

1、梳理核心鏈路

在壓測前我們一定要首先分析清楚需要壓測的業務場景，只有分析清楚了業務場景才能梳理出來涉及的相關係統，分析清楚後也可以更快的找到效能瓶頸進行系統優化。這個工作一般是由架構師來梳理並確認涉及的相關係統，梳理清楚後就可以反饋給壓測負責人進行人員和資源的協調了。

2、壓測資源協調

在全鏈路壓測過程中，最難的工作其實不是系統優化、壓測環境搭建等技術工作，最難的是壓測資源的協調工作。這裡的資源不單單指壓測硬體、軟體、環境等資源，還包括了人力資源。

3、構建資料

資料的真實和可用是保證壓測結果的關鍵，儘量使資料多元化，引數重複性低，可以採用生產資料脫敏的方式。資料的真實性可以保證更真實的模擬生產資料流量。資料的真實不光指發起的資料，測試資料庫的鋪底資料量也要與生產一致。

4、流量監控

搭建流量監控平臺，收集生產各種業務的流量，統計資料，按比例進行流量回放。

5、容量評估

首先知道容量目標是多少，比如全部交易量預期目標每天1億筆，按流量平臺監控到的業務佔比進行壓測，這樣我們可以清楚在哪個節點應該增加多少機器，既能保證系統的穩定又能避免浪費。容量評估不是一步完成的，目標需要結合歷史資料和公司現有業務規模。第一步先按現有環境摸底測試，再逐步增加或減少機器，迴圈多次，最後達到精準的容量評估。

微服務架構下全鏈路壓測優化

1、單系統優化

把鏈路中逐個環節儘量切分成小塊，粒度越小越佳，單粒度分析，涉及其他系統加擋板，這樣可以基本解決所有效能問題。缺點是效能週期長。

2、架構優化

分析系統架構，在硬體資源不飽和情況下儘量減少架構層。筆者在測試中遇到一個案例，A系統呼叫加解密伺服器，A系統因特殊原因執行緒固定300，不能增加執行緒，併發執行緒為300時，A系統伺服器CPU為60%，TPS為370左右，CPU資源不飽和，加解密伺服器cpu為50%，也不飽和，但因A系統不能調整執行緒數量，所以把加解密服務的包部署在A系統上，此時300併發，A伺服器CPU為100%，TPS為700左右。這樣的好處是減少了一層系統呼叫的連線時間，資料傳輸時間，又能使硬體充分利用，減少硬體的浪費。

3、業務優化

很多開發人員都會將優化思路集中在架構層面，但是很多時候從業務流程上進行優化效果可能更好，而且提升的效果會非常明顯。業務優化不包括業務流程本身，還包活實現業務的程式碼邏輯，此優化場景多用於跑批業務。