摘要：有贊對于性能測試主要有線下單系統單接口線上單系統以及線上全鏈路壓測等手段，通過不同維度和顆粒度對接口系統集群層面進行性能測試，最終保障系統的穩定性。這里主要講述一下，有贊全鏈路壓測的相關設計和具體的實施。

有贊致力于成為商家服務領域里最被信任的引領者，因為被信任，所有我們更需要為商家保駕護航，保障系統的穩定性。有贊從去年開始通過全鏈路壓測，模擬大促真實流量，串聯線上全部系統，讓核心系統同時達到流量峰值：

驗證大促峰值流量下系統穩定性

容量規劃

進行強弱依賴的劃分

降級、報警、容災、限流等演練

...

通過全鏈路壓測這一手段，對線上系統進行最真實的大促演練，獲取系統在大壓力時的表現情況，進而準確評估線上整個系統集群的性能和容量水平，不辜負百萬商家的信任。

有贊對于性能測試主要有線下單系統單接口、線上單系統以及線上全鏈路壓測等手段，通過不同維度和顆粒度對接口、系統、集群層面進行性能測試，最終保障系統的穩定性。這里主要講述一下，有贊全鏈路壓測的相關設計和具體的實施。

說到全鏈路壓測，業內的淘寶、京東都都已有很成熟的技術，主要就是壓測流量的制造、壓測數據的構造、壓測流量的識別以及壓測數據流向的處理；直接看下有贊壓測的整體設計：

大流量下發器：其實就是模擬海量的用戶去使用我們的系統，提供壓測的流量，產生大促時的場景和流量；

數據工廠：構造壓測鏈路中用戶請求的數據，以及壓測鋪底的數據、數據清洗、脫敏等工作；

壓測平臺負責管理壓測腳本和壓測請求數據，從數據工廠獲取壓測數據集，分發到每一個壓測 agent 機器上，agent 根據壓測腳本和壓力目標對線上機器發起請求流量，模擬用戶的查看商品-添加購物車-下單-支付等行為，線上服務集群識別出壓測的流量，對于存儲的讀寫走影子存儲。這里就要說到，線上壓測很重要的一點就是不能污染線上的數據，不能讓買賣家有感知，比如壓測后，賣家發現多了好多訂單，買家發現錢少了。所以，線上服務需要能夠隔離出壓測的流量，存儲也需要識別出壓測的數據，下面看一下有贊的壓測流量和壓測數據存儲的隔離方案。

要想壓測的流量和數據不影響線上真實的生產數據，就需要線上的集群能識別出壓測的流量，只要能識別出壓測請求的流量，那么流量觸發的讀寫操作就很好統一去做隔離了，先看一下有贊壓測流量的識別：

全鏈路壓測發起的都是Http的請求，只需要要請求頭上添加統一的壓測請求頭，具體表現形式為:
Header Name:X-Service-Chain;
Header Value:{"zan_test": true}

Dubbo協議的服務調用，通過隱式參數在服務消費方和提供方進行參數的隱式傳遞，表現形式為：
Attachments:X-Service-Chain;
Attachments Value:{"zan_test": true}

通過在請求協議中添加壓測請求的標識，在不同服務的相互調用時，一路透傳下去，這樣每一個服務都能識別出壓測的請求流量，這樣做的好處是與業務完全的解耦，只需要應用框架進行感知，對業務方代碼無侵入

NSQ:通過 NSQMessage 中添加 jsonExtHeader 的 KV 拓展信息，讓消息可以從 Producer 透傳到 Consumer 端，具體表現形式為：Key:zan_test;Value:true

Wagon:對來自影子庫的 binlog 通過拓展消息命令(PUB_EXT)帶上壓測標記{"zan_test": true}

異步調用標識透傳問題，可以自行定制 Runnable 或者定制線程池再或者業務方自行定制實現。

通過流量識別的改造，各個服務都已經能夠識別出壓測的請求流量了，那么如何做到壓測數據不污染線上數據，對于不同的存儲做到壓測數據和真實的隔離呢，有贊主要有客戶端 Client 和 Proxy 訪問代理的方式實現，下面就看一下有贊的數據隔離方案：

針對業務方和數據存儲服務間已有Proxy代理的情況，可以直接升級 Proxy 層，存儲使用方完全無感知，無侵入，下面以 MySQL 為例，說明 Proxy 訪問代理對于壓測數據隔離的方案；

