tcp壓測工具_掌門全鍊路灰階壓測實戰

灰階背景

随着掌門使用者數量，業務的快速疊代，服務釋出出現的事故影響面越來越大，有可能是新業務流程與老業務流程的互相相容的問題，或者是前後端一些較小的手誤導緻應用故障(中台受此風險的影響更大)。

在不斷的挖坑填坑中，我們總結出以下的問題：

• 影響範圍不可控。一旦釋出到生産，特别是一些特别重要的服務的釋出，如登入、首頁、組織架構、消息中心等。這些服務一旦出問題，會導緻将近90%業務不可連續。
• 釋出後驗證的時間節點。為了保證上線後第一時間進行生産驗證，一般在非業務高峰期(半夜12點後)進行釋出和回歸驗證。深夜釋出，不僅參與發版的開發，測試和運維同學較為疲勞，而且釋出過程中遇到的各種小問題導緻釋出完成大多在深夜2點，這個時候因為釋出人員都比較疲勞，在進行線上回歸驗證時難以保持足夠的警惕心，容易産生漏測的情況。
• 問題回報不易，出現生産問題後，隻能通過被動的投訴來發現問題，開發人員疲于奔命，産品還要遭到差評。

灰階方案

針對以上背景，測試需要對已有的兩套方案分别進行壓測。綜合評估，選取最優方案作為公司内部使用。

• 方案一：Java Agent
• 方案二：Solar(Java SDK)

Java Agent ：是運作在 main方法之前的攔截器，内定的方法名是 premain ，原理是先執行 premain 方法然後再執行 main 方法。在加載java檔案之前做攔截修改位元組碼，實作了按流量比對灰階和按條件比對灰階2種方式。

Java SDK：Solar運用SDK實作了基于http header傳遞和規則訂閱的全鍊路釋出。采用配置中心配置路由規則映射在網關過濾器中植入Header資訊，路由規則傳遞到全鍊路服務中而實作。灰階路由方式主要有：多版本比對灰階和多版本權重比對灰階。

Java Agent：

1.按流量比對灰階：

支援完全随機和路徑随機，通過規則中設定百分比實作。如：

參數來源	參數	流量比
header	gray	30

2.按條件比對灰階：

支援header，param，cookie，body參數來源，通過設定equals，in，notIn，range， startWith，endWith條件，配置的key，value的值。如：

參數來源	參數	條件	條件值
header	gray	in	1

隻要請求滿足規則配置，則路由灰階機器，否則路由common 機器。

路由架構圖：

Solar(Java SDK):

1.多版本比對灰階

灰階和common環境分别是2個不同版本号，配置中設定某個服務路由哪個版本号，配置檔案中這樣配置：

2.多版本權重比對灰階  

配置中設定不同版本的權重(流量比例)，配置檔案中這樣配置：

按服務指定版本号和權重路由對應權重到版本号。

路由架構圖：

業務拓撲圖

公司業務複雜度請參考下圖，這是内部某業務的局部拓補圖：

由于業務調用鍊的複雜性，為了盡可能覆寫生産場景，又要做到不備援。測試設計選用了1個網關+2個微服務的政策進行壓測，詳情見下文。

壓測政策

1.壓測階段：內建測試-系統測試-驗收測試-回歸測試-性能測試

2.壓測方法：邏輯覆寫法、基本路徑測試法，場景法等

3.壓測機器：所有執行個體選用阿裡雲獨享型機器(1個網關+2個微服務)

多核獨享	CPU	Memory	Environment	個數(台)
壓測機	4C	8G	UAT	1
網關	8C	16G	UAT	1
微服務A	4C	8G	UAT	3
微服務B	4C	8G	UAT	4

4.壓測分類：spring cloud原生，加包無灰階，加包有灰階

5.壓測鍊路：網關-A-B，A-B

6.壓測規則：為了保持2個方案條件一緻性，統一選用權重30%的灰階流量作為規則

7.壓測工具：

不是大家喜聞樂見的jMeter而是wrk。由于wrk具有一個良好的特性：很少的線程能夠壓出很大的并發量

以下是jmeter與wrk的實作原理的對比：

-------------------------------------------------------------------------------------------------------

其次，在同等壓力下，wrk占用的資源遠遠小于jMeter，故本次壓測中我們采用了wrk

簡單介紹一下wrk的用法：

wrk配合lua腳本使用，屬于指令行工具。指令格式：

./wrk -c1 -t1 -d10m -T8s -s ./scripts/wrk.lua --latency "http://10.25.174.21:8080"

參數解析：

8.壓測參數：

9.壓測腳本：

10.壓測傳回：為了避免處理複雜的邏輯，設計隻傳回一行簡單的字元串

壓測資料統計

