告白成不成心里沒數(shù)，系統(tǒng)扛不扛得住還沒數(shù)嗎？！
情人節(jié)又來了，這一天的 IT 程序員常常成為被調(diào)侃的對(duì)象。事實(shí)上，性格內(nèi)向的他們?cè)谙蛐膬x的對(duì)象告白時(shí)，也確實(shí)會(huì)因?yàn)椴簧蒲赞o，被搞得心里七上八下。
俗話說得好，術(shù)(po)業(yè)(guan)有(po)專(shuai)攻(ba)，告白成不成功心里沒數(shù)兒，系統(tǒng)扛不扛得住，你心里怎么還能沒點(diǎn)兒 Balance !
常言道，「沒過十五都是年」。在 2 月 14 日這一天，我們來想象一下中國(guó)的傳統(tǒng)節(jié)日——春節(jié)。
你所在的業(yè)務(wù)線要上線一個(gè)活動(dòng)：過年七天，用戶每天簽到、邀請(qǐng)好友、完成設(shè)定任務(wù)都可以得到紅包。這個(gè)紅包系統(tǒng)的建設(shè)由你來負(fù)責(zé)，包括所有與紅包相關(guān)的功能，比如發(fā)紅包、搶紅包、拆紅包等。需求方告訴你活動(dòng)上線后，對(duì)紅包系統(tǒng)調(diào)用的 QPS 是 5000。
- 面對(duì)每秒 5000 次的請(qǐng)求，你的系統(tǒng)是否可以穩(wěn)定運(yùn)行?
- 如果現(xiàn)在要同時(shí)上線 10 個(gè)活動(dòng)都需要調(diào)用紅包系統(tǒng)，你設(shè)計(jì)的系統(tǒng)又是否能扛住這 10 個(gè)活動(dòng)的流量?
- 如果宕掉一臺(tái)服務(wù)器會(huì)怎么樣?
- 多長(zhǎng)時(shí)間能夠恢復(fù)?
- 如果扛不住，加多少資源合理?
面對(duì)這一連串的問題，你心里有數(shù)嗎?
為什么需要關(guān)注性能測(cè)試?
對(duì)于用戶來說，穩(wěn)定、平穩(wěn)的使用體驗(yàn)非常重要。在系統(tǒng)架構(gòu)階段，對(duì)于部分關(guān)鍵功能進(jìn)行性能、容量、安全、可擴(kuò)展性和穩(wěn)定性等的評(píng)估非常必要。但我們常常缺少這個(gè)階段的性能測(cè)試實(shí)踐，等系統(tǒng)開發(fā)結(jié)束后才進(jìn)行，常常為時(shí)已晚。
這好比是選拔長(zhǎng)跑運(yùn)動(dòng)員，在選拔運(yùn)動(dòng)員前我們就要知道需要考察哪些素質(zhì)，比如身體協(xié)調(diào)性、耐力、沖刺爆發(fā)力等等，綜合評(píng)估能否應(yīng)對(duì)大賽的考驗(yàn)。對(duì)系統(tǒng)的考察也是如此，在線運(yùn)行時(shí)是否穩(wěn)定，沒有內(nèi)存泄漏、線程安全等問題，應(yīng)對(duì)突發(fā)大流量系統(tǒng)是否可以平穩(wěn)度過，系統(tǒng)各類資源參數(shù)設(shè)置是否合理，該如何設(shè)置，參考的標(biāo)準(zhǔn)是什么。
概括來說，性能測(cè)試就是驗(yàn)證系統(tǒng)的爆發(fā)力、耐力、協(xié)調(diào)性，幫助定位問題，為性能不斷優(yōu)化指導(dǎo)方向。
完整的性能測(cè)試該如何進(jìn)行
之前和其他公司的測(cè)試同學(xué)討論時(shí)，問到他們的性能測(cè)試方案，有人說我們用 Loadrunner，有人說我們用 Jmeter。我的感覺是，測(cè)試工具一定是必要的，但性能測(cè)試一定不能和 Loadrunner、JMeter 劃「=」，而是需要一個(gè)完整的測(cè)試流程。
下面，我結(jié)合馬蜂窩大交通火車票搶票壓測(cè)流程，來說說在我看來，整個(gè)性能測(cè)試應(yīng)該包括哪些內(nèi)容。我自己也處于性能測(cè)試的摸索階段，如果有不妥之處，還請(qǐng)各位不吝賜教。
圖1：大交通火車票壓測(cè)項(xiàng)目流程圖
一、準(zhǔn)備階段
1. 什么情況下需要進(jìn)行性能測(cè)試
生產(chǎn)環(huán)境下可能出現(xiàn)各種場(chǎng)景，哪些場(chǎng)景下我們需要考進(jìn)行性能測(cè)試?
服務(wù)的例行迭代
你所負(fù)責(zé)系統(tǒng)增加新功能需求，增加了新的業(yè)務(wù)代碼，新增加代碼有沒有引入性能問題，以上次性能測(cè)試結(jié)果為參考對(duì)本次迭代版本進(jìn)行壓測(cè)，檢查性能是否下降。
服務(wù)重構(gòu)
核心搜索、交易線服務(wù)架構(gòu)進(jìn)行了重構(gòu)或者調(diào)整，要與重構(gòu)前服務(wù)性能狀況進(jìn)行對(duì)比檢查服務(wù)的處理能力是否達(dá)到重構(gòu)目標(biāo)。
容量規(guī)劃
生產(chǎn)環(huán)境需要進(jìn)行容量規(guī)劃以支撐更大流量或者新服務(wù)上線明確需要多少資源，比如幾臺(tái)服務(wù)器，Redis 容量是多少。舉個(gè)例子，有一個(gè)服務(wù) A 的 QPS 是 100，服務(wù) A 每次請(qǐng)求都要對(duì) Redis 進(jìn)行一次讀和寫，Redis 的 QPS 是 700，原來服務(wù) A 有 3 臺(tái)服務(wù)器，高峰期流量是 300，生產(chǎn)環(huán)境沒有出現(xiàn)資源不夠用的情況。現(xiàn)在上線了一個(gè)活動(dòng)，高峰期流量增長(zhǎng)到 600，需要增加多少臺(tái)服務(wù)器合適呢?上面的例子中根據(jù)單機(jī) QPS 在增加 4 臺(tái)服務(wù)器，可以應(yīng)對(duì)高峰期流量嗎?
有經(jīng)驗(yàn)的同學(xué)會(huì)回答只是增加服務(wù)器個(gè)數(shù)還不夠，因?yàn)槊總€(gè)請(qǐng)求對(duì) Redis 有兩次操作，高峰期 600 QPS 映射到 Redis 是 1200，按照 Redis 處理能力 700 QPS，顯然增加機(jī)器后雖然服務(wù) A 此時(shí)不是瓶頸，但是 Redis 的處理能力仍是瓶頸。
所以，容量規(guī)劃的資源是否合理，進(jìn)行容量規(guī)劃時(shí)給各類資源的參考值是多少，都需要通過性能測(cè)試來給出。
服務(wù)支持上層多方業(yè)務(wù)交易應(yīng)用
越是支撐各類業(yè)務(wù)的底層服務(wù)，對(duì)穩(wěn)定性、系統(tǒng)吞吐要求越高，就像我們?cè)陂_篇舉例的紅包系統(tǒng)，這樣的服務(wù)在架構(gòu)設(shè)計(jì)時(shí)需要充分的考慮并發(fā)處理能力，是否可以方便的進(jìn)行系統(tǒng)的容量和性能擴(kuò)展。
當(dāng)然，需要性能測(cè)試的場(chǎng)景不僅局限于以上列舉的部分，我只列舉出一些，供大家參考和發(fā)散思維。
2. 組建測(cè)試團(tuán)隊(duì)
雖然在圖 1 的角色中沒有體現(xiàn)運(yùn)維和 DBA 以及跨部門人員，很多時(shí)候，尤其是在生產(chǎn)環(huán)境做壓測(cè)，都需要這些人員的參與，開發(fā)準(zhǔn)備好軟件版本由運(yùn)維同學(xué)進(jìn)行部署，同時(shí)需要提前知會(huì)其他上下游依賴部門，關(guān)注服務(wù)，共同配合。
3. 預(yù)先分析
為了對(duì)系統(tǒng)性能建立直觀上的認(rèn)識(shí)和分析，應(yīng)對(duì)系統(tǒng)較重要和常用的業(yè)務(wù)場(chǎng)景模塊有針對(duì)性地進(jìn)行分析，以對(duì)接下來的測(cè)試方案設(shè)計(jì)進(jìn)行準(zhǔn)備。
二、設(shè)計(jì)測(cè)試方案
在整個(gè)性能測(cè)試過程中，制定合理有效的性能測(cè)試方案很重要。壓測(cè)方案中需要明確的內(nèi)容，我的總結(jié)如下圖：
圖2：壓測(cè)方案設(shè)計(jì)思維
1. 性能指標(biāo)
性能指標(biāo)是進(jìn)行壓測(cè)的目標(biāo)，一般這個(gè)指標(biāo)由業(yè)務(wù)需求方產(chǎn)品經(jīng)理或項(xiàng)目經(jīng)理給出，如果產(chǎn)品經(jīng)理或項(xiàng)目經(jīng)理不能提供具體數(shù)值，如何估算出一個(gè)能夠支持業(yè)務(wù)流量 QPS 值呢?提供幾個(gè)參考思考方式：
1)對(duì)于活動(dòng)促銷類的方案，可以參考去年同期活動(dòng)高峰流量上升百分比，今年同期峰值也上升相同的百分比或者在這個(gè)基礎(chǔ)上在增加一定的余量;
2)利用「二八原則」，根據(jù)預(yù)期到達(dá)的 PV 值進(jìn)行推算，80% 的請(qǐng)求集中在 20% 的時(shí)間，那么峰值時(shí)間每秒請(qǐng)求數(shù) (QPS)=(總 PV 數(shù) * 80% ) / (每天秒數(shù) * 20% )
3)參考同類型業(yè)務(wù)最近一個(gè)季度甚至一年高峰期QPS 值;
2. 測(cè)試準(zhǔn)備
測(cè)試內(nèi)容
這里主要分為兩部分，一部分是模擬請(qǐng)求的接口參數(shù)，另外是模擬商品(如果產(chǎn)品是外部供應(yīng)商提供可能需求進(jìn)行 mock)或者外部依賴服務(wù)產(chǎn)生的數(shù)據(jù)。
壓測(cè)數(shù)據(jù)
- 數(shù)據(jù)類型：一是接口請(qǐng)求所需數(shù)據(jù)，如 10w 用戶賬號(hào)、100w 訂單;二是壓測(cè)所需產(chǎn)品數(shù)據(jù)準(zhǔn)備;
- 代碼上增加針對(duì)壓測(cè)數(shù)據(jù)過濾的邏輯，主要為了方便的進(jìn)行數(shù)據(jù)隔離和壓測(cè)結(jié)束環(huán)境恢復(fù);
- 有一些外部依賴不能參與壓測(cè)(可能會(huì)產(chǎn)生費(fèi)用或影響其他業(yè)務(wù)方)，需要添加模擬的請(qǐng)求返回
壓測(cè)資源
比如服務(wù)器，用到的中間件、數(shù)據(jù)庫(kù)等。
這里，我想重點(diǎn)說一下為什么要進(jìn)行數(shù)據(jù)隔離：
1)區(qū)分壓測(cè)流量與真實(shí)流量，方便壓測(cè)結(jié)束后進(jìn)行數(shù)據(jù)清洗。壓測(cè)結(jié)束后產(chǎn)生的交易、支付都要進(jìn)行撤銷，以免產(chǎn)生資損，落到數(shù)據(jù)庫(kù)中數(shù)據(jù)也要?jiǎng)h除。所以，將壓測(cè)流量產(chǎn)生的數(shù)據(jù)落到影子庫(kù)，可以方便進(jìn)行這些操作，如果沒有影子庫(kù)，也可以通過對(duì)壓測(cè)數(shù)據(jù)打標(biāo)簽，來進(jìn)行分區(qū)。
2)壓測(cè)數(shù)據(jù)隱藏，如果測(cè)試環(huán)境壓測(cè)可以不考慮這個(gè)問題，生產(chǎn)環(huán)境壓測(cè)產(chǎn)生的交易對(duì)客戶不可見，包括為了進(jìn)行壓測(cè)準(zhǔn)備的商品，對(duì)客戶也要隱藏。
3)防止壓測(cè)產(chǎn)生請(qǐng)求數(shù)據(jù)進(jìn)入報(bào)表統(tǒng)計(jì)。
以在火車票搶票壓測(cè)為例，處理的方式是對(duì) UID 進(jìn)行路由，壓測(cè) UID 產(chǎn)生的請(qǐng)求數(shù)據(jù)路由到影子庫(kù)中，真實(shí)請(qǐng)求的 UID 數(shù)據(jù)存在測(cè)試環(huán)境數(shù)據(jù)庫(kù)(壓測(cè)是在線下壓測(cè)環(huán)境進(jìn)行的)。
綜上，結(jié)合火車票搶票壓測(cè)示例來看，我們?cè)趬簻y(cè)前了做了如下準(zhǔn)備：
- 火車票搶票服務(wù)依賴其他服務(wù)，創(chuàng)建訂單時(shí)，對(duì)依賴部分做 mock;
- 創(chuàng)單數(shù)據(jù)同步訂單中心也是做了 mock;
- 準(zhǔn)備用與創(chuàng)單的用戶 uid;
- 將從cookie中獲取登陸狀態(tài)的代碼剝離，脫離對(duì)登錄的依賴，接口本身支持傳 uid 就可以創(chuàng)建訂單
圖3: 火車票搶票壓測(cè)服務(wù)拓?fù)?/p>
3. 構(gòu)建壓測(cè)模型
壓測(cè)模型是模擬用戶行為壓測(cè)場(chǎng)景，每個(gè)接口請(qǐng)求參數(shù)有什么特殊要求，一個(gè)場(chǎng)景中會(huì)同時(shí)有多個(gè)接口，這些接口的流量如何配比，后面壓測(cè)執(zhí)行時(shí)都按照這樣的場(chǎng)景進(jìn)行。那如何分析用戶的行為模式獲取到接口的流量配比，下面給出 2 種參考方法：
1)對(duì)于已經(jīng)上線的系統(tǒng)，采用系統(tǒng)日志或輔助的監(jiān)控系統(tǒng)獲得這些信息。大交通每個(gè)業(yè)務(wù)都接入了 CAT 系統(tǒng)，通過在 CAT 上查看每個(gè) URL 的請(qǐng)求量，
得出壓測(cè)場(chǎng)景中涉及到不同接口流量配比。
2)對(duì)于未上線的全新系系統(tǒng)，可以參考行業(yè)類似系統(tǒng)做分析，或公司類似業(yè)務(wù)做分析。
4. 編寫壓測(cè)腳本
按照用例描述，選擇工具進(jìn)行編寫。對(duì)壓測(cè)腳本的編寫，現(xiàn)在有很多成熟的工具，比如 JMeter、nGrinder?；疖嚻睋屍眽簻y(cè)工具選用了 JMeter。
三、壓測(cè)執(zhí)行
壓測(cè)過程需要開發(fā)、運(yùn)維同學(xué)參與，整個(gè)壓測(cè)執(zhí)行過程分兩部分：一個(gè)部分是啟動(dòng)壓測(cè)腳本對(duì)服務(wù)器產(chǎn)生請(qǐng)求壓力;一部分是監(jiān)控服務(wù)表現(xiàn)是否符合要求。壓測(cè)過程中通常關(guān)注的內(nèi)容有：
- CPU 使用率，通常要求 CPU 使用率<70%;
- 內(nèi)存使用情況，是否存在內(nèi)容泄漏;
- 系統(tǒng)業(yè)務(wù)完整性，返回結(jié)果是否正確;
- 系統(tǒng)響應(yīng)時(shí)間是否滿足業(yè)務(wù)要求;
- 系統(tǒng)處理能力是否穩(wěn)定，QPS 的大小在固定很小范圍內(nèi)抖動(dòng)比如，如果有規(guī)律的出現(xiàn) QPS 值跌落，則鏈路上可能存在某個(gè)服務(wù)處理比較慢;
- 觀察服務(wù)是否存在 ERROR/WARN 級(jí)別的報(bào)錯(cuò);
- 觀察服務(wù) GC 的頻率;
- 壓測(cè)結(jié)束后占用的資源是否正常釋放;
- 調(diào)整服務(wù)器數(shù)量看系統(tǒng)性能是否具備橫向擴(kuò)展的能力;
此外還有磁盤 IO、網(wǎng)絡(luò)帶寬等……
四、問題優(yōu)化
壓測(cè)目的是就是找出系統(tǒng)潛在的問題及系統(tǒng)各類資源參數(shù)設(shè)置，壓測(cè)問題調(diào)優(yōu)不同業(yè)務(wù)系統(tǒng)有不同解決方案，開發(fā)可能更有發(fā)言權(quán)，此處不贅述。列舉一些常見的方法：
- 數(shù)據(jù)庫(kù)進(jìn)行讀寫分離，單條寫改成批量寫;
- 不屬于關(guān)鍵鏈路上的服務(wù)不做重試或改為異步方式;
- 壓測(cè)過程中報(bào) connect: cannot assign requested address
原因：客戶端端口不夠，修改 sysctl.conf 文件配置
sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_timestamps=1
net.ipv4.ip_local_port_range = 1024 65535
- 通信的短鏈接改成長(zhǎng)連接;
五、記錄壓測(cè)報(bào)告，分析結(jié)果
壓測(cè)結(jié)束輸出壓測(cè)報(bào)告，分析不同壓測(cè)情況下測(cè)試結(jié)果找到拐點(diǎn)，得出系統(tǒng)處理能力，得出各類資源參數(shù)設(shè)置參考值。
一些建議
除了加機(jī)器，你還能做什么?
生產(chǎn)環(huán)境下，我們會(huì)遇到各種各樣的問題。有時(shí)，即使進(jìn)行了充分的性能測(cè)試，還是會(huì)出現(xiàn)問題。那么對(duì)于提高系統(tǒng)穩(wěn)定性，除了加機(jī)器，我們還有哪些方案呢?這里，給大家一些建議：
1)上線提前設(shè)計(jì)好限流方案，如：
- 活動(dòng)入口的時(shí)候增加游戲環(huán)節(jié)進(jìn)行消峰操作，還有秒殺前的倒計(jì)時(shí)也可以起到流量削峰;
- 在接口層面拒絕多余的訪問, 或者讓多余的訪問排隊(duì)等待服務(wù);
2)降級(jí)服務(wù)，下線一些輔助功能，減少資源的競(jìng)爭(zhēng);
3)引入緩沖機(jī)制;
4)實(shí)時(shí)監(jiān)控訪問量，一旦 QPS 超過預(yù)設(shè)的閾值，則可以考慮進(jìn)行擴(kuò)容以避免出現(xiàn)訪問量過大宕機(jī)。
路漫漫其修遠(yuǎn)兮，系統(tǒng)的穩(wěn)定性也是如此，通過不斷的解決問題積累經(jīng)驗(yàn)，以應(yīng)對(duì)日益增長(zhǎng)的業(yè)務(wù)需求。
本文作者：董敏，馬蜂窩大交通研發(fā)團(tuán)隊(duì)測(cè)試工程師，目前主要負(fù)責(zé)火車票相關(guān)業(yè)務(wù)的測(cè)試工作。
【本文是51CTO專欄作者馬蜂窩技術(shù)的原創(chuàng)文章，作者微信公眾號(hào)馬蜂窩技術(shù)(ID：mfwtech)】