業務方應用讀寫DB時，統一與 RDS-Proxy (介于 MySQL 服務器與 MySQLClient 之間的中間件)交互，調用 RDS-Proxy 時會透傳壓測的標記，RDS 識別出壓測請求后，讀寫 DB 表時，自動替換成對應的影子表，達到壓測數據和真實的生產數據隔離的目的

ElasticSearch、KV 對于壓測的支持也是通過 Proxy 訪問代理的方式實現的

業務應用通過Client調用存儲服務時，Client 會識別出壓測的流量，將需要讀寫的 Table 自動替換為影子表，這樣就可以達到影子流量，讀寫到影子存儲的目的；

Hbase、Redis 等采用此方案實現

推動框架、中間件升級、業務方改造，難免會有遺漏之處，所以有贊對于壓測的數據統一做了偏移，確保買賣家 ID 與線上已有數據隔離開，這樣即使壓測數據由于某種原因寫入了真實的生產庫，也不會影響到線上買賣家相關的數據，讓用戶無感知；

這里要說一下特殊的周期掃表應用的改造，周期性掃表應用由于沒有外部觸發，所有無法掃描影子表的數據，如何讓這樣的 job 集群整體來看既掃描生產庫，也掃描影子庫呢？
有贊的解決思路是，部署一些新的 job 實例，它們只掃描影子庫，消息處理邏輯不變；老的 job 實例保持不變（只掃生產庫）

有贊的全鏈路壓測平臺目前主要負責壓測腳本管理、壓測數據集管理、壓測 job 管理和調度等，后續會有重點介紹，這里不做深入

壓測的“硬件”設施基本已經齊全，下面介紹一下有贊全鏈路壓測的具體實施流程吧

廢話不多說，直接上圖：

有贊全鏈路壓測的執行流程如上圖所示，下面具體看一下幾個核心步驟在有贊是怎么做的。

要想模擬大促時線上真實的流量情況，首先需要確認的就是壓測場景、鏈路，壓測的目錄，以及壓測的流量漏斗模型：

壓測的鏈路：根據公司具體業務具體分析，有贊屬于電商類型公司，大促時候的峰值流量基本都是由于買家的購買行為導致的，從宏觀上看，這樣的購買行為主要是店鋪首頁-商品詳情頁-下單-支付-支付成功，我們把這一條骨干的鏈路稱為核心鏈路，其實大促時主要就是保證核心鏈路的穩定性

壓測鏈路的漏斗模型：線上真實的場景案例是，100個人進入了商家的店鋪首頁，可能有50個人直接退出了，有50個人最終點擊進入了商品詳情頁面，最終只有10個人下了單，5個人真正付款了，這就是壓測鏈路的漏斗模型，也就是不同的接口的真實調用比例；實際的模型制定會根據近7天線上真實用戶的行為數據分型分析建模，以及往期同類型活動線上的流量分布情況，構建壓測鏈路的漏斗模型

壓測的場景：根據運營報備的商家大促活動的計劃，制定大促的壓測場景（比如秒殺、抽獎等），再結合近七天線上流量的場景情況，綜合確定壓測的場景；

壓測目標：根據運營報備的商家大促預估的PV和轉換率情況，結合去年同期線上流量情況和公司業務的增長速率，取大值作為壓測的目標

前面我們已經介紹了如何確定壓測的目標、場景、鏈路，那么壓測的數據怎么來尼，這就是數據工廠登場的時候了，下面就介紹一下有贊壓測的數據工廠

有贊的壓測數據工廠主要負責，壓測鋪底數據的準備、壓測請求數據塊的生成；

壓測準備鋪底的數據，這個眾所周知的，但是由于有贊壓測的方案采用的是影子庫的設計，所以對于鋪底數據準備不得不去處理影子庫的數據。直接看下鋪底數據準備的流程圖：

數據導入

從生產數據庫按需過濾，導入壓測鋪底需要的數據到大數據集群的hive表中。

數據處理

在 hive 表中，對導入的數據進行脫敏和清洗，清洗的目的是保證壓測的數據可用性，比如保證鋪底商品庫存最大、營銷活動時間無限、店鋪正常營業等。

數據導出

