作者：暮角

隨著通過互聯(lián)網(wǎng)音視頻與知識建立連接的新學習方式在全國范圍內(nèi)迅速普及，在線教育/認證考試的用戶規(guī)模呈井噴式增長。但教育容不得半點馬虎與妥協(xié)，伴隨用戶規(guī)模不斷增長，保證系統(tǒng)穩(wěn)定性、有效避免千萬考生考試時遭遇故障風險，成為行業(yè)認證機構/部門解決的首要難題。

在某次行業(yè)認證考試后，考生登陸查分系統(tǒng)時遭遇白屏、卡頓等問題。因此，行業(yè)認證機構/部門開始探索系統(tǒng)穩(wěn)定性評估的路徑。不同于傳統(tǒng)線下行業(yè)可模擬出對等的生產(chǎn)環(huán)境，在線教育/行業(yè)認證的壓測難以實現(xiàn)同級別的服務集群。數(shù)據(jù)構造不真實、場景不符實際使用都會造成壓測任務與真實場景的偏差。此外，壓測工具缺乏安全性、人力成本、IT 成本投入大等問題亦亟待解決。因此，想要完美承受高壓檢驗，就需要進行細致的調(diào)研與準備工作。

為了幫助更多在線教育、認證機構/部門避免以上問題，我們完整復盤如何進行一次完整性能測試，涵蓋部署架構資源風險輸出與優(yōu)化、應用實時監(jiān)控與告警（可觀測性）、系統(tǒng)容量評估與性能優(yōu)化（壓測）、活動遠程保障與事后項目復盤。

第一步：需求調(diào)研與目標制定

為了更好的協(xié)調(diào)多方力量及保證項目執(zhí)行足夠聚焦，先設定一個業(yè)務目標。面對一個存在“白屏、卡頓”等問題的 Web 系統(tǒng)，與業(yè)務團隊溝通初步制定「系統(tǒng)可以支撐 5 萬 QPS 訪問量」的目標。由于即將來臨新的業(yè)務高峰，本次壓測的初衷并不是在兩周內(nèi)對應用系統(tǒng)進行大幅度技術改造，而是通過壓力測試發(fā)現(xiàn)應用的重大性能瓶頸并對之進行優(yōu)化改造，并通過流量摸高方式了解系統(tǒng)真實服務能力，輔以分流等手段保障服務的可用性。

第二步：資源評估

（一）工具評估

進行高并發(fā)服務保障，除了對應用的服務能力進行一定擴容之外。由于行業(yè)認證機構/部門此前在云上未進行過壓力測試，因此需要購買壓測工具以及相應的監(jiān)控工具，這里使用了阿里云性能測試 PTS、應用實時監(jiān)控服務 ARMS，這里需要注意的是：

• 性能測試 PTS， 工具本身不收費，根據(jù)流量進行收費，所以需要根據(jù)壓測規(guī)模、壓測目標、壓測次數(shù)，提前預估壓測資源包的額度。首次開通性能測試 PTS，贈送 5000 VUM 免費額度，可以用來幫助團隊熟悉工具的使用或進行初次測試。
• 應用實時監(jiān)控服務 ARMS， 目前按照數(shù)據(jù)寫入量進行計費，提供每個月 50 GB 免費額度，這個數(shù)據(jù)寫入量與 JVM 進程數(shù)量、存儲時間相關，免費額度基本滿足本次壓測需求。
• Web 應用防火墻 WAF， 由于本次壓力測試是在真實生產(chǎn)環(huán)境進行，流量會過 WAF。由于 WAF 按照流量計費，壓測目標超過用戶所購買的 WAF 規(guī)格包。WAF 3.0 版本，當前規(guī)格帶寬 100M，5K QPS，壓測目標 5 萬 QPS，超出部分按量計費，不使用不收費，按 45K QPS 估算，0.15/QPS/天，按 3 次壓測+分數(shù)查詢首日，共 4 次預估費用 2.7 萬元。

（二）資源梳理

