如何做“健康碼”的性能壓測

作者：拂衣、風云

為什么要做壓測

隨著無線設備的普及和 5G 的大力建設，越來越多的線上系統、小程式成為了人們生活中必不可少的工具，對于這些工具，都會面對一個問題：系統能承受多少用戶同時訪問，面對突發的流量洪峰，能否保證系統無故障穩定運行？

為了回答這個問題，就需要在系統上線前做多輪壓力測驗，提前模擬出復雜的, 高仿真的線上流量來驗證整體系統的高可用性, 這也是實施系統高可用方案的關鍵環節，另外,通過不同階段的壓測，也完成對系統的容量規劃、瓶頸探測，對系統整體能力進行驗收，確保在突發的流量洪峰來臨前，系統確實能夠承受即將來臨的真實線上壓力，

從某種意義上來說，壓測是系統穩定性的驗證者，

如何實施一次準確的性能壓測

準備壓測環境

壓測的執行環境是一個老生常談的話題，如果直接在生產環境執行壓測，會有2個問題：

1、會影響線上業務，對正常訪問系統的用戶造成影響

2、會污染線上資料，將壓測資料寫入線上資料庫

為了解決這 2 個問題，一般業內采用如下幾種方案：

以上方案各有優缺點，適用場景也不盡相同，可以根據自己專案所處的階段靈活選擇方案，

構建壓測腳本

業內常用的壓測工具包括 JMeter、Gatling、Locust、k6、Tsung、阿里云 PTS 等，這些工具無一例外，都需要將壓測業務的 API，編排為一個壓測腳本，

這一步作業的重點在確認壓測的 API，不要有遺漏，且 API 編排的順序要符合用戶的操作邏輯，對于健康碼業務的壓測來說，如果腳本中遺漏了登錄鑒權 API，那后面的重繪健康碼、查看核酸報告等 API 都會在權限校驗這步就報錯，不會執行正常的業務邏輯，也就無法模擬真實的業務場景，

以上壓測工具編排腳本都有 2 個方式：

1、手動輸入腳本，這需要腳本的撰寫人員對業務非常熟悉，保證不會遺漏API，

2、自動錄制腳本，上述開源壓測工具都提供了錄制請求的代理功能，開啟并配置代理后，只要在頁面上模擬用戶的操作和點擊行為，即可自動錄制請求，并生成壓測腳本，同時 PTS 還提供了 Chrome 錄制插件[1]，免代理配置，可以一鍵生成 JMeter 和 PTS 壓測腳本，提升了腳本撰寫的效率，也能保證不遺漏 API，

為了避免復雜腳本中遺漏 API 的風險，推薦使用錄制功能生成腳本，

確認壓力模型

這一步是在配置壓測中模擬的壓力峰值、不同 API 的壓力分布比例以及壓力值遞增模型，壓力值指的是模擬并發用戶數，或每秒發送的請求數，

施壓模式

在設定之前，需要確認施壓模式，業內主要有 2 種施壓模式：

1、虛擬用戶(VU)模式，可以理解為一個執行緒模擬一個真實用戶，壓測時執行緒一直回圈執行，模擬用戶不停地發送請求，

2、吞吐量模式，即每秒請求數(QPS)，可以直接衡量服務端的吞吐量，

在專案驗收階段，很重要的一個指標就是系統的吞吐量，即可支持的QPS，對于這種壓測場景，更推薦使用吞吐量模式，可以直觀的看到施壓機每秒發出的請求數，并和服務端的吞吐量直接對應起來，

各 API 壓力分布比例

確認了施壓模式后，需要配置不同 API 的壓力分布比例，比如健康碼業務，100% 的用戶會呼叫登錄 AP 和獲取健康碼 API，但后面并不是所有用戶都會呼叫查詢核酸報告 API、查看推送資訊等 API，所以每個 API 的準確壓力分布比例，也是一次成功壓測中不可獲取的因素，

壓力值遞增模型

常見有脈沖模型，階梯遞增，均勻遞增，

脈沖模型會模擬流量在瞬間突然增大，常用于秒殺、搶購的業務場景，

遞增模型可以模擬在一定時間段內，用戶量不斷增大，常用于模擬有預熱的業務場景，

除了常規的遞增模型，最好在壓測中可以實作手動調速功能，一是可以模擬一些非常規的流量遞增情況，二是可以反復調整壓力值，來復現和排查問題，

