1、項(xiàng)目背景

翼賽是翼課網(wǎng)的業(yè)務(wù)線之一，其主要功能是在學(xué)校/區(qū)等大范圍競賽中，提供給學(xué)生的一個(gè)線上作答競賽平臺(tái)。競賽管理人員在后臺(tái)發(fā)布競賽后，學(xué)生登錄翼賽平臺(tái)，進(jìn)入對應(yīng)的競賽可進(jìn)行考試-提交等流程。為保障線上大流量用戶場景中，學(xué)生答題流程、使用體驗(yàn)正常，我們需要提前測試翼賽線上環(huán)境能否支撐應(yīng)用場景下的大流量并發(fā)，以便提前預(yù)知&解決大流量并發(fā)引發(fā)的問題。根據(jù)線上用戶使用數(shù)據(jù)，我們將并發(fā)數(shù)初步確定為10w。

2、壓測目標(biāo)

驗(yàn)證線上翼賽服務(wù)系統(tǒng)能否承擔(dān)10w流量的并發(fā)，發(fā)現(xiàn)風(fēng)險(xiǎn)點(diǎn)。

3、壓測環(huán)境

• 壓測環(huán)境主要包含兩部分：壓測系統(tǒng)和被壓測系統(tǒng)。
• 壓測系統(tǒng)：壓測系統(tǒng)為翼課網(wǎng)自主開發(fā)的一個(gè)流量控制平臺(tái)-APCT。
• 被壓測系統(tǒng)：RD在阿里云服務(wù)器上搭建的與線上測試環(huán)境一致的系統(tǒng)，共20臺(tái)服務(wù)器，用于接收和處理壓測產(chǎn)生的流量。

4、壓測系統(tǒng)-APCT1.1

4.1、壓測范圍

翼賽涉及到競賽管理人員在后臺(tái)發(fā)布競賽、學(xué)生在前臺(tái)作答共兩條主業(yè)務(wù)線。由于只有特殊的賬號(hào)才能在后臺(tái)發(fā)布競賽，所以后臺(tái)發(fā)布競賽的并發(fā)不高，不納入壓測范圍。翼賽作答的前臺(tái)包含了PC前臺(tái)和翼賽app。通過在諸葛io上獲取的數(shù)據(jù)（如下圖），可以看到在近一年中使用翼賽app的用戶量占總用戶量的94.2%，由此我們在PC和app中確定了被壓測軟件為app，在翼賽app中產(chǎn)生大流量并發(fā)的主流程為：登錄-作答-提交，所以最終將本次的壓測范圍確定為：翼賽app的登錄-作答-提交業(yè)務(wù)。

使用翼賽平臺(tái)占比.png

4.2、壓測場景

根據(jù)上面的數(shù)據(jù)分析，我們設(shè)計(jì)了以下核心測試鏈路：

測試鏈路圖.png

4.3、apct的系統(tǒng)架構(gòu)

系統(tǒng)架構(gòu)更新2.png

4.4、apct功能架構(gòu)

壓測系統(tǒng)-apct是一個(gè)分布式的流量發(fā)起和監(jiān)控平臺(tái)，它主要具備以下功能：

功能架構(gòu)圖.png

4.4.1 發(fā)布競賽

由于翼賽后臺(tái)賬號(hào)的特殊性（只有特定權(quán)限的賬號(hào)才能發(fā)布），我們設(shè)計(jì)的競賽發(fā)布前端頁面如下。在該頁面中填寫發(fā)布翼賽必要的參數(shù)：競賽后臺(tái)用戶登錄名，競賽后臺(tái)用戶登錄密碼，布置的學(xué)校名稱，競賽試卷id，競賽名稱，競賽開始時(shí)間，競賽結(jié)束時(shí)間，競賽作答時(shí)間，競賽學(xué)生數(shù)量，競賽練習(xí)試卷id。點(diǎn)擊“確認(rèn)發(fā)布按鈕”，參數(shù)校驗(yàn)通過，就可以發(fā)布一場競賽，如以下截圖。

發(fā)布翼賽頁面.png

4.4.2 一鍵壓測

發(fā)布競賽之后，頁面自動(dòng)跳轉(zhuǎn)到發(fā)起壓測頁面，上傳學(xué)生賬號(hào)，填寫必要的參數(shù)：壓測場景名稱，需要模擬的學(xué)生人數(shù)，流量釋放規(guī)則，各個(gè)鏈路場景的學(xué)生占比，點(diǎn)擊“開始測試按鈕”，參數(shù)校驗(yàn)通過并且已到競賽作答時(shí)間，即可發(fā)起壓測，如下圖：

