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

有贊致力于成為商家服務(wù)領(lǐng)域里最被信任的引領(lǐng)者，因?yàn)楸恍湃危形覀兏枰獮樯碳冶ｑ{護(hù)航，保障系統(tǒng)的穩(wěn)定性。有贊從去年開始通過全鏈路壓測，模擬大促真實(shí)流量，串聯(lián)線上全部系統(tǒng)，讓核心系統(tǒng)同時(shí)達(dá)到流量峰值：

驗(yàn)證大促峰值流量下系統(tǒng)穩(wěn)定性

容量規(guī)劃

進(jìn)行強(qiáng)弱依賴的劃分

降級(jí)、報(bào)警、容災(zāi)、限流等演練

...

通過全鏈路壓測這一手段，對線上系統(tǒng)進(jìn)行最真實(shí)的大促演練，獲取系統(tǒng)在大壓力時(shí)的表現(xiàn)情況，進(jìn)而準(zhǔn)確評(píng)估線上整個(gè)系統(tǒng)集群的性能和容量水平，不辜負(fù)百萬商家的信任。

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

說到全鏈路壓測，業(yè)內(nèi)的淘寶、京東都都已有很成熟的技術(shù)，主要就是壓測流量的制造、壓測數(shù)據(jù)的構(gòu)造、壓測流量的識(shí)別以及壓測數(shù)據(jù)流向的處理；直接看下有贊壓測的整體設(shè)計(jì)：

大流量下發(fā)器：其實(shí)就是模擬海量的用戶去使用我們的系統(tǒng)，提供壓測的流量，產(chǎn)生大促時(shí)的場景和流量；

數(shù)據(jù)工廠：構(gòu)造壓測鏈路中用戶請求的數(shù)據(jù)，以及壓測鋪底的數(shù)據(jù)、數(shù)據(jù)清洗、脫敏等工作；

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

要想壓測的流量和數(shù)據(jù)不影響線上真實(shí)的生產(chǎn)數(shù)據(jù)，就需要線上的集群能識(shí)別出壓測的流量，只要能識(shí)別出壓測請求的流量，那么流量觸發(fā)的讀寫操作就很好統(tǒng)一去做隔離了，先看一下有贊壓測流量的識(shí)別：

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

Dubbo協(xié)議的服務(wù)調(diào)用，通過隱式參數(shù)在服務(wù)消費(fèi)方和提供方進(jìn)行參數(shù)的隱式傳遞，表現(xiàn)形式為：
Attachments:X-Service-Chain;
Attachments Value:{"zan_test": true}

通過在請求協(xié)議中添加壓測請求的標(biāo)識(shí)，在不同服務(wù)的相互調(diào)用時(shí)，一路透傳下去，這樣每一個(gè)服務(wù)都能識(shí)別出壓測的請求流量，這樣做的好處是與業(yè)務(wù)完全的解耦，只需要應(yīng)用框架進(jìn)行感知，對業(yè)務(wù)方代碼無侵入

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

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

異步調(diào)用標(biāo)識(shí)透傳問題，可以自行定制 Runnable 或者定制線程池再或者業(yè)務(wù)方自行定制實(shí)現(xiàn)。

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

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

業(yè)務(wù)方應(yīng)用讀寫DB時(shí)，統(tǒng)一與 RDS-Proxy (介于 MySQL 服務(wù)器與 MySQLClient 之間的中間件)交互，調(diào)用 RDS-Proxy 時(shí)會(huì)透傳壓測的標(biāo)記，RDS 識(shí)別出壓測請求后，讀寫 DB 表時(shí)，自動(dòng)替換成對應(yīng)的影子表，達(dá)到壓測數(shù)據(jù)和真實(shí)的生產(chǎn)數(shù)據(jù)隔離的目的

ElasticSearch、KV 對于壓測的支持也是通過 Proxy 訪問代理的方式實(shí)現(xiàn)的

業(yè)務(wù)應(yīng)用通過Client調(diào)用存儲(chǔ)服務(wù)時(shí)，Client 會(huì)識(shí)別出壓測的流量，將需要讀寫的 Table 自動(dòng)替換為影子表，這樣就可以達(dá)到影子流量，讀寫到影子存儲(chǔ)的目的；

Hbase、Redis 等采用此方案實(shí)現(xiàn)

推動(dòng)框架、中間件升級(jí)、業(yè)務(wù)方改造，難免會(huì)有遺漏之處，所以有贊對于壓測的數(shù)據(jù)統(tǒng)一做了偏移，確保買賣家 ID 與線上已有數(shù)據(jù)隔離開，這樣即使壓測數(shù)據(jù)由于某種原因?qū)懭肓苏鎸?shí)的生產(chǎn)庫，也不會(huì)影響到線上買賣家相關(guān)的數(shù)據(jù)，讓用戶無感知；

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

有贊的全鏈路壓測平臺(tái)目前主要負(fù)責(zé)壓測腳本管理、壓測數(shù)據(jù)集管理、壓測 job 管理和調(diào)度等，后續(xù)會(huì)有重點(diǎn)介紹，這里不做深入

壓測的“硬件”設(shè)施基本已經(jīng)齊全，下面介紹一下有贊全鏈路壓測的具體實(shí)施流程吧

廢話不多說，直接上圖：

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

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

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

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

壓測的場景：根據(jù)運(yùn)營報(bào)備的商家大促活動(dòng)的計(jì)劃，制定大促的壓測場景（比如秒殺、抽獎(jiǎng)等），再結(jié)合近七天線上流量的場景情況，綜合確定壓測的場景；

壓測目標(biāo)：根據(jù)運(yùn)營報(bào)備的商家大促預(yù)估的PV和轉(zhuǎn)換率情況，結(jié)合去年同期線上流量情況和公司業(yè)務(wù)的增長速率，取大值作為壓測的目標(biāo)