施壓流量地域分布

確定了壓力值和遞增模型后，還需要確定施壓流量的地域分布，應盡量擬合真實的用戶分布，才能保證測驗結果真實可信，

對于區域性的在線業務，施壓機分布在當地的同一機房，是可以理解的，如果是全國性的在線業務，施壓機也應該按照用戶分布，在全國各地域部署，

執行壓測，觀察壓測指標

壓測中核心指標：請求成功率，請求回應時間（RT），系統吞吐量（QPS）

請求成功率不止要看全域的請求成功率，還要關注一些核心API的成功率，避免整體成功率達標，核心 API 成功率不足的情況，

請求回應時間，需要關注 99、95、90、80... 等一些關鍵分位的指標是否符合預期，而平均回應時間沒有太大的參考意義，因為壓測需要保證絕大部分用戶的體驗，在不清楚離散程度的情況下，平均值容易造成誤判，

系統吞吐量是衡量系統能承受多大訪問量的指標，是壓測不可缺少的標準，

上面三個指標遇到拐點時，就可以認為系統已經出現性能瓶頸，可以停止壓測或調小壓力值，準備分析、定位性能問題了，

除了這三個業務指標，同時還應該同時觀測系統的應用監控、中間件監控和硬體監控的一些指標，包括但不限于：

服務器：

• 網路吞吐量
• CPU 使用率
• 記憶體使用率
• 磁盤吞吐量
• ......

資料庫：

• 連接數
• SQL 吞吐量
• 慢 SQL 數
• 索引命中率
• 鎖等待時間
• 鎖等待次數
• .....

中間件：

• JVM GC 次數
• JVM GC 耗時
• 堆內、堆外記憶體使用量
• Tomcat 執行緒池活躍執行緒數
• ......

更多壓測時需要關注的指標，見壓測指標[2]

如果系統已經達到預期，往往還可以可以按照 10-20% 的比例，不斷加大壓力值，為系統做一次峰值“摸高”，觀察系統的極限值是多少，做到心里有底，

復盤，性能優化

壓測結束，如果未達到預期，可以配合監控排定位，分析性能問題，性能優化完成后，在下一輪壓測中繼續驗證，

測驗中問題分析和調優的方法這里不展開描述，可以參考這篇測驗問題分析及調優[3]，

如果系統表現已經符合預期，可以用壓測得到的系統吞吐量指標，配置流控、降級、系統或隔離規則，保障系統穩定性，

阿里云 PTS - 壓測大禮包，助您系統無憂

性能測驗 PTS（Performance Testing Service）是一款阿里云 SaaS 化的性能測驗工具，從最早為了精準模擬雙十一流量洪峰誕生，到現在已經走過了 10 個年頭，每年支持包括雙十一在內的全集團范圍的幾萬次壓測任務，是阿里內部雙十一技術架構的"提前驗證者"，

技術讓利 1 — 自研 PTS 壓測引擎，壓力模型準，性能優

PTS 完全自研的壓測引擎，在并發模型的實作上相較傳統執行緒模型性能更優，并且支持 API 維度的吞吐量配置，比開源工具更精細，可以準確模擬流量漏斗模型，

比如真實的流量模型是 100% 用戶會呼叫登錄 API，80% 用戶會呼叫重繪健康碼 API，20% 用戶會呼叫查看核酸 API，這就需要在每個 API 上配置吞吐量（QPS），如果使用并發模型，就無法模擬此場景，

漏斗模型示例：

PTS 壓測還支持多種客戶端的流量錄制功能，可以快速構建壓測腳本，并支持完全白屏化的操作，讓壓測腳本構建的門檻大大降低，

技術讓利 2 — 全面兼容 JMeter，上線 JMeter 插件

PTS 在全面兼容 JMeter 的同時，針對 JMeter 分布式壓測做了很多優化：

優化點 1：全球分布施壓機，即壓即用，可支持百萬并發，千萬 QPS 壓測；

優化點 2：支持吞吐量模式，可以設定全域目標 QPS，更直觀衡量服務端性能；

優化點 3：支持壓測中調速，可以靈活調整并發或 QPS，不斷逼近性能極限點；

優化點 4：支持瀏覽器插件錄制，一鍵匯出 JMeter 腳本，無需配置代理，大大降低構建腳本的作業量；