一鍵壓測頁面.png

4.4.3 壓測數(shù)據(jù)處理

壓測過程中壓測引擎采集的各種統(tǒng)計(jì)數(shù)據(jù)將會(huì)上報(bào)到APCT相關(guān)業(yè)務(wù)，經(jīng)過一系列的處理計(jì)算之后業(yè)務(wù)相關(guān)數(shù)據(jù)以折線圖的形式展示在瀏覽器頁面中，接口相關(guān)數(shù)據(jù)以散點(diǎn)圖的形式展示，如下圖：

1. 以下圖形中的數(shù)據(jù)以5s為一個(gè)時(shí)間單位；
2. 登錄相關(guān)曲線圖中，黑色線表示當(dāng)前時(shí)刻的數(shù)據(jù)（當(dāng)前5s內(nèi)），紅色線表示從開始到當(dāng)前時(shí)刻的累計(jì)數(shù)據(jù)；
3. 測試過程中設(shè)置的接口連接超時(shí)時(shí)間為10s，接口read超時(shí)時(shí)間為10；
4. 從登錄成功數(shù)的曲線可以看出，學(xué)生的流量是分批釋放的，在18:56左右，全部學(xué)生釋放完畢，此時(shí)流量達(dá)到高峰；
5. 此處圖片均為測試總數(shù)據(jù)（壓測引擎上的數(shù)據(jù)+觀察引擎上的數(shù)據(jù)），觀察引擎上的數(shù)據(jù)見5.壓測結(jié)果；
6. 關(guān)于接口返回錯(cuò)誤的定義：當(dāng)接口響應(yīng)超時(shí)、接口沒有響應(yīng)超時(shí)但是返回?cái)?shù)據(jù)錯(cuò)誤，均記為接口錯(cuò)誤。
   
   登錄成功/失敗率.png

登錄成功/失敗數(shù).png

接口并發(fā)量.png

接口錯(cuò)誤率.png

接口響應(yīng)時(shí)間.png

4.5 壓測策略

4.5.1 引擎配置

為實(shí)現(xiàn)10w并發(fā)，我們共使用了2998臺(tái)壓測引擎，每個(gè)引擎上33-34個(gè)并發(fā)線程，2998*34≈10w。

4.5.2 逐步增壓

根據(jù)線上數(shù)據(jù)統(tǒng)計(jì)，高峰時(shí)期的流量通常是40%~60%的學(xué)生在競賽開始后30分鐘內(nèi)進(jìn)入作答頁面。在壓測過程中，為了模擬的更加真實(shí)，我們采用了逐步增壓的流量釋放規(guī)則，即每10s釋放500個(gè)用戶，在34分鐘內(nèi)將10w學(xué)生釋放完畢。通過4.4.3中的登錄成功數(shù)圖也可以看出，前期流量是逐步釋放的。

4.5.3 觀察對比

由于測試過程中，每個(gè)壓測引擎都會(huì)發(fā)起大量的流量到被壓測系統(tǒng)，當(dāng)在前端觀察到有數(shù)據(jù)異常時(shí)（比如某個(gè)/某些節(jié)點(diǎn)出現(xiàn)大量失?。覀儫o法判斷此時(shí)到底是客戶端本身導(dǎo)致的錯(cuò)誤，還是被測服務(wù)的錯(cuò)誤，所以我們?yōu)槊總€(gè)測試場景都設(shè)置了觀察引擎，以便觀察驗(yàn)證我們的服務(wù)是否正常：

登錄觀察引擎：與登錄壓測引擎業(yè)務(wù)一致，只是觀察引擎上采用單線程、低并發(fā)、無sleep、持續(xù)運(yùn)行。單線程、低并發(fā)是為了排除客戶端本身的影響，無sleep、持續(xù)運(yùn)行是為了盡可能多的采集到被測系統(tǒng)的響應(yīng)數(shù)據(jù)。由于觀察引擎的并發(fā)很低，那么只要它可以正常響應(yīng)，我們就認(rèn)為被測系統(tǒng)是正常的。