• 與研發(fā)團隊對齊業(yè)務系統(tǒng)架構、業(yè)務資源容量情況及壓測環(huán)境、壓測工具和業(yè)務接口信息溝通。
• 關鍵業(yè)務接口梳理完成 (非全量，關鍵 API）。
• 重保壓測資源與費用評估。以 5 萬 QPS 為目標，系統(tǒng)壓力測試費用評估，包括測試所需的 ECS 、PTS、ARMS、WAF 等費用。
• 確定最終資源使用規(guī)劃。按生產(chǎn)等比配置測試環(huán)境，機器數(shù)量 6 臺，升級新購資源費用，初步費用評估完成。

第三步：壓測摸高

（一）第一輪壓測：問題初現(xiàn)

在完成壓測環(huán)境、系統(tǒng)數(shù)據(jù)準備以及壓測場景配置之后。開通 ARMS 完成 Java 應用接入，同時提供壓測環(huán)境的服務器清單，開始 PTS 壓測環(huán)節(jié)。其中，因為域名所屬行業(yè)特殊，PTS 壓測域名需要開白才可以。我們開始第一輪壓測。

【壓測結果】

「登錄-查分」并發(fā)用戶數(shù) 3000，平均 RT 1631ms，平均 TPS 1964，錯誤數(shù) 1.7 萬。

【問題發(fā)現(xiàn)】

應用壓測過程中有大量的 5s 超時問題，后續(xù)調(diào)整 PTS 超時時間。

【問題發(fā)現(xiàn)】

概覽所有環(huán)節(jié)中，驗證碼環(huán)節(jié)耗時最長，RT 平均能達到 7s 。

調(diào)整 GTM 主備配置互換，啟動第一輪壓測，最高 3K QPS 不及預期。同時，調(diào)整 tomcat 應用連接池大小至 4096。因為與生產(chǎn)環(huán)境共用，只能業(yè)務空閑時間進行壓測，導致壓測進度與預期不符，調(diào)整 SLB 轉(zhuǎn)發(fā)規(guī)則并指向測試服務器組。同時，阿里云建議后續(xù)研發(fā)團隊可將驗證碼信息存儲到 Redis 中來提升性能。從壓測情況看研發(fā)側優(yōu)化效果較好，但 RT 波動較大。云原生應用平臺團隊給出一些優(yōu)化建議后，RT 波動問題明顯改進。

（二）第二輪壓測：持續(xù)改進

在優(yōu)化了一些中間件優(yōu)化之后，我們基本逐漸提升并發(fā)用戶數(shù)繼續(xù)進行第二輪測試，并持續(xù)改進。

【壓測結果】

「登錄-查分」并發(fā)用戶數(shù) 1 萬，平均 RT 1560ms，平均 TPS 6082，錯誤數(shù) 6.2 萬。

「登錄-查分」并發(fā)用戶數(shù) 2 萬，平均 RT 2916ms，平均 TPS 6831，錯誤數(shù) 3390。

【問題發(fā)現(xiàn)】

通過對比測試，我們發(fā)現(xiàn)應用承載能力就是 1 萬并發(fā)用戶數(shù)、平均 RT 1.5s。提升 1 倍并發(fā)用戶后，服務器平均 TPS 沒有提升，只是 RT 增加了 1 倍。

針對上述問題，研發(fā)團隊進行了優(yōu)化。通過在內(nèi)網(wǎng)使用 Jmeter 測試，看到單臺服務器性能有明顯提升，并發(fā)現(xiàn) Redis 存在可優(yōu)化點。進一步分析發(fā)現(xiàn)，很多慢請求都是訪問用戶的自建 Redis，但研發(fā)團隊反饋 Redis 延時很小，并且切換到阿里云 Redis 后未發(fā)現(xiàn)改進。因為之前驗證碼環(huán)節(jié)性能很差，壓測環(huán)境都跳過該環(huán)節(jié)。目前這部分優(yōu)化已經(jīng)完成，在測試增加了驗證碼環(huán)節(jié)。驗證碼環(huán)節(jié)壓測需要特殊配置，配置好后繼續(xù)測試。當天結果瓶頸還未找到，QPS 穩(wěn)定在 1.2 萬、RT 2-3s，再加大壓到 5 萬，無明顯改善。

（三）第三輪壓測：問題突破

因為目前整體服務承載能力多次優(yōu)化后，穩(wěn)定無法提升，阿里云建議嘗試通過增加服務器數(shù)量壓測，由此判斷是應用服務器性能，還是數(shù)據(jù)庫服務器性能導致目前瓶頸。如果橫向擴展應用服務器性能能提升，就是應用服務器問題，否則就是數(shù)據(jù)庫這種單點服務的問題。應用服務器從 6 臺增加到 8 臺，服務能力并未看到線性上升，QPS 增加到 1.3 萬左右。結合此現(xiàn)狀，可以判斷是單點問題限制，推斷可能是 Oracle 數(shù)據(jù)庫、Redis，但研發(fā)團隊反饋壓測時兩個產(chǎn)品鏈接不多，響應速度在毫秒級。經(jīng)過對壓測報告的分析，發(fā)現(xiàn)滑塊驗證處理比較慢，耗時較長，研發(fā)團隊將滑塊驗證改為字符驗證碼。并發(fā)起新一輪的壓測。

【壓測結果】

添加 Redis 后，3 萬用戶，3 分鐘，性能幾乎翻倍。

「登錄-查分」并發(fā)用戶數(shù) 3 萬，平均 RT 1514ms，平均 TPS 20145，錯誤數(shù) 2960。

「登錄-查分」并發(fā)用戶數(shù) 5 萬，平均 RT 4552ms，平均 TPS 13744，錯誤數(shù) 21.6 萬。

【問題發(fā)現(xiàn)】

通過對比測試，發(fā)現(xiàn)應用服務器的承載能力在翻倍提升后，穩(wěn)定在 2 萬 TPS。即便把并發(fā)提升到 5 萬，該指標也未能再繼續(xù)提升。Redis 擴容后(64c 128g *3)，性能提升 1 倍，RTS 穩(wěn)定在 2.2 萬，RT 1-2s 。嘗試使用阿里云 Redis（7c8g 4db）壓測，但與自建 Redis 相比規(guī)格小太多，測試結果性能提升不大。

應用 8 臺服務器最高 QPS 到 2.5 萬，按照 5 萬 QPS，屆時分流需要拆分 2.5 萬到靜態(tài)頁面。測試壓測單臺分流服務器靜態(tài)頁面 RTS 支撐能力為 4 萬，靜態(tài)頁面使用 404 頁面是否合理待評估?！?/p>

登錄-繁忙」并發(fā)用戶數(shù) 2.5 萬，平均 RT 582ms，平均 TPS 41772，錯誤數(shù) 10.9 萬。

SLB 負載不均是健康檢查失敗導致的，靜態(tài)頁返回 404，SLB 層面不會抑制請求轉(zhuǎn)發(fā)，會正常分發(fā)請求給該應用服務器。

第四步：上線保障

在上述多輪壓測以及優(yōu)化之后，我們進行最后一輪壓測：業(yè)務服務器+靜態(tài)頁面 壓測達到預期業(yè)務目標 5 萬 QPS，按 3 : 1 比例分發(fā)請求，度過業(yè)務高峰后快速關閉靜態(tài)頁服務器。

【壓測結果】

「登錄-查分」并發(fā)用戶數(shù) 2.5 萬，平均 RT 1030ms，平均 TPS 22965，錯誤數(shù) 44（6 臺生產(chǎn)機器總體處理能力）。

「登錄-查分」并發(fā)用戶數(shù) 2.5 萬，平均 RT 396ms，平均 TPS 64887，錯誤數(shù) 72.2 萬。

【壓測摸高】

10 臺應用服務處理能力最高 2.5 萬 TPS，其中 3 臺應用服務器上同時部署靜態(tài)頁面，應用程序和靜態(tài)頁面權重比例 1 : 1壓測。并發(fā) 4 萬、RT 396ms、TPS 64887ms、達到預期目標 5 萬 TPS。最后一次持續(xù)高并發(fā)壓測，并發(fā) 2.5 萬，RT有抖動，TPS 維持在 2 萬，成功率 99% 以上。通過最后的壓測結果，結合資源現(xiàn)狀進行保障方案落地：開放查分入口首日，靜態(tài)頁面與應用程序權重比例調(diào)整為 100 : 30 ，總體處理能力 3 萬 TPS。

【開放查分】

晚 23 時開放查分，流量小于預期，系統(tǒng)平穩(wěn)運行度過峰值 QPS 1.6W。

第五步：優(yōu)化總結

經(jīng)過多輪的壓測以及前期優(yōu)化，應用及架構找到多個瓶頸點并進行改造優(yōu)化，比如驗證碼模塊性能差、單 Redis 改為集群 Redis、應用多線程處理能力、業(yè)務處理能力隨資源增加而線性提升等都進行相應的驗證和優(yōu)化。在現(xiàn)有條件下，優(yōu)化后的應用和架構的健壯性大幅提升，積累了該應用的資源容量評估經(jīng)驗，后續(xù)可以隨著業(yè)務量增減，有數(shù)據(jù)依據(jù)的增減資源，日常保持好水位線即可。同時，我們梳理了諸多日常優(yōu)化方案，其中包括：

一、安全風險預警。

重保期間請求流量尚未經(jīng)過 Web 應用防火墻，缺失常見攻擊防御能力，后續(xù)考慮請求流量過 WAF 且動靜資源分離，靜態(tài)資源通過 CDN 加速分發(fā)。一方面，減輕業(yè)務服務器對靜態(tài)資源處理壓力和帶寬壓力；另一方面，有效降低 WAF 帶寬壓力與成本。

二、數(shù)據(jù)庫產(chǎn)品存在單點風險與升降配不靈活問題。

在 ECS 云服務器上的自建 Oracle 數(shù)據(jù)庫存在單點故障風險，一旦單個服務出現(xiàn)異常整個平臺會徹底不可用。自建的 Oracle 數(shù)據(jù)庫與 Redis 服務，無法靈活改配，不便于日常使用與重保期間進行能力切換。后期計劃通過改造使用云上的數(shù)據(jù)庫，加強可用性的同時，靈活升降配，進一步貼近當前業(yè)務需求。

三、應用存在大規(guī)格服務器資源無法利用問題。

目前應用單體架構耦合度高，無法經(jīng)濟的單獨部署更多涉及性能瓶頸的模塊。后續(xù)計劃對應用內(nèi)部模塊進行拆分，以便讓應用可以有更合理的部署架構。另外，針對目前問題，后續(xù)重保期間擴容的應用服務器采用更多低規(guī)格服務器來提升性能。從現(xiàn)在的 64C128G 變?yōu)?16C32G，從而獲得 4 倍應用服務能力。