優化點 5：針對分布式壓測，支持自動切分檔案，支持全域生效 Timer、Controller 組件，零門檻開啟分布式壓測；

優化點 6：發布 JMeter PTS 插件，使用 JMeter GUI 客戶端即可發起云端分布式壓測，無縫銜接腳本除錯和執行階段（詳見 JMeter 插件使用指導[4]），

技術讓利 3 — VPC 內網壓測

在全面正式壓測前，重點微服務應用需要在日常態做單應用的壓測，摸清楚區域的性能極限，

對于部署在阿里云上的服務，單個微服務應用不會暴露公網入口，這時就需要壓測工具有打通 VPC 內網的能力，

PTS 支持 VPC 內網壓測，可以在壓測時快速打通施壓機與用戶 VPC 網路，保證內網壓測的網路暢通，在壓測結束后，也會即時關閉網路通道，保證網路安全，

用戶只需要在壓測配置中，選擇微服務應用所在的 VPC 內網、安全組、交換機，即可開啟 VPC 內網壓測，讓您的服務無需暴露公網入口，也可以探測出性能指標，

操作示例如下：

技術讓利 4 — 流量地域定制

大部分業務的用戶并不是按地域均分的，相反，往往很不均勻，要模擬真實流量分布，施壓機需要在各地分散部署，并且支持按地域、按量分配，在壓測時，還要支持實時的統一調度，如果施壓機都分布在一個 Region，甚至是一個可用區內，那是無法模擬出來自全球用戶請求的，

使用阿里云性能測驗服務（PTS）壓測時，開啟流量地域定制功能，只需簡單勾選地域，即可指定施壓機的地域分布，目前支持全球 22 個地域定制，

技術讓利 5 — 問題診斷工具

壓測的目的是發現性能問題，在壓測報告中，PTS 有例外請求狀態碼的統計，并提供了請求采樣日志，可以直觀的看到請求、回應的全部資訊，對于回應時間較長的請求，也會直觀的展示請求在各個階段的耗時，

對于 Java 應用，PTS 提供了基于 Java Agent 的問題診斷工具，只需在 Java 應用上掛載探針，即可自動獲取應用、API、機器維度的秒級監控，對于報錯的請求，可以直接定位到呼叫鏈上報錯的方法堆疊，省去了大量排查問題的時間，是定位問題的“利器”，

定位報錯方法堆疊示例如下：

成本讓利 1 — 上線 JMeter 資源包

PTS 上線了 JMeter 專屬資源包，價格相比 PTS 壓測資源包更加優惠，

成本讓利 2 — VPC 內網壓測價格更優

PTS 上線了 VPC 內網壓測資源包，1 萬并發壓測 20 分鐘，僅需 29 元起，讓日常態內網壓測成本更低，

成本讓利 3 — 包年包月包，限時優惠75折

包年包月資源包，限時優惠 75 折，且在包月時間段內，不計 VUM，適合高頻壓測的用戶，

成本讓利 4 — 定制資源池

對于高并發，需要壓測時間較長的情況，推薦使用定制資源池，20 臺施壓機以上，連續壓測 1 小時的情況下，計費相當于正常壓測的 4 折，讓長時間、高并發壓測的用戶支付成本更低，

點擊閱讀原文，即可前往 PTS 資源包購買頁[5] ，歡迎大家按需選購，

相關鏈接

[1] Chrome錄制插件使用指導:
https://help.aliyun.com/document_detail/187749.html

[2] 壓測指標:
https://help.aliyun.com/document_detail/29338.html

[3] 測驗問題分析及調優：
https://help.aliyun.com/document_detail/29342.html

[4] JMeter 插件使用指導：
https://help.aliyun.com/document_detail/379921.html

[5] PTS 產品購買頁：
https://common-buy.aliyun.com/?commodityCode=ptsbag

發布云原生技術最新資訊、匯集云原生技術最全內容，定期舉辦云原生活動、直播，阿里產品及用戶最佳實踐發布，與你并肩探索云原生技術點滴，分享你需要的云原生內容，

關注【阿里巴巴云原生】公眾號，獲取更多云原生實時資訊！

標籤：其他

上一篇：SchedulerX 如何幫助用戶解決分布式任務調度難題？

下一篇：深度學習：多層感知機和異或問題(Pytorch實作)