前陣子我們組要對(duì)訂單服務(wù)做上線前的容量評(píng)估我這次沒(méi)有繼續(xù)用 JMeter而是選了 Locust 來(lái)搭建整套 API 壓測(cè)流程。微服務(wù)架構(gòu)越拆越細(xì)接口數(shù)量翻著跟頭漲壓測(cè)腳本的復(fù)雜度也在漲。JMeter 不是不能做但腳本一到登錄鑒權(quán)、動(dòng)態(tài)參數(shù)、接口關(guān)聯(lián)這些環(huán)節(jié)維護(hù)成本就像在一張巨大的表單里繡花。換成用 Python 寫(xiě)壓測(cè)邏輯的 Locust 之后我兩天就跑通了原來(lái)計(jì)劃一周才能搞定的場(chǎng)景。這篇就記錄一下我怎么把 Locust 從入門(mén)用到實(shí)戰(zhàn)優(yōu)化給正在折騰微服務(wù)壓測(cè)的測(cè)試開(kāi)發(fā)和后端同學(xué)做個(gè)參考。1. 為什么微服務(wù)架構(gòu)下的API壓測(cè)我最終選了Locust1.1 微服務(wù)壓測(cè)的真實(shí)痛點(diǎn)在微服務(wù)架構(gòu)下面接口不是孤立存在的。一次用戶請(qǐng)求背后可能是網(wǎng)關(guān)、鑒權(quán)服務(wù)、業(yè)務(wù)服務(wù)、緩存、消息隊(duì)列、數(shù)據(jù)庫(kù)一路調(diào)用下去。壓測(cè)的時(shí)候你面對(duì)的不是一個(gè)靜態(tài) HTML 頁(yè)面而是帶鑒權(quán)頭、帶簽名、帶動(dòng)態(tài)參數(shù)的復(fù)合請(qǐng)求鏈路。具體到腳本層面你會(huì)發(fā)現(xiàn)這么幾個(gè)問(wèn)題接口需要先登錄拿 tokentoken 還有有效期請(qǐng)求體里有大量動(dòng)態(tài)數(shù)據(jù)比如訂單號(hào)、手機(jī)號(hào)、隨機(jī)字符串部分接口的返回會(huì)作為下一個(gè)接口的入?yún)⒋嬖跀?shù)據(jù)關(guān)聯(lián)壓測(cè)數(shù)據(jù)不能重復(fù)否則會(huì)觸發(fā)冪等校驗(yàn)、唯一索引沖突線上真實(shí)的流量是有比例的比如 70% 查詳情、20% 加購(gòu)物車(chē)、10% 下單。這些問(wèn)題在 JMeter 里都能解決但解決的過(guò)程很繁瑣。JMeter 的圖形化界面在配置幾十個(gè)接口時(shí)候還勉強(qiáng)能忍一旦需要寫(xiě)復(fù)雜邏輯比如 AES 加密、簽名算法、根據(jù)響應(yīng)動(dòng)態(tài)跳轉(zhuǎn)你就得寫(xiě) BeanShell 或 JSR223 腳本最終維護(hù)的其實(shí)是夾在圖形界面里的代碼既難讀又難做版本管理。我換到 Locust 之后最大的感受是壓測(cè)腳本本身就是一份普通的 Python 文件。它可以直接放進(jìn) Git 倉(cāng)庫(kù)可以做代碼評(píng)審可以用 IDE 調(diào)試可以調(diào)任何 Python 庫(kù)。對(duì)一個(gè)團(tuán)隊(duì)來(lái)說(shuō)這個(gè)優(yōu)勢(shì)在微服務(wù)場(chǎng)景下幾乎是決定性的。1.2 Locust、JMeter、k6 的選型對(duì)比這里放一張我當(dāng)時(shí)對(duì)比用的表參數(shù)基于我個(gè)人實(shí)測(cè)和官方文檔整理維度LocustJMeterk6腳本形式Python 代碼XML 圖形界面JavaScript 腳本并發(fā)模型基于 gevent 協(xié)程單進(jìn)程可支持?jǐn)?shù)千并發(fā)線程模型單機(jī)受線程數(shù)限制基于 Go 的協(xié)程單機(jī)性能強(qiáng)分布式壓測(cè)原生支持 master/worker主節(jié)點(diǎn)統(tǒng)一控制通過(guò)遠(yuǎn)程啟動(dòng) agent配置較繁瑣原生支持 k6 cloud / 手動(dòng)編排調(diào)試體驗(yàn)可斷點(diǎn)調(diào)試、可在 REPL 里試請(qǐng)求主要是界面調(diào)試本地跑腳本 日志輸出學(xué)習(xí)門(mén)檻會(huì) Python 上手很快圖形界面入門(mén)快復(fù)雜邏輯門(mén)檻高會(huì) JS 語(yǔ)法即可生態(tài)較年輕與 CI/CD 集成命令行 headless 模式十分友好可通過(guò)命令行 csv 輸出集成略笨重為云原生和 CI 而生我并沒(méi)有說(shuō) JMeter 不行。如果你的場(chǎng)景就是單接口固定參數(shù)壓測(cè)JMeter 依然是成熟穩(wěn)定的選擇。但如果你的壓測(cè)目標(biāo)是真實(shí)業(yè)務(wù)鏈路需要頻繁調(diào)整邏輯我會(huì)優(yōu)先推薦 Locust。k6 我也試過(guò)性能很猛適合做比較純粹的協(xié)議層壓測(cè)但在復(fù)雜業(yè)務(wù)邏輯的編寫(xiě)自由度上還是 Python 更舒服。1.3 必須理解的幾個(gè)核心概念Locust 的模型一句話就能說(shuō)清每個(gè)虛擬用戶是一個(gè)協(xié)程協(xié)程按你寫(xiě)好的 wait_time 等待一段時(shí)間然后隨機(jī)執(zhí)行 User 類(lèi)上標(biāo)記為 task 的方法。核心概念就這幾個(gè)User模擬一個(gè)用戶。它本身只負(fù)責(zé)行為定義不會(huì)真正對(duì)應(yīng)一條連接。HttpUser繼承 User額外帶一個(gè) client 屬性這個(gè) client 是對(duì) requests 庫(kù)的封裝用來(lái)發(fā) HTTP 請(qǐng)求。task裝飾在方法上的task(weight)weight 表示權(quán)重比如task(3)和task(1)前者被執(zhí)行的概率是后者的 3 倍。wait_time用戶執(zhí)行完一個(gè)任務(wù)之后休息多久常寫(xiě)between(1, 5)表示隨機(jī)等待 1 到 5 秒。這個(gè)參數(shù)直接影響壓測(cè)速率。FastHttpUser基于 geventhttpclient 實(shí)現(xiàn)的 HttpUser請(qǐng)求效率更高后面分布式章節(jié)我會(huì)再展開(kāi)。這五個(gè)概念已經(jīng)覆蓋絕大多數(shù)日常壓測(cè)場(chǎng)景剩下的是 Web UI、事件鉤子、csv 輸出這些外圍能力。別一開(kāi)始就被TaskSetSequentialTaskSet這些老概念勸退新版本里直接在 User 類(lèi)上寫(xiě) task 就夠了代碼反而更清晰。我見(jiàn)過(guò)不少剛接觸 Locust 的人把它當(dāng)成性能測(cè)試工具其實(shí)它更像一個(gè)可編程壓測(cè)框架。它不會(huì)替你做壓力模型但給了你做任意壓力模型的自由區(qū)別就在這。2. 從零寫(xiě)一個(gè)能跑的Locust腳本環(huán)境準(zhǔn)備與第一個(gè)壓測(cè)用例2.1 環(huán)境準(zhǔn)備與安裝我用的是 Python 3.10建議你至少在 3.9 以上。新版本 Locust 對(duì) Python 版本有要求太老的版本裝不上。安裝前先建一個(gè)虛擬環(huán)境這是 Python 項(xiàng)目的常規(guī)操作python3 -m venv .venv source .venv/bin/activate pip install locust裝完確認(rèn)版本locust --version如果你看到locust 2.x.x就說(shuō)明裝好了。我這邊當(dāng)時(shí)裝的是 2.24 左右不同小版本在 Web UI 樣式和參數(shù)細(xì)節(jié)上會(huì)有差異但核心用法沒(méi)有大變化。需要注意一點(diǎn)如果你是 Windows 環(huán)境gevent 依賴(lài)的 C 擴(kuò)展在安裝時(shí)偶爾會(huì)出問(wèn)題。官方文檔建議直接裝預(yù)編譯的 wheel 包一般pip install locust會(huì)自動(dòng)選對(duì)版本。真的遇到編譯錯(cuò)誤把 pip 升到最新再裝一次基本能解決。2.2 第一個(gè)最簡(jiǎn)腳本在項(xiàng)目目錄創(chuàng)建一個(gè)locustfile.py這是 Locust 的默認(rèn)文件名不帶-f參數(shù)時(shí)會(huì)自動(dòng)找它from locust import HttpUser, task, between class ApiUser(HttpUser): wait_time between(1, 3) task def get_health(self): self.client.get(/health)這個(gè)腳本的意思很直白每個(gè)虛擬用戶協(xié)程在每次請(qǐng)求后隨機(jī)等待 1 到 3 秒每次執(zhí)行時(shí)隨機(jī)挑一個(gè)標(biāo)記為 task 的方法這里只有一個(gè)任務(wù)就是 GET /health。如果你要壓測(cè)的是一個(gè) POST 接口改成這樣task def create_order(self): self.client.post( /orders, json{product_id: 10001, count: 2}, )self.client的用法和 requests 幾乎一致get、post、put、delete、head、patch 都有headers、params、json、data、files 這些參數(shù)也都能傳。這一點(diǎn)對(duì)從 requests 轉(zhuǎn)過(guò)來(lái)的人來(lái)說(shuō)幾乎不需要學(xué)習(xí)成本。2.3 啟動(dòng)方式Web UI 模式與命令行模式開(kāi)發(fā)調(diào)試階段我習(xí)慣直接跑 Web UIlocust -f locustfile.py --host https://api.example.com啟動(dòng)后瀏覽器打開(kāi)http://localhost:8089填上并發(fā)用戶數(shù)、每秒啟動(dòng)數(shù)、壓測(cè)地址點(diǎn)開(kāi)始就行。Web UI 可以實(shí)時(shí)看請(qǐng)求數(shù)、響應(yīng)時(shí)間、異常數(shù)還能在線下載報(bào)告 CSV對(duì)臨時(shí)摸底非常方便。真正到了自動(dòng)化壓測(cè)和 CI 階段用 headless 命令行模式locust -f locustfile.py --host https://api.example.com \ --headless \ -u 500 \ -r 50 \ -t 10m \ --csvreport/load_test \ --htmlreport/load_test.html參數(shù)含義我列一下-u目標(biāo)虛擬用戶數(shù)-r每秒生成多少個(gè)用戶速率-t壓測(cè)持續(xù)時(shí)間支持10m、30s、1h--csv前綴每 3 秒寫(xiě)一版 CSV 快照壓測(cè)結(jié)束生成完整數(shù)據(jù)文件--html導(dǎo)出帶圖表 HTML 報(bào)告。第一次跑的時(shí)候別貪多先用-u 10 -r 2 -t 1m熱個(gè)身確認(rèn)腳本沒(méi)有返回異常再往上加。我很長(zhǎng)一段時(shí)間的習(xí)慣都是先跑 10 個(gè)用戶打開(kāi)報(bào)告看有沒(méi)有 401、500然后再談加壓。3. 把真實(shí)業(yè)務(wù)邏輯塞進(jìn)腳本鑒權(quán)、參數(shù)關(guān)聯(lián)與數(shù)據(jù)驅(qū)動(dòng)3.1 為什么必須處理鑒權(quán)如果你壓測(cè)的接口需要鑒權(quán)而你的腳本里沒(méi)寫(xiě) token 邏輯那么壓測(cè)一開(kāi)始你就會(huì)看到滿屏的 401RPS 再高也沒(méi)有意義——你測(cè)的其實(shí)是未授權(quán)請(qǐng)求被拒絕的速度。在 Locust 里做鑒權(quán)有兩種常見(jiàn)策略。策略一全局登錄一次token 復(fù)用class ApiUser(HttpUser): wait_time between(1, 3) def on_start(self): resp self.client.post(/auth/login, json{ username: load_test_user, password: xxxxx, }) token resp.json()[data][token] self.client.headers[Authorization] fBearer {token}on_start在每個(gè)虛擬用戶啟動(dòng)時(shí)執(zhí)行一次。幾百個(gè)用戶會(huì)各登錄一次這樣做的好處是每個(gè)協(xié)程都有獨(dú)立 token符合真實(shí)用戶分布。如果擔(dān)心登錄接口本身成為壓測(cè)瓶頸可以用test_start鉤子全局登錄一次再把 token 作為類(lèi)屬性共享from locust import events events.test_start.add_listener def on_test_start(environment, **kwargs): resp requests.post(...) ApiUser.token resp.json()[data][token]兩種策略沒(méi)有絕對(duì)優(yōu)劣。壓測(cè)目標(biāo)是業(yè)務(wù)接口時(shí)我傾向策略一因?yàn)榈卿浟髁勘旧硪彩钦鎸?shí)調(diào)用的一部分更貼近線上。如果業(yè)務(wù)要求 token 有效期很長(zhǎng)、登錄接口資源有限就選策略二。3.2 動(dòng)態(tài)參數(shù)與接口關(guān)聯(lián)微服務(wù)接口最麻煩的不是鑒權(quán)而是參數(shù)動(dòng)態(tài)化。比如下單接口要求訂單號(hào)不能重復(fù)創(chuàng)建訂單后還要用返回的訂單號(hào)去查支付狀態(tài)。這就是接口關(guān)聯(lián)。拿一個(gè)典型的電商鏈路為例登錄拿 token - 創(chuàng)建訂單拿 order_id - 查訂單狀態(tài)。腳本可以這樣寫(xiě)import json from locust import HttpUser, task, between class OrderUser(HttpUser): wait_time between(1, 2) def on_start(self): login_resp self.client.post(/auth/login, json{ username: user_001, password: xxxx, }) data login_resp.json() token data[data][token] self.client.headers[Authorization] fBearer {token} task def create_and_query_order(self): order_resp self.client.post(/orders, json{ sku_id: 10086, count: 1, }) if not order_resp.ok: return order_id order_resp.json()[data][order_id] self.client.get(f/orders/{order_id}/status)這里的核心動(dòng)作是order_id order_resp.json()[data][order_id]把上一個(gè)接口的響應(yīng)變成下一個(gè)接口的路徑參數(shù)。如果響應(yīng)體不是 JSON可以用正則提取import re order_id re.search(rorder_id:\s*([^]), order_resp.text).group(1)動(dòng)態(tài)參數(shù)的另一類(lèi)常見(jiàn)需求是從數(shù)據(jù)池里隨機(jī)取。比如壓測(cè)不同區(qū)域維度的訂單接口import random regions [cn-east, cn-north, cn-south, cn-west] task def regional_order(self): region random.choice(regions) self.client.post(/orders, json{ region: region, user_id: random.randint(10000, 99999), })數(shù)據(jù)量更大時(shí)從 CSV 讀入內(nèi)存再循環(huán)使用或者連測(cè)試庫(kù)隨機(jī)取一行原理都一樣壓測(cè)腳本要盡量復(fù)用真實(shí)數(shù)據(jù)的分布特征而不是每個(gè)請(qǐng)求都用同一個(gè)固定參數(shù)。3.3 壓測(cè)中必現(xiàn)的401問(wèn)題別讓鑒權(quán)錯(cuò)誤污染壓測(cè)結(jié)果我做過(guò)不少接口壓測(cè)發(fā)現(xiàn)一上高并發(fā)就出現(xiàn)一堆 401是個(gè)高頻現(xiàn)象而且很多時(shí)候不是被測(cè)服務(wù)的問(wèn)題是壓測(cè)腳本自己的問(wèn)題。常見(jiàn)原因有三個(gè)。第一個(gè)是 token 過(guò)期。登錄接口發(fā)的 token 有效期可能只有 30 分鐘壓測(cè)跑到第 40 分鐘時(shí)全局復(fù)用的 token 已經(jīng)失效后面的請(qǐng)求全部 401。解決辦法是縮短單輪壓測(cè)時(shí)長(zhǎng)或者在腳本里捕獲 401 并重新登錄。Locust 支持在任務(wù)里判斷響應(yīng)碼resp self.client.get(/orders/123/status) if resp.status_code 401: self.on_start()第二個(gè)是 Authorization 頭沒(méi)傳對(duì)。不少平臺(tái)要求Authorization: Bearer token或者自定義頭X-API-Key少傳一個(gè)空格、大小寫(xiě)寫(xiě)錯(cuò)都會(huì) 401。壓測(cè)前建議先用真實(shí)請(qǐng)求單獨(dú)調(diào)試一遍別直接上百并發(fā)。第三個(gè)是使用了錯(cuò)誤的 API Key。我遇到好幾次同事從配置中心拿錯(cuò)了 key或者 key 被輪換后測(cè)試環(huán)境沒(méi)同步壓測(cè)一開(kāi)始就是一片 401。判斷方式很簡(jiǎn)單單獨(dú)用一條真實(shí)請(qǐng)求打目標(biāo)接口看返回體里的錯(cuò)誤信息。如果返回的是incorrect api key provided、unexpected status 401 unauthorized大概率是配置本身的問(wèn)題不是被測(cè)服務(wù)的問(wèn)題。這里有個(gè)非常實(shí)用的建議壓測(cè)開(kāi)始時(shí)先看前 1 分鐘的異常分布。如果異常率從第一秒就很高那基本是腳本或配置問(wèn)題如果前 5 分鐘正常、后面突然 401那優(yōu)先懷疑 token 過(guò)期或服務(wù)端限流策略。這兩種問(wèn)題的處理路徑完全不一樣。3.4 數(shù)據(jù)驅(qū)動(dòng)與加載策略最后說(shuō)一下數(shù)據(jù)驅(qū)動(dòng)。市面上很多壓測(cè)工具都強(qiáng)調(diào)數(shù)據(jù)文件參數(shù)化Locust 的做法更加樸素——在 Python 里怎么讀數(shù)據(jù)腳本里就怎么寫(xiě)。我常用的是把測(cè)試賬號(hào)放在 CSV 里在模塊加載時(shí)讀入一次import csv USERS [] with open(users.csv, r) as f: USERS list(csv.DictReader(f)) class DataDrivenUser(HttpUser): wait_time between(0.5, 1) task def use_account(self): user USERS.pop(0) if USERS else None if user: self.client.post(/some/api, json{username: user[username]})讀取數(shù)據(jù)的開(kāi)銷(xiāo)記住一個(gè)原則能加載一次就不要加載一千次。如果把 CSV 讀取放在每個(gè)用戶的on_start里1000 個(gè)并發(fā)就是 1000 次文件 IO完全沒(méi)必要。4. 從單機(jī)到分布式千級(jí)并發(fā)下壓測(cè)集群的搭建與調(diào)優(yōu)4.1 單機(jī)瓶頸在哪里用 Locust 單機(jī)跑幾百并發(fā)很輕松跑到幾千時(shí)通常會(huì)遇到幾類(lèi)問(wèn)題CPU 占滿、文件描述符不夠、TCP 端口耗盡。先解釋一下原理Locust 的并發(fā)模型是 gevent 協(xié)程單進(jìn)程的協(xié)程吃 CPU 很少但 Python 進(jìn)程有 GIL當(dāng)請(qǐng)求響應(yīng)體很大、需要做大量 JSON 解析或正則匹配時(shí)CPU 會(huì)成為瓶頸。另一個(gè)瓶頸是 TCP 連接壓測(cè)機(jī)作為客戶端每條連接要占用一個(gè)本地端口默認(rèn)的臨時(shí)端口范圍有限。你可以先看系統(tǒng)限制ulimit -n如果輸出只有 1024那并發(fā)到 1000 就很容易出現(xiàn)Cannot assign requested address這類(lèi)連接錯(cuò)誤可以臨時(shí)調(diào)大ulimit -n 65535單機(jī) Locust 能扛多少并發(fā)很大程度上取決于壓測(cè)機(jī)自身配置和響應(yīng)體大小。一個(gè) 2C4G 的機(jī)器壓簡(jiǎn)單 JSON 接口跑到 3000 并發(fā)是可能的但壓大響應(yīng)體接口可能 1000 就吃滿了。如果你的目標(biāo)是 5000 甚至 10000 并發(fā)別繼續(xù)壓榨單機(jī)了直接上分布式集群。4.2 主從模式的工作原理Locust 的分布式模式很清爽一個(gè) master 節(jié)點(diǎn)負(fù)責(zé)分發(fā)任務(wù)、匯總統(tǒng)計(jì)數(shù)據(jù)、提供 Web UI若干個(gè) worker 節(jié)點(diǎn)實(shí)際執(zhí)行壓測(cè)任務(wù)。啟動(dòng)方式# master 節(jié)點(diǎn) locust -f locustfile.py --master # worker 節(jié)點(diǎn) locust -f locustfile.py --worker --master-host192.168.1.10master 和 worker 都加載同一個(gè)locustfile.py。worker 連上 master 后你在 master 的 Web UI 上看到的并發(fā)用戶總數(shù)為所有 worker 的累加。這里有個(gè)容易踩的坑master 和 worker 的 Locust 版本必須一致。我遇到過(guò)版本不一致導(dǎo)致 worker 反復(fù)重連 master、壓測(cè)跑不起來(lái)的詭異問(wèn)題排查了半天才發(fā)現(xiàn)是兩臺(tái)機(jī)器上pip install locust的版本不一樣。master 本身不執(zhí)行壓測(cè)任務(wù)配置不用太高worker 才是真正的壓力發(fā)生源CPU 和內(nèi)存要給足。4.3 用 Docker Compose 快速拉起壓測(cè)集群Docker 方式部署最省心官方鏡像直接可用。我在項(xiàng)目里的docker-compose.yml大概是這樣的services: master: image: locustio/locust:latest ports: - 8089:8089 volumes: - ./:/mnt/locust command: -f /mnt/locust/locustfile.py --master worker: image: locustio/locust:latest volumes: - ./:/mnt/locust command: -f /mnt/locust/locustfile.py --worker --master-hostmaster然后執(zhí)行docker compose up --scale worker4就能拉起一個(gè) master 加 4 個(gè) worker 的集群。整個(gè)壓測(cè)腳本目錄掛載進(jìn)容器代碼更新后重啟容器即可。用--scale worker4只改變 worker 數(shù)量master 始終只有一個(gè)這點(diǎn)和普通服務(wù)擴(kuò)容不太一樣。需要調(diào)整并發(fā)規(guī)模時(shí)要么改-u參數(shù)要么調(diào)整 worker 數(shù)量?jī)烧叨伎梢浴?.4 性能調(diào)優(yōu)讓壓測(cè)機(jī)自身別成為瓶頸分布式不是萬(wàn)能的還要注意壓測(cè)側(cè)的性能優(yōu)化。我的經(jīng)驗(yàn)排序是第一能換FastHttpUser就換。底層用的是 geventhttpclient比默認(rèn)HttpUser的 requests 實(shí)現(xiàn)輕量很多。官方和一些社區(qū)測(cè)試中FastHttpUser 的請(qǐng)求吞吐比 HttpUser 高出一個(gè)數(shù)量級(jí)。改法就一行from locust import FastHttpUser class ApiUser(FastHttpUser): pass大部分情況下原有的self.client寫(xiě)法都不用改。第二控制日志輸出。壓測(cè)時(shí)不要無(wú)腦print更不要在每個(gè)請(qǐng)求里記錄 debug 日志。日志本身會(huì)占 CPU 和磁盤(pán) IO高并發(fā)時(shí)對(duì)結(jié)果的影響不可忽視。要輸出只在捕獲到異常時(shí)打印關(guān)鍵信息。第三監(jiān)控壓測(cè)機(jī)自身。壓測(cè)時(shí)同時(shí)打開(kāi)htop和vmstat如果 worker 節(jié)點(diǎn)的 CPU 已經(jīng) 100%說(shuō)明瓶頸在壓測(cè)側(cè)此時(shí)加用戶數(shù)只會(huì)讓結(jié)果更失真正確做法是加 worker 或優(yōu)化腳本。5. 壓測(cè)報(bào)告的讀法哪些指標(biāo)值得盯哪些指標(biāo)容易騙人5.1 Locust 聚合報(bào)告的關(guān)鍵指標(biāo)在 Web UI 或--csv導(dǎo)出的數(shù)據(jù)里核心指標(biāo)其實(shí)就那么幾項(xiàng)RPS、平均響應(yīng)時(shí)間、中位數(shù)響應(yīng)時(shí)間、P95、P99、異常率、當(dāng)前用戶數(shù)。我給個(gè)表格幫新手快速對(duì)號(hào)入座指標(biāo)看什么常見(jiàn)誤讀RPS系統(tǒng)吞吐能力把單機(jī) RPS 當(dāng)整體能力忽略 worker 數(shù)量平均響應(yīng)時(shí)間整體水平被少量慢請(qǐng)求拉高看不出長(zhǎng)尾P50典型用戶感受只代表多數(shù)用戶正常不代表高負(fù)載P95 / P99長(zhǎng)尾與抖動(dòng)不看這兩個(gè)值等于沒(méi)發(fā)現(xiàn)性能隱患異常率錯(cuò)誤請(qǐng)求占比401 和 500 都算異常但原因完全不同我特別想說(shuō) P95 和 P99。很多接口平均響應(yīng)時(shí)間 80ms看起來(lái)很美但 P99 可能是 800ms說(shuō)明有 1% 的請(qǐng)求慢了一個(gè)數(shù)量級(jí)。在線服務(wù)最怕的就是這種隱性問(wèn)題它可能來(lái)自 GC 停頓、緩存擊穿、連接池爭(zhēng)搶。只盯著平均值做優(yōu)化很容易得出系統(tǒng)沒(méi)問(wèn)題的錯(cuò)誤結(jié)論。5.2 從異常狀態(tài)碼倒推問(wèn)題根因壓測(cè)報(bào)告里的異常率不是用一個(gè)數(shù)字概括的我習(xí)慣按狀態(tài)碼拆開(kāi)看401鑒權(quán)問(wèn)題。先查腳本里的 token、Header、API Key再查服務(wù)端是否有會(huì)話失效機(jī)制。429限流。服務(wù)端限流一般有策略比如按 IP、按用戶、按接口。壓測(cè)時(shí)出現(xiàn) 429要確認(rèn)是業(yè)務(wù)預(yù)期行為還是限流閾值配置太低。500服務(wù)端異常。這時(shí)候要看服務(wù)日志、數(shù)據(jù)庫(kù)慢查詢(xún)、異常堆棧。502 / 504網(wǎng)關(guān)或代理層面的問(wèn)題。常見(jiàn)于壓測(cè)并發(fā)加大后網(wǎng)關(guān)連接后端超時(shí)。我遇到過(guò)一個(gè)印象很深的案例某接口壓測(cè)到 800 并發(fā)時(shí)異常率突然飆到 15%大部分是 429。當(dāng)時(shí)第一反應(yīng)是限流閾值太低后來(lái)查日志發(fā)現(xiàn)是壓測(cè)機(jī)出口 IP 被 WAF 自動(dòng)封了。這種問(wèn)題不會(huì)直接顯示在業(yè)務(wù)代碼里必須把壓測(cè)機(jī)的出口 IP 加白名單或者反過(guò)來(lái)用真實(shí)線上入口做壓測(cè)。這類(lèi)問(wèn)題只能靠經(jīng)驗(yàn)判斷。5.3 從響應(yīng)時(shí)間分布定位瓶頸的方法響應(yīng)時(shí)間變長(zhǎng)不一定就是目標(biāo)服務(wù)變慢。我按調(diào)用鏈路的順序梳理了一套排查順序先確認(rèn)壓測(cè)機(jī)自身沒(méi)有被打滿CPU、帶寬、端口。觀察目標(biāo)服務(wù)的 CPU、內(nèi)存、GC、連接數(shù)。如果 CPU 已經(jīng)打滿優(yōu)先考慮擴(kuò)容或優(yōu)化業(yè)務(wù)代碼?？磾?shù)據(jù)庫(kù)指標(biāo)。慢 SQL、鎖等待、連接池打滿都是壓測(cè)時(shí)最常暴露的問(wèn)題?？赐獠恳蕾?lài)。如果接口內(nèi)部調(diào)了第三方 API 或另一個(gè)微服務(wù)要看下游返回耗時(shí)和錯(cuò)誤率。第三方服務(wù)一旦抖動(dòng)上游接口的 P99 會(huì)非常難看。我這么排序的原因很簡(jiǎn)單響應(yīng)時(shí)間是從客戶端視角統(tǒng)計(jì)的它只能告訴你慢不能告訴你哪里慢。要回答哪里慢必須分層看各鏈路節(jié)點(diǎn)的指標(biāo)。Locust 負(fù)責(zé)證明慢存在具體根因要靠 APM 和基礎(chǔ)設(shè)施監(jiān)控去挖。6. 我踩過(guò)的坑和沉淀下來(lái)的Locust壓測(cè)習(xí)慣6.1 六個(gè)最值得記住的坑第一個(gè)坑wait_time 寫(xiě)成 0。有人為了提高并發(fā)把等待時(shí)間設(shè)為 0結(jié)果每個(gè)協(xié)程都在瘋狂發(fā)請(qǐng)求壓測(cè)機(jī) CPU 先被打滿測(cè)出來(lái)的數(shù)據(jù)完全不可信。wait_time 是模擬用戶思考時(shí)間的你不想要可以適當(dāng)調(diào)小但最好別設(shè)成 0。第二個(gè)坑在壓測(cè)腳本里引用不存在的測(cè)試數(shù)據(jù)。比如用一個(gè)固定手機(jī)號(hào)反復(fù)下單結(jié)果因?yàn)橛唵翁?hào)重復(fù)導(dǎo)致接口報(bào)錯(cuò)。解決辦法是讓腳本自己生成隨機(jī)數(shù)據(jù)或者用前置腳本灌一批可用的測(cè)試數(shù)據(jù)。第三個(gè)坑token 全局復(fù)用但沒(méi)考慮有效期。前面已經(jīng)講過(guò)不再重復(fù)。第四個(gè)坑master 和 worker 版本不一致。分布式壓測(cè)跑起來(lái)像個(gè)啞彈看不到任何請(qǐng)求多半是這個(gè)問(wèn)題。第五個(gè)坑壓測(cè)機(jī)和被測(cè)服務(wù)部署在同一臺(tái)機(jī)器上。這個(gè)屬于資源競(jìng)爭(zhēng)壓測(cè)機(jī)一高并發(fā)被測(cè)服務(wù)的 CPU 被搶走結(jié)果自然不準(zhǔn)。盡量分開(kāi)機(jī)器至少分開(kāi)物理資源。第六個(gè)坑只看最終匯總不看過(guò)程趨勢(shì)。接口可能在壓測(cè)第 5 分鐘出現(xiàn)內(nèi)存泄漏但你沒(méi)看過(guò)程數(shù)據(jù)只盯著最后的匯總 RPS根本發(fā)現(xiàn)不了。Locust 生成的 CSV 數(shù)據(jù)分很多時(shí)間片建議留檔下來(lái)做趨勢(shì)分析。6.2 我沉淀下來(lái)的壓測(cè)動(dòng)作清單現(xiàn)在我在項(xiàng)目里做一次正式壓測(cè)基本按這個(gè)流程走寫(xiě)腳本前先用手工方式把接口調(diào)通確認(rèn)鑒權(quán)和參數(shù)規(guī)則。寫(xiě)一個(gè)locustfile.py先用 10 個(gè)用戶跑 1 分鐘檢查異常碼。確認(rèn)沒(méi)有 401、500 之后按目標(biāo)并發(fā)數(shù) 50%、100%、150% 三檔逐步加壓。壓測(cè)過(guò)程中同時(shí)記錄服務(wù)端關(guān)鍵指標(biāo)包括 CPU、內(nèi)存、DB 慢查詢(xún)、下游調(diào)用耗時(shí)。壓測(cè)結(jié)束后導(dǎo)出 CSV 和 HTML 報(bào)告按 P95、P99、異常率、時(shí)間趨勢(shì)三個(gè)維度寫(xiě)結(jié)論。把locustfile.py和報(bào)告提交到 Git作為這個(gè)接口的歷史基線。這個(gè)清單看起來(lái)樸素但真的能避免很多壓了個(gè)寂寞的情況。最有價(jià)值的是第 1 步和第 4 步它們決定了壓測(cè)結(jié)果的真實(shí)性。6.3 把 Locust 融入持續(xù)壓測(cè)最后聊一下自動(dòng)化。Locust 的 headless 模式特別適合放進(jìn) CI 流程。在 Jenkins 或 GitHub Actions 里把壓測(cè)做成一個(gè) job每天晚上跑一次回歸或者每次上線前跑一次容量評(píng)估都能自動(dòng)留報(bào)告。我用的比較順手的寫(xiě)法是這樣locust -f locustfile.py --host https://staging.example.com \ --headless \ -u 200 -r 20 -t 5m \ --csvreport/staging \ --htmlreport/staging.html \ --expect-workers4--expect-workers4用于分布式模式下master 會(huì)等待 4 個(gè) worker 全部連接后才開(kāi)始任務(wù)避免出現(xiàn)master 已開(kāi)始worker 還沒(méi)連上的競(jìng)態(tài)。這個(gè)參數(shù)在 CI 場(chǎng)景下幾乎是必加的。另外可以利用事件鉤子做自定義擴(kuò)展比如壓測(cè)結(jié)束時(shí)把結(jié)論推到企業(yè)微信或郵件。Locust 的擴(kuò)展點(diǎn)很多真正用到的時(shí)候再查文檔即可?？傊劝炎约旱膲簻y(cè)動(dòng)作標(biāo)準(zhǔn)化自動(dòng)化只是水到渠成的事。從我自己的經(jīng)驗(yàn)看Locust 最大的價(jià)值不是壓測(cè)工具這四個(gè)字而是把一個(gè)復(fù)雜的性能驗(yàn)證問(wèn)題簡(jiǎn)化成了一個(gè)寫(xiě) Python 腳本的問(wèn)題。你把業(yè)務(wù)邏輯理清楚腳本寫(xiě)規(guī)范剩下的事情 Locust 都會(huì)幫你處理得明明白白。這套實(shí)踐我用到現(xiàn)在已經(jīng)幫組里提前發(fā)現(xiàn)了三次數(shù)據(jù)庫(kù)慢查詢(xún)和兩次第三方接口抖動(dòng)希望這篇內(nèi)容也能讓你少走一段彎路。