四、在日常研發(fā)中使用 PTS 進行持續(xù)壓測。

通過本次重保壓測，研發(fā)團隊已經(jīng)在阿里云 PTS 產(chǎn)品團隊支持下充分掌握該工具的使用方法。該工具擁有的快速創(chuàng)建多地壓測節(jié)點的能力充分利用的阿里云平臺的多地域優(yōu)勢，能快速模擬實際業(yè)務場景進行全鏈路壓測，大大的節(jié)約了應用問題發(fā)現(xiàn)與改進時間。是本次重保環(huán)節(jié)中的核心功臣。

五、繼續(xù)在日常應用服務環(huán)節(jié)使用 ARMS 監(jiān)控。

通過 ARMS 應用監(jiān)控，在壓測過程中發(fā)現(xiàn)很多細節(jié)問題，為快速的定位問題提供極大便利，大大提升問題定位效率，是不可多得的運維必備工具。

第六步：查漏補缺

一、PTS 是一款非常容易上手且便捷的壓力測試工具，使用 PTS 可以迅速提升測試效率；

1）使用自帶的錄制控件可以快速錄制場景，自動捕捉需要壓測的接口；

2）產(chǎn)品公共云值班同學能耐心給予產(chǎn)品問題解答，即便是新手也可以立即上手使用；本次測試過程中，研發(fā)團隊是第一次使用該產(chǎn)品，交付團隊也不是熟手，但是使用十分絲滑，整個過程中并未覺得不順手；

