性能測試之線上引流測試--讓性能測試更真實更豐富 - andashu－IT工程師數位筆記本

文章出處

為什么要做引流測試

目前為止大部分的測試是在測試環境下，通過模擬用戶的行為來對系統進行驗證，包括功能以及性能。在這個過程中，你可能會遇到以下問題:

用戶訪問行為比較復雜，模擬很難和用戶行為一致，模擬不夠真實;
線下模擬場景有限，會出現業務覆蓋不全的情況。
引流測試就是為了解決以上問題，通過把線上的真實流量復制到線下環境，解決測試環境模擬不夠真實，或覆蓋不夠全面的問題。

引流的做法

目前不少公司對引流測試進行了實踐，主要有以下4種引流方式：

以上幾種辦法各有利弊，有的是需要自己開發相應的工具來支持。在做URS產品性能測試過程中，考慮到都是HTTP類型的請求，且大部分的請求為讀請求，使用tcpcopy工具可以滿足要求，且成本比較低。在介紹基于tcpcopy的引流測試在項目中怎么應用之前，我們先來介紹下tcpcopy這個工具。

tcpcopy介紹

tcpcopy是一種請求復制(基于tcp的packets)工具，其應用領域較廣。tcpcopy主要有如下功能：

分布式壓力測試工具，利用在線數據，可以測試系統能夠承受的壓力大小,同時提前發現一些bug;
對于后端的短連接，請求丟失率非常低(1/10萬)，可以應用于熱備份;
普通上線測試，可以發現新系統是否穩定，提前發現上線過程中會出現的諸多問題，讓開發者有信心上線;
對比試驗，同樣請求，針對不同或不同版本程序，可以做性能對比等試驗;
利用級聯tcpcopy，構造無限在線壓力，滿足中小網站壓力測試要求。

圖1 tcpcopy工具流量復制過程

在線服務器啟動tcpcopy進程，在IP層捕獲數據包，通過數據鏈路層發包;
復制的包到了被測試服務器，經過協議棧的處理，到達應用進程，進程處理完，響應的包通過路由轉發給輔助服務器;
輔助服務器捕獲到路由過來的響應包，去掉包的body，返回給在線服務器。

整個過程是一個閉環，引流的過程不會干擾用戶的請求，復制的請求的響應，也不會返回給用戶。

URS引流測試實踐

接下來講述下tcpcopy是怎么在URS這個產品中運用起來的，通過下面的案例來分享下整個引流測試的過程。

案例：本人經歷過一個項目主庫的性能驗證，優化及替換

背景介紹：

該產品的線上數據庫服務器年限比較長，配置比較老，另外數據庫服務器在瞬時訪問量比較大的時候，會出現性能下降的問題。為了提高數據庫服務器的穩定性，以及對數據庫的參數進行一些優化，產品方計劃采用新的數據庫服務器來代替線上服務器，且在上線先進行一輪優化，保證新的數據庫滿足目前的性能需求的情況下，再替換掉線上的數據庫。

測試的難點

新數據庫的數據量基本要和線上是一致的，否則測試的意義不大；
僅僅依靠線下的請求模擬是不夠的，需要線上真實的流量來驗證；
需要提供突發流量，高于線上的流量等場景來驗證新的數據庫服務器是否能夠處理突發情況。、

測試方法

利用tcpcopy工具，搭建引流測試環境，利用線上真實流量，倍數流量，突發流量，驗證新的163主庫的性能，并與DBA協作，進行參數優化和驗證。

測試成果

通過復制真實流量，有效驗證了現有數據庫的性能，并且通過調整流量，對數據庫造成多樣的負載，進而對數據庫進行參數優化，保證了數據庫的性能和穩定性

引流測試方案

為確保引流測試順利實施，先制定一個詳細的方案，方案主要包括業務選取，環境搭建，結果分析和驗證等，接下來逐一介紹這些部分。

測試環境搭建

需要先根據線上環境部署架構來確定我們的引流測試環境應該搭建成什么樣子。下面為引流環境架構示意圖。先簡單介紹下：

環境部署如下：

圖2 測試環境部署

線上Nginx服務器上安裝部署tcpcopy，負責把指定的流量復制到測試環境；
引流環境的數據庫通過導入線上的數據庫的備份初始化數據，同時通過做成線上的備庫，保持和線上數據庫的同步。每次要開展引流測試的時候，先剝離出來，做完測試之后再和線上數據庫進行同步；
為了避免引流操作更新部分緩存，導致弄臟了線上的緩存數據，同時為了控制穿透到數據庫的量，搭建了單獨的緩存服務器集群；
搭建mock服務器，把短信，郵件，將軍令等服務都mock掉，避免觸發到這些操作，影響用戶，另外也可以通過在前端Nginx進行請求過濾，來屏蔽可能觸發這些操作的請求。

引流業務選取及過濾

環境搭建好以后，需要確定復制哪些請求到測試環境，以下三類請求是不建議引流的，需要屏蔽掉。

