微盟全鏈路壓測：如何幫助電商業務實現 10 倍效能提升？

一分鐘精華速覽

全鏈路壓測之所以被譽為電商大促備戰的 “核武器” ，是因為它基於實際的生產業務場景、系統環境，模擬海量的使用者請求和資料對整個業務鏈進行壓力測試，能真實反映系統的狀況，對系統風險和瓶頸真正做到心中有數。

微盟作為電商 SaaS 的龍頭企業，支撐著數十萬中小電商企業的經營，那麼在電商大促中微盟系統面臨過哪些容量保障挑戰？他們的全鏈路壓測又是如何發揮作用的？

作者介紹

微盟非功能測試負責人——趙金龍

TakinTalks 穩定性社群專家團成員，2017 年加入微盟，曾就職於上海北斗、攜程，多年來一直從事效能和穩定性保障相關工作；目前擔任微盟質量保障部非功能測試團隊負責人，負責微盟非功能測試體系建設，多次擔任大型專案一號位，帶領團隊完成了全鏈路壓測體系從 0 到 1 的建設與落地；主導壓測平臺、故障演練等平臺的建設。

溫馨提醒：本文約 4400 字，預計花費 7 分鐘閱讀。

後臺回覆 “交流” 進入讀者交流群；回覆“1071”獲取課件資料；

一、背景

微盟作為一家網際網路電商企業，服務著眾多商戶，在電商促銷活動期間，比如 618、雙 11、雙 12 等，微盟系統需要支援眾多商戶的大促活動，導致我們在這些活動期間的故障數量較多，在 2020 年之前微盟基本每次大促期間都會出現線上的事故。

針對這些事故覆盤後我們總結出很多不足，其中壓測這部分的問題我簡單地列了幾點——

1、單介面壓測為主

2、各業務單獨壓測

3、壓測場景不夠真實

4、壓測工具不能滿足高 QPS 複雜場景壓測

基於這些不斷的線上事故和覆盤出來的問題點，我們下定決心在 2020 年雙 11 期間落地全鏈路壓測。

二、落地全鏈路壓測遇到了哪些挑戰？

從 2020 年 4 月份開始立項來做全鏈路壓測，一直到雙 11 大促的整個專案落地期間，我們前後做了比較周密的籌備。

2.1 方案調研

首先是方案調研，我們瞭解到全鏈路壓測的目標是讓一切壓測結果更加真實，讓壓測更接近真實的使用者場景，所以壓測環境我們需要儘可能還原真實的線上環境；壓測資料要切合真實的交易場景以及對應的資料量級；壓測流量模型是非常重要的，它需要和真實業務情況保持一致；壓測流量發起需要模擬真實的使用者請求，在很複雜的流量模型下也能發起壓測流量；問題定位要求我們有完善的監控和告警系統，以協助服務端快速定位問題。

2.2 微盟當時現狀

在公司內部推進全鏈路壓測，我們面臨了非常大的挑戰，實際上在 2020 年之前我們每年都會討論落地全鏈路壓測，但最終都因為改造成本問題沒有實施。

推進的阻力主要是基礎架構元件版本不一致，各個業務方都有自己的技術棧，一些中介軟體、元件等選型使用都不一樣，還有一些非同步、回撥通知、Job 等等，我們要針對這些問題做改造來實現全鏈路壓測，成本是非常高的。

2.3 方案設計

為了應對 2020 年雙十一的流量衝擊，我們的實施方案經過了很多輪討論，下圖是我們最終的實施流程，線上全鏈路壓測我們需要做流量識別改造、資料隔離改造、影子儲存的配置。

我們在改造的同時，也部署了一套獨立的全鏈路壓測環境，基本復刻了核心業務線的線上環境，快速同步線上應用及配置，直接同步線上資料並脫敏，在雙 11 之前我們先在全鏈路壓測環境做了大量的壓測工作，包括各核心業務線的壓測，以及全鏈路壓測，在改造完成後，我們再在線上環境做全鏈路壓測驗證。

流量場景構造、壓測執行等等，都依賴著壓測的工具端，就會涉及到壓測平臺，所以在全鏈路壓測專案立項後，對應的壓測平臺我們也做了獨立的研發立項，這個在後面的平臺建設部分再做詳細介紹。

