深度解析全鍊路壓測實施過程

在開始全鍊路壓測前，還要梳理核心鍊路、準備測試資料、改造系統并進行流量染色。對一些老舊系統實施改造并不容易，往往涉及各種複雜的業務內建，改造成本比較高。

1、核心鍊路梳理

第一步是梳理。梳理系統中的業務場景，并找到支撐和實作業務場景的資訊流的鍊路，這些資訊有助于我們知道要測的是什麼。一般來說，業務系統的場景有很多，使用者當然不會對每個場景都平均地進行通路，是以，做全鍊路壓測時，使用者集中使用的場景對應的服務之間進行調用的鍊路通常是我們要梳理的核心鍊路。這個梳理過程并不難，從調用入口着手找到它需要調用的其他服務接口，隻要明确了這些調用關系，就能得到技術上的核心鍊路。通常還需要和業務分析師一起對核心鍊路進行二次确認，以避免測試過程中出現偏差。這一步梳理過程很重要。

第二步是記錄。将确定好的核心鍊路中的服務調用關系記錄下來，同時記錄下分支業務等資訊，标注出需要參與性能測試的場景，而不需要參與測試的場景也需要做出标注，友善後續工作的跟進。随着業務系統不斷演進改變，核心鍊路相關的文檔也需要及時更新。

第三步是隔離。對核心鍊路中不能參與性能測試的部分要進行隔離，例如第三方的支付接口、短信網關接口、物流運輸系統等，這些系統的性能需要第三方自己去保證。在進行隔離時，可以考慮把第三方系統替換成按照接口契約Mock出的系統。

2、準備測試的資料

在産品環境下的全鍊路壓測通常使用的是線上的真實資料，線上資料的多樣性可以讓測試涵蓋系統中更多的被測場景和代碼路徑。當然，在使用真實資料時需要對它們做脫敏處理。線上資料的擷取方式主要如下。

• 抽取系統日志，還原使用者的通路請求并在系統中進行回放。高峰時段日志更具有測試代表性。
• 用SQL腳本從産品環境下的資料庫抽取資料并進行改造，改造後的資料可以作為壓測資料。線上資料包含各種使用者敏感資訊，如身份證号、手機号、家庭住址等，測試前要對這些資料進行脫敏處理（對資料進行批量替換、增加随機數等）。除此之外，線上資料還包含臨時Token等資訊，需要将其替換成長時間有效的Token，才能被系統反複使用和執行。

全鍊路壓測中，性能鋪底資料的量級應該和産品環境下的資料量級保持一緻，還要結合線上業務增長率，提前準備半年或者一年的資料量。如果是新業務上線，可能暫時沒有線上資料作為參考，那麼就需要人工預測鋪底資料的量級了。性能測試資料需要定期清理，一般我們采用編寫腳本的方式進行自動化清理。長時間不清理的話，測試結果是會受影響的。

3、改造系統并進行流量染色

在測試環境中做性能測試時，自然不需要擔心測試過程對産品環境的使用者造成影響，也不需要考慮測試資料的隔離。而在産品環境中，必須對測試資料進行隔離，否則會污染線上資料，這一點我們反複提過很多次了。如何實作測試資料不影響産品環境的資料呢？需要通過對性能測試請求增加染色辨別來區分測試請求和真實請求。

對于微服務系統常用的HTTP調用接口來說，在HTTP請求的Header中添加特殊标記，以提示HTTP伺服器這是測試請求，這種方式是個不錯的選擇，不影響請求資料，侵入性也是極小的。當使用其他協定發送請求給微服務系統時，也可以使用這一思路。

HTTP伺服器端在接收到包含染色辨別的請求後，會立刻把請求轉發給業務處理子產品，這些子產品涉及緩存層、線程池、資料庫、日志等環節，要對這些子產品做相應改動，來保證帶有測試标記的請求和産品環境資料分離開。在處理過程中要防止測試标記丢失，因為标記一旦丢失，後續處理子產品就無法區分資料的實際身份到底是測試資料還是真實使用者資料，這将直接影響到産品環境下的使用者使用體驗。