壓測QPS	G-A-B	A(1台)-B
spring cloud原生	5434	7850
agent無灰階	5223	7652
agent有灰階	4957	6174
無灰階性能下降百分比(和spring cloud 原生比較)	-3.88%	-2.52%
有灰階性能下降百分比(和spring cloud 原生比較)	-8.77%	-21.35%
-----	-----	-----
spring cloud 原生	6244	5529
solar無灰階	6120	5100
solar有灰階	5830	4600
無灰階性能下降百分比(和spring cloud 原生比較)	-1.98%	-7.75%
有灰階性能下降百分比(和spring cloud 原生比較)	-6.63%	-16.80%

故障分析

測試過程中發現，同樣的腳本，同樣的場景，同樣的參數在不同時間點，timeout個數較多，QPS波動較大，且qps較低，始終達不到預期。根據問題采取如下措施逐漸得以解決(以原生為例)：

1. 分别在源和目标主機同時抓包：

   tcpdump -i any host x.x.x.x -w /x/x.pcap

   ，分析比較有沒有丢包。發現target沒有響應SYN，想到檢視TCP accept queue是否滿了

   

2. 檢視接收端的系統日志

   /var/log/message

   有沒有報錯，結果并未有error資訊
3. 使用指令：

   netstat -s | egrep "listen|LISTEN"

   ，果然，有大量連接配接溢出

   

4. 檢視網關

   cat /proc/sys/net/ipv4/tcp_max_syn_backlog

   

5. 檢視網關

   cat /proc/sys/net/core/somaxconn

   ，發現somaxconn和max_syn_backlog兩個值較小，需要調整

   

6. 登入網關調整參數，步驟：

1、vi /etc/sysctl.conf2、調整如下2個參數值：
   net.core.somaxconn=128 調整為1280
   net.ipv4.tcp_max_syn_backlog=1024 調整為102403、生效
   sysctl -p
           

重新壓測，發現QPS并沒有明顯提升。考慮可能是機器性能問題。

1. 網關嘗試換機器：

   網關執行個體規格由sn1(較老規格，CPU：8c)變更至 c6(新規格，CPU：8c)

   說明：

   同樣核數的執行個體，新規格一般較停售的舊規格性能好。esc.c6具有2大優良特性：開啟numa，CPU更厲害。

   換機器後QPS有部分提升但還是達不到預期。

2. 通過grafana看闆，檢視tcp連接配接數分析到網關到微服務的有效連接配接數接近20，幾乎等于預設值。考慮檢視：zuul.host.maxTotalConnections,zuul.semaphore.max-semaphores,zuul.host.maxPerRouteConnections這三個參數的值。

   說明：

   zuul.host.maxTotalConnections

   适用于ApacheHttpClient，如果是okhttp無效。每個服務的http用戶端連接配接池最大連接配接，預設是200。

   zuul.host.maxPerRouteConnections

   适用于ApacheHttpClient，如果是okhttp無效。每個route可用的最大連接配接數，預設值是20。

   zuul.semaphore.max-semaphores

   Hystrix 最大的并發請求

   execution.isolation.semaphore.maxConcurrentRequests，這個值并非TPS、QPS、RPS等都是相對值，指的是1秒時間視窗内的事務/查詢/請求，semaphore.maxConcurrentRequests是一個絕對值，無時間視窗，相當于亞毫秒級的。當請求達到或超過該設定值後，其其餘就會被拒絕。預設值是100

3. 修改zuul的參數：

zuul.host.maxTotalConnections=20000
zuul.semaphore.max-semaphores=5000
MaxConnectionsPerHost=2000
           

再次壓測，QPS大幅上升。

1. 嘗試将A,B各換為1台ecs.c6後，A-B QPS上升較多

   測試結果資料：

壓測QPS	G-B	G-A-B	A(1台)-B
網關：ecs.c6 1台，A:獨享型3 台，B:獨享型 4台	9012	8512	7418
網關：ecs.c6 1台，A:ecs.c6 1台，B:ecs.c6 1台	8932	8486	11115

采取以上措施，最終timeout個數減少，所占比例不到0.1%。QPS達到9000左右，符合預期。

壓測結論

性能測試過程中，CPU運作穩定，記憶體沒有溢出現象。綜合分析以上測試資料，由于solar 性能優于agent 5%左右, 未來将選用solar作為公司灰階方案，友善業務線灰階釋出。

本文作者

謝璐，多年測試經曆。 Github: [email protected], 現任職掌門1對1測試架構師，負責掌門基礎架構部架構測試及元件測試。 謝慶芳，5年測試經驗。 Github: Enersmill ,擅長性能測試，自動化測試。 熟悉java, python。 現任職掌門1對1測試開發工程師。

元旦快樂