2.4 微盟流量模型

2.4.1 核心交易鏈路場景

前面有提到微盟的流量模型是非常複雜的，這是我們的核心鏈路模型。微盟是以電商零售業務為主的 SaaS 服務商，業務和天貓、京東有很多相似之處，核心以交易鏈路為主。

2.4.2 不同入口流量模型

我們會有各種促銷引流場景，比如拼團、秒殺等，也接入了很多渠道商引流，比如微信 H5 小程式、支付寶小程式、抖音、百度等，這裡麵包括各類優惠券引流以及活動商品引流等，在 2020 年還有一個非常火的場景是直播，直播業務場景也是我們非常核心的流量來源。

2.4.3 流量比例模型

壓測業務各個場景的流量比例模型是怎麼獲取？我們基於像 618 這類大型活動的峰值資料去做一些基礎資料，在雙 11 期間翻倍去壓測；還有其他的方式，如 CAT 統計交易配比，去統計不同活動期間的峰值流量模型。

2.5 壓測平臺的挑戰

在雙 11 期間我們做了多條業務線的驗證，其中最核心的兩條業務線就是電商零售和直播業務壓測，另外還有一些營銷活動等多條業務線需要混合壓測。我們梳理出來的核心介面有 100 +，當時以 618 的流量峰值做了翻倍的目標，目標 QPS 需要達到 12 萬+。

這裡我簡單列了當時的壓測場景，可以看到每個業務線都有非常多的介面，我們要儘可能都去壓測，包括每個介面都有它的目標 QPS 需要手動設定。

（2020 年微盟雙十一直播場景核心鏈路，介面眾多）

（2020 年微盟雙十一零售場景核心鏈路，介面眾多）

同時，壓測平臺是面向整個研發中心各個業務線去做的，所以涉及到的人會非常多，平臺對於多人協作也有一定的要求，比如壓測指令碼建立、壓測資料構造、壓測實時結果檢視等，在壓測期間，壓測團隊和研發團隊都會實時地檢視壓測結果，分析壓測期間的瓶頸點，所以這對於壓測平臺也是非常大的挑戰。

三、全鏈路壓測平臺建設有哪些技術要點？

前面有提到在 2020 年我們做全鏈路壓測立項的同時，壓測平臺也單獨做了立項，在立項之前的 2019 年，壓測只是微盟質量平臺的一個模組，且模組功能也比較簡單，所以順著全鏈路壓測的專案，2020 年 9 月壓測平臺 1. 0 版本正式上線，承擔了雙 11 期間的壓測任務執行。

2020 年-2022 年我們對平臺做了很多優化，比如 2021 年我們對壓測模型、場景設計、壓測報告做了優化，2022 年我們主要對監控和呼叫鏈分析做了一些優化。接下來我就微盟壓測平臺的建設，給大傢俱體做一些分享。

3.1 工具選型

在壓測平臺建設之前，還是單獨壓測模組時，我們已經對工具做了一些選型，當時不同的業務團隊使用的工具是不統一的，主要使用的有兩個壓測工具，Ngrinder 和 Jmeter。這裡可以看到每種工具都有其優缺點，比如，Ngrinder 是 B/S 架構的，在指令碼維護和壓測結果記錄方面，相比 Jmeter 的 C/S 有一定的優勢。針對微盟的實際情況以及全鏈路壓測對複雜場景的要求，我們最終選擇 Jmeter 作為壓測引擎，因為 Jmeter 有很多擴充套件外掛，我們可以做定製化開發；另外，在複雜場景設計上，它相對於 Ngrinder 有更大的優勢。

3.2 平臺架構

3.2.1 壓測平臺構成

壓測平臺分為 Server 端和 Agent 端，Agent 端主要是和壓測執行引擎 Jmeter 做了一些互動。Server 端的控制操作有很多模組，比如壓測資料構造、場景構造、壓測執行等。結果中心可以在壓測期間實時展示壓測結果，壓測執行完後，會有歷史結果的沉澱，且介面都會儲存一些基線版本的資料，這樣針對每個版本的壓測，會有版本之間的壓測資料對比。我們還對接了公司的監控系統、呼叫鏈平臺、資源監控告警等等。