二、通過壓測發(fā)現(xiàn)系統(tǒng)瓶頸的過程是一個持續(xù)尋找問題的過程，壓測能給系統(tǒng)壓力然后暴露出系統(tǒng)的瓶頸；

1）單 Web 服務器并發(fā)能力需要第一步得到答案。分布式架構或者單體架構都沒關系，重要的是要獲取每個服務角色的單機能力。服務器的規(guī)格并不是越大越好，比如這次我們最后都無法給予一個 64C128G 的 Web 服務器超過 50% 壓力，合適的規(guī)格是業(yè)務規(guī)劃最重要的評估項。

2）確認單 Web 服務節(jié)點的能力后，就可以提升服務器數(shù)量進行整體壓測，這樣擴展下去就能知道在達到壓測目標的情況下，每個服務器角色需要多少臺。除非是嚴重的 Web 服務角色節(jié)點性能問題，短期內(nèi)提升服務器數(shù)量都可以大規(guī)模提升服務能力。

3）想要更快的暴露系統(tǒng)架構中的單點瓶頸，可以橫向擴展的服務器擴展到一定規(guī)模。這種單點瓶頸一般就是數(shù)據(jù)庫，例如關系型數(shù)據(jù)庫、緩存數(shù)據(jù)庫、分布式數(shù)據(jù)庫。如果壓測到單點瓶頸，優(yōu)化關系型數(shù)據(jù)庫最簡單的方式就是提升服務器規(guī)格；如果無可提升就需要使用讀寫分離來分擔壓力。如果使用可以橫向擴展的數(shù)據(jù)庫，就可通過擴容節(jié)點來提升能力，使系統(tǒng)整體服務能力提升。在高并發(fā)場景下，使用內(nèi)存數(shù)據(jù)庫無疑是提升能力的快速通道，尤其是考試查分這種只讀場景。