全鍊路壓測改造的系統涉及HTTP伺服器、應用程式的代碼、消息隊列、緩存層、資料庫等環節，最終把測試資料寫入影子表、影子日志目錄。在改造過程中，首先要識别出讀接口和寫接口。讀接口不涉及測試資料的隔離操作，隔離主要是針對寫接口的。改造的内容主要包括以下幾方面。

• 線程池。以Java語言為例，當測試請求進入線程池後，要把測試标記寫入線程的ThreadLocal變量中，友善測試辨別跟随線程傳遞到下個處理環節。
• 緩存層。緩存層存儲了大量使用者經常通路的資料，可以加快使用者通路速度。測試過程中産生的資料可能會把使用者正在使用的緩存資料沖掉，是以我們有必要隔離出緩存伺服器并把測試資料寫進去，從實體上将測試資料和真實業務資料分離開。
• 影子庫和影子表。對資料庫的改造有兩種方案—影子表和影子庫，具體選擇使用哪一種則應根據實際情況來。

影子表建立在産品資料庫中，複制産品資料庫對應表的結構，同時保證同樣數量級的初始資料。一般我們在影子表名稱後加特殊字尾以進行區分。建立影子表不但成本較低，也不用單獨購買資料庫的使用授權。然而由于影子表和業務表共享記憶體等資源，這又會導緻測試過程中可能對産品環境産生一定影響。

影子庫，是我們建立的一個獨立的、和産品環境相同的資料庫。因為它是獨立的，是以在測試過程中對産品環境資料庫的影響很小。也正因為獨立，它需要購買資料庫使用權，并且搭建對應的硬體基礎設施，導緻投入成本較高。

• 消息隊列。當測試資料進入消息隊列時，會出現兩種可能：一是根據業務情況做丢棄處理；二是帶着測試标記傳遞到其他子產品進行處理。
• 日志子產品。當測試日志和真實使用者日志混在一起時，分析和排查起來相當麻煩，我們通過建立影子日志目錄對日志子產品進行改造，友善區分測試日志資料和真實日志資料。
• 搜尋引擎等子產品。搜尋引擎或者BI（Business Intelligence，商業智能）分析系統，會讀取産品資料庫，掃描和抽取資料。在這個過程中，要防止影子表、影子庫的資料被掃描到。

系統改造過程中，任何一個環節的遺漏都有可能造成測試标記丢失，為了避免測試過程中出現辨別遺漏現象，對測試資料的隔離效果也要進行驗證。正式開始全鍊路測試前，先在測試環境進行全面的演練測試，確定性能測試過程符合設計預期。驗證的過程分為4步。

1. 在測試環境驗證單次請求：把改造完的系統部署在測試環境，發送單次請求驗證測試标記的流轉是否符合預期，以及寫入資料是否進入了影子表、影子日志目錄。
2. 在測試環境驗證多線程請求：從産品環境抽取資料并做脫敏處理，把這些資料用在測試環境中，使用多線程并發測試。線上資料的多樣性可以讓測試覆寫更多的代碼路徑。
3. 在産品環境驗證單次請求：由于線上環境和測試環境存在配置等差異，是以在産品環境測試時，也需要先發送單次請求進行驗證，確定線上各個環節對測試資料做到準确隔離。
4. 在産品環境驗證多線程請求：使用線上脫敏後的資料在産品環境做性能測試。測試前要對所有資料進行備份，確定測試出現問題時能夠及時恢複資料。

4、測試過程和測試監控

在産品環境下做全鍊路壓測時，盡管我們選擇的是業務低峰時段，但在整個壓測過程中仍需随時關注系統的各項名額，避免影響線上使用者的正常使用。執行時我們通常選擇平滑加壓的測試方式，而不是一開始就把測試請求全部發送出去，這是為了避免系統被壓垮。在接下來的測試過程中，一旦系統出現異常行為，如響應過慢或者錯誤率超過預期标準，就要及時停止增加通路流量，并對異常問題進行排除。

5、異常處理方案的驗證