最下面是資料儲存層，DB 用的 MySQL，實時資料用的 influx DB，在壓測期間的日誌和壓測結果，我們通過非同步的方式做儲存。

3.2.2 壓測執行鏈路圖

這是壓測平臺的壓測執行鏈路圖。從 Server 端發起壓力測試，第一步它會先去查詢空閒壓力機，並且鎖定對應的壓力機，這裡我只做了大概流程的展示，相對複雜的技術原理就不贅述了。接著執行壓測 agent 端，去建立壓測指令碼， download 引數檔案，引數檔案裡面有可能會涉及到檔案的拆分等等。

準備工作做完後排程壓測執行引擎，壓測執行引擎會涉及到兩部分結果，一個是 RunResult 實時結果，比如 TPS、響應時間等等；另外一部分是壓測的日誌記錄，比如一些錯誤日誌、響應內容等等都做了非同步的處理。

期間 Server 端可以實時展示結果，在執行結束後會針對壓測結果做持久化儲存， 有一個 addRunResult 的步驟會儲存所有壓測資料，可能會有一些異常導致結果儲存失敗，我們也有補償機制的設計，這是整個平臺執行排程的大概過程。

3.3 平臺能力

這裡重點介紹一下微盟整個壓測平臺的能力——

支援 http、https、dubbo 介面壓測，以及自定義 jar 壓測；

支援流量染色；

支援豐富的複雜鏈路場景配置，目前支援 3 種壓測模式（併發模式、RPS 模式、固定次數模式），5 種流量模型（固定壓力、階梯遞增）；

壓力機支援水平擴充套件，可發起超 25 萬 QPS 的壓力；

支援實時結果展示與歷史結果展示；

效能缺陷管理，效能問題知識庫；

提供 mock 能力，支援對第三方 mock 配置；

基於鏈路管理，聚合相關應用資源監控，包括 pod、DB、redis、es 等資源監控；

基於呼叫鏈資料監控，聚合鏈路中 top 耗時節點，以及鏈路節點耗時同比、環比分析；

3.4 產品應用展示

3.4.1 資料大盤

我們可以在平臺中看到整個資料大盤，一個是彙總大盤，還有一個實時大盤。可以實時看到壓測執行情況，以及歷史時間段的執行情況，目前的最新資料壓測執行已經超過 4 萬次了。

3.4.2 壓測場景-流量配比

施壓配置中的併發模式可以看到有一個流量配比，配置不同介面在整個場景裡的佔比。

3.4.3 壓測場景-RPS 模式

根據每一個介面的目標 QPS，在做階梯 RPS 遞增時，可以基於 RPS 成倍地增加壓力。

3.4.4 流量打標

前面提到我們有 Http 介面和 Dubbo 介面。Http 通過自定義請求頭資訊來新增壓測標識，Dubbo 是通過 RpcContext 做標識的傳遞。

