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

作者：拂衣、風雲

為什麼要做壓測

隨著無線裝置的普及和 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錄製外掛使用指導: http://help.aliyun.com/document_detail/187749.html

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

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

[4] JMeter 外掛使用指導： http://help.aliyun.com/document_detail/379921.html

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

釋出雲原生技術最新資訊、彙集雲原生技術最全內容，定期舉辦雲原生活動、直播，阿里產品及使用者最佳實踐釋出。與你並肩探索雲原生技術點滴，分享你需要的雲原生內容。

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