前面我們已經(jīng)介紹了如何確定壓測的目標(biāo)、場景、鏈路，那么壓測的數(shù)據(jù)怎么來尼，這就是數(shù)據(jù)工廠登場的時(shí)候了，下面就介紹一下有贊壓測的數(shù)據(jù)工廠

有贊的壓測數(shù)據(jù)工廠主要負(fù)責(zé)，壓測鋪底數(shù)據(jù)的準(zhǔn)備、壓測請求數(shù)據(jù)塊的生成；

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

數(shù)據(jù)導(dǎo)入

從生產(chǎn)數(shù)據(jù)庫按需過濾，導(dǎo)入壓測鋪底需要的數(shù)據(jù)到大數(shù)據(jù)集群的hive表中。

數(shù)據(jù)處理

在 hive 表中，對導(dǎo)入的數(shù)據(jù)進(jìn)行脫敏和清洗，清洗的目的是保證壓測的數(shù)據(jù)可用性，比如保證鋪底商品庫存最大、營銷活動(dòng)時(shí)間無限、店鋪正常營業(yè)等。

數(shù)據(jù)導(dǎo)出

對 hive 標(biāo)中已經(jīng)處理完成的數(shù)據(jù)，導(dǎo)出到已經(jīng)創(chuàng)建好的影子庫中，需要注意的是同一實(shí)例寫入數(shù)據(jù)的控制（因?yàn)橛白訋旌蜕a(chǎn)庫同實(shí)例），寫入數(shù)據(jù)的 binlog 過濾。

有贊的壓測數(shù)據(jù)準(zhǔn)備目前全部在 DP 大數(shù)據(jù)平臺(tái)上操作，基本完成了數(shù)據(jù)準(zhǔn)備操作的自動(dòng)化，維護(hù)了近千的數(shù)據(jù)準(zhǔn)備 job

壓測請求數(shù)據(jù)數(shù)據(jù)集

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

從各個(gè)業(yè)務(wù)線的表中獲取壓測場景整個(gè)鏈路所以接口請求需要的參數(shù)字段，存到一張創(chuàng)建好的壓測數(shù)據(jù)源寬表中

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

壓測時(shí)，壓測引擎自動(dòng)從 HDFS 上拉取壓測的請求數(shù)據(jù)塊

MapReduce 生成的數(shù)據(jù)集 json 示例：

壓測就要知道壓測的具體接口和接口參數(shù)，所以我們采用統(tǒng)一的 RESTful 風(fēng)格規(guī)范，讓各個(gè)業(yè)務(wù)方的人員提交壓測接口的 API 文檔，這樣壓測腳本編寫人員就能根據(jù)這份 API 快速寫出壓測的腳本，以及接口的預(yù)期結(jié)果等

有贊的壓測引擎用的是公司二次封裝的 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)
  )

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

壓測的鋪底數(shù)據(jù)、壓測腳本、壓測請求的數(shù)據(jù)集都已經(jīng)介紹完了，可謂是萬事俱備只欠東風(fēng)，那這個(gè)東風(fēng)就是我們自建的壓測平臺(tái) maxim，這里不對壓測平臺(tái)的設(shè)計(jì)展開介紹，展示一下 maxim 在壓測執(zhí)行過程中所承擔(dān)的工作。

maxim平臺(tái)主要的功能模塊有：

測試腳本：負(fù)責(zé)測試腳本的管理

數(shù)據(jù)集：負(fù)責(zé)壓測請求數(shù)據(jù)集的管理，目前主要有兩種數(shù)據(jù)集上傳模式：直接上傳數(shù)據(jù)包和 hadoop 集群數(shù)據(jù)源路徑上傳。第二種上傳模式，只需要填寫數(shù)據(jù)源所在的 hadoop 集群的路徑，maxim 平臺(tái)會(huì)自動(dòng)去所在路徑獲取壓測數(shù)據(jù)集文件

測試 job：負(fù)責(zé)測試任務(wù)的管理，指定壓測 job 的腳本和腳本入口，以及壓測數(shù)據(jù)集等

壓測注入器：負(fù)責(zé)展示壓測注入機(jī)器的相關(guān)信息

壓測報(bào)告生成：壓測報(bào)告的生成，直接用的 gatling 原生的報(bào)告生成功能

maxim 平臺(tái)壓測結(jié)果報(bào)告

下面看一下壓測執(zhí)行的頁面功能：

壓力注入器數(shù)量：指定本次壓測執(zhí)行，需要多少臺(tái)壓測機(jī)去執(zhí)行

重復(fù)場景測試：一個(gè)虛擬用戶重復(fù)幾次壓測場景

并發(fā)用戶數(shù)：可執(zhí)行壓測時(shí)，按需填寫需要的每秒加載的并發(fā)用戶數(shù)和持續(xù)時(shí)間，無需每次變更壓測腳本

目標(biāo) RPS：可執(zhí)行壓測時(shí)，按需填寫壓測的目標(biāo) RPS，爬坡時(shí)間，目標(biāo)持續(xù)時(shí)間，達(dá)到限流的作用，可同時(shí)指定多個(gè)目標(biāo) RPS，達(dá)到分梯度壓測的目的；

到這里有贊全鏈路壓測方案已經(jīng)介紹完了，因?yàn)槠脑蜻€有很多實(shí)施細(xì)節(jié)部分并沒有完整表述，同時(shí)有贊的全鏈路壓測也才初具雛形，歡迎有興趣的同學(xué)聯(lián)系我們一起探討，有表述錯(cuò)誤的地方也歡迎大家聯(lián)系我們糾正。