(Http 介面流量打標）

(Dubbo 介面流量打標）

3.4.5 引數化設定

在壓測過程中，引數化設定至關重要，前面提到我們摒棄了 Jmeter 原生的 master slave 方式，所以對於引數控制提取要做對於改造，當我們使用到多臺 Agent 壓測，且需要保證請求引數不重複時，所以針對引數檔案我們要做獨立地拆分，我們可以在系統中通過兩個按鈕獨立地對檔案做拆分。

在做引數化設定時有很多引數化格式是一樣的，所以在構建壓測指令碼時，我們會新增一個全域性變數，這個變數以壓測 agent ID 作為標識，由於 agent ID 在資料庫中都是唯一的，所以做引數化設定時能夠保證引數的唯一性。

3.4.6 壓測實時結果

最終可以實時檢視壓測結果詳情、壓測結果聚合等，基於目標會做簡單的計算，分析壓測結果是否滿足預期目標、與目標相差多少等。

（壓測結果實時圖表）

（混合場景壓測報告）

3.5 壓測平臺效果

3.5.1 超 5000 次壓測執行 壓測平臺於 9 月 15 日上線提供給整個研發中心使用，在 2020 年雙十一壓測期間，平臺承擔了超過 5000 次壓測執行，裡面涉及 HTTP 介面、Dubbo 介面，以及鏈路場景的壓測。

3.5.2 QPS 10 倍提升

經過多輪線上壓測，電商零售場景的 QPS 從第一輪的不到 1 萬提升為 10 萬+，整體 QPS 有了 10 倍的提升，直播業務場景 QPS 也提升了 1.8 倍。

2020 年雙 11 期間，微盟線上沒有出現效能事故，通過全鏈路壓測保證了雙 11 平穩度過，我認為這是全鏈路壓測給我們帶來了比較明顯的收益。

四、壓測平臺在鏈路監控有哪些實踐？

每一個介面都有對應的呼叫鏈路，我們通過呼叫鏈平臺分析鏈路後，可以生成兩個清單，應用清單和介面清單。應用清單會基於 APPID 通過釋出平臺 CMDB 關係查詢到應用涉及的元件資源，如 DB、Redis、ES、Kafka 等等，進而拿到對應元件的監控資料。

基於介面清單，我們能夠分析鏈路中所有涉及到的呼叫節點，每個節點的耗時情況都可以通過呼叫鏈監控查到資料。有了這些資料，我們就能在鏈路監控上做一些分析。比如，可以在整個呼叫鏈中查詢 TOP 耗時的 API，並快速將高耗時的 API 列出來；再比如，基於不同版本介面的資料基線，對 API 做同比環比分析，以快速發現可能存在效能隱患的 API 等等。當然，這部分我們目前還在做優化，在分析上我們目前所提供的能力還不夠完善，這也是我們後面重點要做的事情。

4.1 鏈路元件資源監控

這是我們目前版本的簡單展示，這裡已經聚合了元件監控，可以看到 MySQL 部分的監控資料。

4.2 呼叫鏈路監控

呼叫鏈是支援手動和自動的鏈路管理。在壓測目標非常明確時，比如要壓某一個介面，想重點監控該介面依賴的某幾個 API，我們就可以通過手動的方式將這幾個 API 配置到鏈路監控當中。當壓測鏈路涉及到的節點很多，我們又想做完整的鏈路監控，此時就可以採用自動解析的方式。

4.3 鏈路監控收益

五、壓測平臺未來有哪些規劃？

未來我們希望是往穩定性保障平臺上做轉變，目前壓測平臺核心的功能主要是在壓測能力上，後面的規劃會涉及到 SLA 的管理，包括整合壓測 SLA 和故障演練 SLA。

我們也做了故障演練平臺的開發，基於故障演練平臺，我們要分析事故報告，提煉故障型別，不斷地豐富演練場景以及標準化的演練模板，還要去完善故障演練期間的故障記錄和場景覆盤。故障演練平臺和壓測平臺的整合，也是我們後面要做的事情。這是我們整個平臺後期的規劃。

（微盟故障演練平臺能力展示）

Q&A

Q1 ：除了壓測平臺還有哪些工具在配合使用？有沒有其他比較好的工具推薦？

Q2：完成壓測平臺建設，需要具備哪些條件因素？

Q3：工具模擬的場景，和真實使用者使用的場景有什麼區別？是不是能夠完全地匹配？

Q4：對於雙 11 壓測，遇到的一些對於效能提升比較大的實踐有哪些？

Q5：針對現有的架構環境開源的監控和自研有哪些優劣勢？

Q6：怎麼模擬混合場景，進行不同業務的容量測試？

答案請前往：http://news.shulie.io/?p=5638

瞭解更多全鏈路壓測落地細節，歡迎公眾號後臺回覆“交流”進入「讀者交流群」，和老師實時互動。

公眾號後臺回覆【1071】獲取資料

更多內容歡迎點選“閱讀原文”，進入「TakinTalks 穩定性社群」，獲取更多穩定性相關資料和知識。

宣告：本文由公眾號「TakinTalks 穩定性社群」聯合社區專家共同原創撰寫，如需轉載，請後臺回覆“轉載”獲得授權。

本文由部落格一文多發平臺 OpenWrite 釋出！