對 hive 標中已經處理完成的數據，導出到已經創建好的影子庫中，需要注意的是同一實例寫入數據的控制（因為影子庫和生產庫同實例），寫入數據的 binlog 過濾。

有贊的壓測數據準備目前全部在 DP 大數據平臺上操作，基本完成了數據準備操作的自動化，維護了近千的數據準備 job

壓測請求數據數據集

gatling 原生支持 json、csv、DB 等方式的數據源載入，我們采用的壓測數據源是 json 格式的，那么如此海量的壓測源數據，是通過什么方式生成和存儲的尼，我們的實現還是依托于 DP 大數據平臺，通過 MapReduce 任務的方式，按需生成我們壓測請求需要的數據集：

從各個業務線的表中獲取壓測場景整個鏈路所以接口請求需要的參數字段，存到一張創建好的壓測數據源寬表中

編寫 MapReduce 任務代碼，讀取壓測數據源寬表數據，按壓測的接口請求參數情況，生成目標 json 格式的壓測請求數據塊文件到 HDFS

壓測時，壓測引擎自動從 HDFS 上拉取壓測的請求數據塊

MapReduce 生成的數據集 json 示例：

壓測就要知道壓測的具體接口和接口參數，所以我們采用統一的 RESTful 風格規范，讓各個業務方的人員提交壓測接口的 API 文檔，這樣壓測腳本編寫人員就能根據這份 API 快速寫出壓測的腳本，以及接口的預期結果等

有贊的壓測引擎用的是公司二次封裝的 gatling，原生就支持漏斗比例的控制，直接看例子

setUp(
    scn0.inject(constantUsersPerSec(10) during (1 minute)).throttle(
      reachRps(300) in (30 seconds),
      holdFor(2 minute)).protocols(CustomHttpProtocol.httpProtocol),
    scn1.inject(constantUsersPerSec(10) during (1 minute)).throttle(
      reachRps(500) in (10 seconds),
      holdFor(3 minute)).protocols(CustomHttpProtocol.httpProtocol),
    scn2.inject(constantUsersPerSec(10) during (1 minute)).throttle(
      reachRps(200) in (20 seconds),
      holdFor(1 minute)).protocols(CustomHttpProtocol.httpProtocol)
  )

對不同的壓測場景鏈路按模塊編寫壓測腳本，這樣的好處就是需要不同場景混合壓測時，只需要在 setUp 時，按需把不同的場景組合到一起即可；需要多帶帶壓測某一個場景時，setUp 中只留一個場景就好，做到一次編寫，處處可壓。

壓測的鋪底數據、壓測腳本、壓測請求的數據集都已經介紹完了，可謂是萬事俱備只欠東風，那這個東風就是我們自建的壓測平臺 maxim，這里不對壓測平臺的設計展開介紹，展示一下 maxim 在壓測執行過程中所承擔的工作。

maxim平臺主要的功能模塊有：

測試腳本：負責測試腳本的管理

數據集：負責壓測請求數據集的管理，目前主要有兩種數據集上傳模式：直接上傳數據包和 hadoop 集群數據源路徑上傳。第二種上傳模式，只需要填寫數據源所在的 hadoop 集群的路徑，maxim 平臺會自動去所在路徑獲取壓測數據集文件

測試 job：負責測試任務的管理，指定壓測 job 的腳本和腳本入口，以及壓測數據集等

壓測注入器：負責展示壓測注入機器的相關信息

壓測報告生成：壓測報告的生成，直接用的 gatling 原生的報告生成功能

maxim 平臺壓測結果報告

下面看一下壓測執行的頁面功能：

壓力注入器數量：指定本次壓測執行，需要多少臺壓測機去執行

重復場景測試：一個虛擬用戶重復幾次壓測場景

并發用戶數：可執行壓測時，按需填寫需要的每秒加載的并發用戶數和持續時間，無需每次變更壓測腳本

目標 RPS：可執行壓測時，按需填寫壓測的目標 RPS，爬坡時間，目標持續時間，達到限流的作用，可同時指定多個目標 RPS，達到分梯度壓測的目的；

到這里有贊全鏈路壓測方案已經介紹完了，因為篇幅的原因還有很多實施細節部分并沒有完整表述，同時有贊的全鏈路壓測也才初具雛形，歡迎有興趣的同學聯系我們一起探討，有表述錯誤的地方也歡迎大家聯系我們糾正。