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

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

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

容量規(guī)劃

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

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

...

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

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

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

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

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

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

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

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

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

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

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

Wagon:對(duì)來(lái)自影子庫(kù)的 binlog 通過(guò)拓展消息命令(PUB_EXT)帶上壓測(cè)標(biāo)記{"zan_test": true}

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

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

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

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

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

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

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

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

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

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

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

廢話不多說(shuō)，直接上圖：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

壓測(cè)請(qǐng)求數(shù)據(jù)數(shù)據(jù)集

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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