三、短時間內(nèi)能做的事情十分有限，重保這種高并發(fā)場景要做的就是保障系統(tǒng)可用性；

1）我們本次壓測的系統(tǒng)是一個適用于傳統(tǒng)自建 IDC 機房并有一定技術歷史包袱的系統(tǒng)，采用 Windows + Oracle + 單體架構，想要在短期內(nèi)改變架構很難。為了保障近期重要的高并發(fā)場景，研發(fā)團隊聚焦于把解決嚴重的性能缺陷，扛過保障時點。

2）服務分流是保障系統(tǒng)可用性的最簡單手段，8 臺 Web 服務器測試得到的應用最高 QPS 才 2 萬余，單臺 Web 服務器能承載的繁忙頁 QPS 就能達到 1 萬 QPS。所以，關鍵時刻保障部分用戶可用即可。在完全不可用與排隊間取舍，一起排隊用已是最優(yōu)解。

3）上線前一定要做好保障演練。前端 SLB 最大能承載的流量就是 5 萬 QPS，這也是本次演練的目標。因此設計了正式應用服務器承載 3 萬 QPS 流量，繁忙頁承載 2 萬 QPS 流量，在 SLB 端配置權重比例。ARMS 應用監(jiān)控是秒級監(jiān)控且調(diào)整 SLB 權重實時生效，但只對新連接請求生效，原有長連接不受新權重影響。文章來源地址http://www.zghlxwxcb.cn/news/detail-816856.html

到了這里，關于考試查分場景重保背后，我們?nèi)绾芜M行可用性測試的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！