作答觀察引擎：與作答壓測引擎略有區(qū)別，壓測引擎上完成的業(yè)務(wù)是“登錄-作答（全部小題）-提交”，觀察引擎上完成的業(yè)務(wù)是“業(yè)務(wù)-作答（僅作答一道小題）-提交”。觀察引擎上采用單線程、低并發(fā)、無sleep、持續(xù)運(yùn)行。單線程、低并發(fā)是為了排除客戶端本身的影響，僅作答一道小題即提交、無sleep、持續(xù)運(yùn)行都是為了盡可能多的采集到被測系統(tǒng)的響應(yīng)數(shù)據(jù)。

5、壓測結(jié)果

5.1 測試總數(shù)據(jù)

1. 從登錄相關(guān)曲線圖中可以看出，10w并發(fā)流量上漲的過程中，會(huì)有部分學(xué)生登錄失敗，再結(jié)合接口響應(yīng)時(shí)間和接口錯(cuò)誤率散點(diǎn)圖，可以看出導(dǎo)致這部分學(xué)生登錄失敗的接口大部分是“/user/fastlogin”接口。
2. 從接口錯(cuò)誤率散點(diǎn)圖中可以看出，在流量上漲的過程中，“/exam/loadexamtest”接口的錯(cuò)誤率由20%逐漸增長到75%左右。但是從接口響應(yīng)時(shí)間圖中看到，該接口并沒有出現(xiàn)大量響應(yīng)超時(shí)的現(xiàn)象，這是因?yàn)椤?exam/loadexamtest”這個(gè)接口在高并發(fā)情況下返回了“服務(wù)器并發(fā)異常”的信息，期望返回正常的競賽題目信息。當(dāng)返回“服務(wù)器異?！钡男畔r(shí)，將該接口記為錯(cuò)誤+1。
3. 從接口錯(cuò)誤率散點(diǎn)圖中可以看出，在后期提交正常競賽時(shí)，“/exam/saveracedraft”和“/exam/submitrace”接口錯(cuò)誤率不斷上漲到30%左右，而從接口并發(fā)圖中看出，這兩個(gè)接口在錯(cuò)誤率上漲時(shí)，剛好處于并發(fā)量上漲階段。

登錄成功/失敗率.png

登錄成功/失敗數(shù).png

接口并發(fā)量.png

接口錯(cuò)誤率.png

接口響應(yīng)時(shí)間.png

5.2 觀察引擎數(shù)據(jù)

1. 測試過程中，觀察節(jié)點(diǎn)一直保持：登錄-作答-提交的無sleep循環(huán)，每個(gè)循環(huán)大概平均耗時(shí)4s（不考慮接口超時(shí)等特殊情況），觀察節(jié)點(diǎn)最先啟動(dòng)整個(gè)測試過程中一直運(yùn)行，但是由于流量釋放規(guī)則是每10s釋放500個(gè)學(xué)生，不能保證每個(gè)時(shí)刻的異常都能被觀察節(jié)點(diǎn)捕捉到。
2. 盡管觀察引擎中沒有catch到所有的接口錯(cuò)誤情況，但是從三個(gè)接口相關(guān)圖中仍能得出與測試總數(shù)據(jù)中的2和3相同的結(jié)論，此處不再贅述。
3. 關(guān)于接口返回錯(cuò)誤的定義：當(dāng)接口響應(yīng)超時(shí)、接口沒有響應(yīng)超時(shí)但是返回錯(cuò)誤數(shù)據(jù)均記為接口錯(cuò)誤。

登錄成功/失敗數(shù).png

接口并發(fā)量.png

接口錯(cuò)誤率.png

接口響應(yīng)時(shí)間.png

5.3 結(jié)論

1. 在流量上漲過程中，“/exam/loadexamtest”接口的錯(cuò)誤率不斷上漲，“/exam/loadexamtest”這個(gè)接口在高并發(fā)情況下返回了“服務(wù)器并發(fā)異常”的信息。
2. 在后期提交整場競賽時(shí)，“/exam/saveracedraft”和“/exam/submitrace”接口錯(cuò)誤率不斷上漲。
3. 綜上，我們認(rèn)為目前線上的翼賽環(huán)境在10w并發(fā)的情況下存在風(fēng)險(xiǎn)，需要針對上述兩條結(jié)論進(jìn)行優(yōu)化調(diào)整。

6、投入時(shí)間&資源

6.1 時(shí)間節(jié)點(diǎn)

項(xiàng)目時(shí)間節(jié)點(diǎn).png

6.2 引擎資源

引擎資源.png

來源：翼課網(wǎng)技術(shù)團(tuán)隊(duì)