無法處理的請求
測試環境因為缺少數據或者缺少外圍系統等，導致這類請求在測試環境執行會報錯，因此需要過濾掉。
連續相關的請求，或者有狀態的請求
連續相關的請求因為存在狀態，請求之間的數據有傳遞，導致復制過去的話，業務處理會報錯，也需要過濾掉。舉個簡單的例子，比如登錄操作，服務端可能會需要填寫驗證碼，復制過來的請求的驗證碼和原始的請求是不一樣的。如果登錄操作也復制過去了，驗證碼是無效的。
寫請求
寫請求會新增數據，且一般寫請求的量比較小，請求大都有狀態，不是很適合引流。如果寫請求的影響很小，也需要進行寫請求的測試，也可以進行復制，但是要特別注意，不要弄臟線上環境的數據，或者對線上的業務有影響。

請求過濾可以通過以下方式實現：

Nginx配置Location進行過濾
```
location ~* ^/services/(otplogin|onlyotplogin|qrcodeotpauth|onlyotplogin|ticketotpauth) {
 expires -1;
 return 200 'request mocked\n';
}
```
把需要屏蔽的請求，直接返回200。這里要經過仔細篩選。上面的配置只是一個示例，實際項目可以按照規則來過濾。
搭建mock服務器進行過濾請求的處理過程中，如果會調用第三方系統，這個時候可以搭建mock服務進行屏蔽。

引流測試執行

環境準備好之后，就可以執行引流測試了，引流測試過程會包含以下步驟：

配置檢查

Nginx的Location配置，避免復制了不合適的請求到測試環境；
應用配置是否正確，一切會影響線上用戶的配置都需要調整；
緩存服務器的配置是否正確，確認使用的是測試環境的實例，且能正常訪問；
數據庫的配置是否正確，確認使用的是測試數據庫，且能正常訪問；
Mock服務器是否正常，服務的返回是否正常等；
以上檢查完成后，在測試的Nginx上利用curl工具手動發送請求驗證環境。

啟動輔助服務器intercept

啟動命令
```
sudo ./bin/intercept  -i 網卡  -F 'tcp and src host ${測試Nginx IP地址}  and src port  ${測試Nginx端口} ' -p  ${intercept的監聽端口}  -d
```
可以不指定監聽端口使用默認的36524，如果要啟動多個實例，端口是必須指定。啟動后通過netstat –an | grep 監聽端口，檢查端口是否正常。
檢查error_intercept.log日志文件檢查文件有沒error和fatal級別的錯誤信息。
綁定在不同的CPU上
如果intercept進程的CPU使用率比較高，需要啟動多個intercept并且綁定在不同CPU上，可以通過執行 taskset -cp ${cpu $pid來設定，其中

cpu為CPU的編號，

pid為intercept的進程號。

配置路由并驗證

在測試環境的Nginx上增加默認網關，設置為intercept的地址：命令：route add default gw ${intercept的IP} 設置好路由信息后，可以找一臺測試機器，telnet測試環境Nginx的服務端口80，如果能夠建立連接，說明路由信息沒生效，測試環境Nginx服務器的包沒有轉發給輔助服務器，可以找SA的同事幫忙協助，確定路由要怎么配置。

啟動tcpcopy

在線上Nginx服務器，啟動tcpcopy命令：

sudo bin/tcpcopy -F 'dst port ${線上nginx端口} and dst host ${線上nginx IP} '  -i  網卡 –x  ${線上nginx端口} -${測試環境nginx的IP}:{測試環境nginx端口} -s ${intercept的IP} -n 1 -d

啟動后，檢查error_tcpcopy.log日志文件有無error和fatal級別的錯誤。

請求驗證

對線上nginx和測試nginx的日志進行對比，檢查請求是不是已經復制到測試環境，請求返回的大小和狀態碼等是否正常，同時，檢查應用服務器是否有錯誤日志。如果有錯誤，影響到了線上環境，或者錯誤很多，先停止引流，解決報錯。

系統監控

引流過程中，可以利用哨兵系統對線上Nginx服務器，測試服務器的系統資源，應用服務器、數據庫進行性能監控。

調整流量

引流過程中，會根據測試環境的負載，調整復制的流量，通過修改tcpcopy的啟動參數來調整。-n 設置復制的倍數，-r 可以設置復制的比例(1<r<100)。

引流測試結果分析

前面的章節介紹了引流的方案和執行過程。引流開始后，我們怎么去分析系統當前的性能呢？在數據庫的性能驗證的案例中，我們一方面要知道當前的業務負載情況，同時也需要知道應用和數據庫的各項資源的使用情況。

如何監控業務指標

業務性能指標，主要是通過對nginx的日志進行分析來完成，分析能夠監控到所有請求，以及單個請求的TPS，錯誤，平均響應時間，最大響應時間4個重要的指標。

圖3 業務指標監控

例如在圖3中，可以實時監控到***login這個接口的TPS，ERRORS，AVG_RT，MAX_RT四個指標。

如何監控數據庫

數據庫可以通過在類似于zabbix系統進行配置性能監控。引流過程中，可以實時監控數據庫的各項性能指標，觀察是否有異常，進而調整復制的流量。 系統資源指標：CPU，內存，網絡，磁盤等常規資源監控指標。 數據庫性能指標：數據庫各內存池使用率和命中率，Average active session，Database Time Ratio，會話連接數，IO讀寫吞吐量，IO讀寫請求次數，執行次數，資源使用率等。
通過監控這些指標，定位數據庫的性能瓶頸，讓DBA進行優化和調整，再復測。找出最佳的配置。這些性能指標，我們可以通過哨兵系統來實時監控。

例如，我們在引流過程中監控到的連接數，活躍的會話，內存池的使用情況如圖4所示：