?一、背景

隨著公司交易體量的不斷增長，以及圍繞“服務(wù)千萬商家，全能生意幫手”的理念不斷拼裝的業(yè)務(wù)版圖，曾經(jīng)在某一段時間內(nèi)發(fā)生了一些故障，給用戶和商戶帶來非常不好的體驗(yàn)，也給公司帶來較大損失。

線下我們明明做了各種驗(yàn)證測試，功能、性能等，怎么一上線還是各種問題？

老板或者運(yùn)營同學(xué)說，我們馬上要做活動，線上能支撐得住吧？

IT環(huán)境成本又增長了，但是業(yè)務(wù)又沒有多大增長，能降低線上IT成本嗎？

上面類似的問題，相信很多同學(xué)都碰到過，解決辦法業(yè)界也有比較成熟的方案，就是全鏈路壓測。

二、解決方案

1、傳統(tǒng)線上壓測

在全鏈路壓測之前，我們線上環(huán)境壓測，往往采用如下方式進(jìn)行：

• 線上環(huán)境預(yù)先準(zhǔn)備好測試數(shù)據(jù)，模擬請求針對單個服務(wù)或者集群壓測；
• nginx鏡像一份流量來壓測。

上述的壓測方式有以下問題：?

• 費(fèi)時費(fèi)力，前期需要構(gòu)建大量測試數(shù)據(jù)；
• 產(chǎn)生臟數(shù)據(jù)，污染線上數(shù)據(jù)庫等；
• 壓測模型需人為構(gòu)建，導(dǎo)致壓測結(jié)果不精準(zhǔn)；
• 僅覆蓋關(guān)鍵核心服務(wù)，壓測覆蓋面窄；
• 難以覆蓋鏈路上的基礎(chǔ)設(shè)施，比如slb、nginx、網(wǎng)絡(luò)、數(shù)據(jù)庫等。

2、現(xiàn)在方案

基于上述問題以及收錢吧具體業(yè)務(wù)需求，我們設(shè)計(jì)開發(fā)了全鏈路壓測系統(tǒng)Havok。作為公司層級的全鏈路壓測平臺，主要設(shè)計(jì)目標(biāo)就是為公司業(yè)務(wù)提供真實(shí)、安全的仿真流量輸出，同時給業(yè)務(wù)團(tuán)隊(duì)提供準(zhǔn)確的容量評估數(shù)據(jù)，所以我們主要提供如下能力：

1）真實(shí)重現(xiàn)用戶行為，持續(xù)輸出真實(shí)壓測流量

真實(shí)復(fù)現(xiàn)線上用戶行為，按時間輪回放真實(shí)流量，同時不污染線上數(shù)據(jù)，用戶無感。

2）提供按速率和倍數(shù)來放大流量

在上一步的基礎(chǔ)能力上，可以按照預(yù)設(shè)的速率或者倍數(shù)來放大流量，進(jìn)而探測線上容量。

3）具備“開箱及測”的能力

不需要前期花費(fèi)過多精力構(gòu)造測試數(shù)據(jù)等準(zhǔn)備工作，做到想什么時候壓測就什么時候開始；同時不污染生產(chǎn)數(shù)據(jù)。

4）支持多種壓測類型

支持普遍的http接口壓測，支持收錢吧內(nèi)部的rpc請求壓測以及移動設(shè)備的特殊協(xié)議壓測

5）提供壓測過程中實(shí)時的監(jiān)控和過載保護(hù)能力

提供實(shí)時監(jiān)控?cái)?shù)據(jù)收集查看的能力，同時根據(jù)預(yù)定規(guī)則提供自動停止壓測來保護(hù)線上環(huán)境的能力。

三、系統(tǒng)架構(gòu)設(shè)計(jì)

我們采取的方式是回放生產(chǎn)服務(wù)日志來實(shí)現(xiàn)壓測，包括讀和寫操作，同時根據(jù)日志的時間戳來控制阻塞/放行請求，來達(dá)到高仿真壓測的目的，整體架構(gòu)如下：

• Havok-dispatcher【調(diào)度中心】：負(fù)責(zé)線上服務(wù)日志數(shù)據(jù)的下載、排序（有規(guī)則約束）、時間控制、請求分發(fā)、壓測引擎監(jiān)控?cái)?shù)據(jù)的收集和上送等功能。

• Havok-replayer【壓測引擎】：負(fù)責(zé)根據(jù)既定規(guī)則回放dispatcher訂閱的壓測請求、支持回放請求的增益調(diào)整、支持壓測數(shù)據(jù)的規(guī)則調(diào)整等功能。
• Havok-monitor【監(jiān)控平臺】：收集并展示壓測引擎的數(shù)據(jù)、線上服務(wù)的監(jiān)控?cái)?shù)據(jù)、中間件等數(shù)據(jù)。

• Havok-mock【mock服務(wù)】：提供mock服務(wù)功能。

• Havok-canal【數(shù)據(jù)構(gòu)造】：提供影子數(shù)據(jù)的實(shí)時增量清洗。

四、主要模塊功能介紹

1、調(diào)度中心核心功能

調(diào)度中心核心功能是日志抽取以及請求下發(fā)，支持多個數(shù)據(jù)源、支持維度篩選、保序日志分發(fā)、增益能力、監(jiān)控?cái)?shù)據(jù)查看上送、壓測引擎的管理調(diào)度。整體設(shè)計(jì)如下圖：

1）為什么采取回放方式

假設(shè)有這么一個外賣下單接口: POST /api/order，需要傳入商戶ID、菜品ID等參數(shù)，如果計(jì)劃用100并發(fā)線程去壓這個接口，你肯定會考慮以下幾個問題：

• 是使用同一商戶、同一菜品去壓測？
• 是使用同一商戶、不同菜品去壓測？
• 是使用100個商戶、不同菜品去壓測？
• 是使用20個商戶、每個商戶相同菜品去壓測？

場景設(shè)置外，還有其他諸如：

• 緩存如何控制？是否需要避免命中緩存？是否考慮命中緩存概率?
• 查詢請求，是否要考慮存量數(shù)據(jù)的查詢效率影響？是否考慮數(shù)據(jù)庫分庫分表？
• .....

這么多場景構(gòu)造，很麻煩...

日志回放方式就相對較好的解決上面的困擾，因?yàn)閴簻y請求場景的構(gòu)造，日志里已經(jīng)告訴我了，要做的就是塞到壓測請求里回放就行了，我不需要考慮如何設(shè)計(jì)。同時利用好現(xiàn)有的數(shù)據(jù)庫表、緩存等設(shè)施，我也就不需要考慮數(shù)據(jù)多樣性等問題。

2）如何做到高仿真

除了如實(shí)的回放請求內(nèi)容外，我們還得控制好回放的節(jié)奏，就像一首歌，同樣的磁帶，播放的速度不一樣那出來的節(jié)奏肯定不一樣。所以我們還嚴(yán)格按照日志的時間戳來控制好回放的節(jié)奏，做到回放出的不僅歌詞一樣，同時節(jié)奏也一樣。timewheel模塊就承擔(dān)了這樣的職責(zé)，支持快放、慢放。

3）增益能力

為了滿足業(yè)務(wù)容量探測設(shè)計(jì)，提供了請求的增益（倍率）能力，能將一個請求復(fù)制出多份，從而實(shí)現(xiàn)對業(yè)務(wù)增長的模擬。另外，即便一比一等量回放，我們依然要面對回放型壓測中不得不解決的一個問題：冪等性。

f(x) = f(f(x))

舉個例子：我們的創(chuàng)建商戶接口 POST: /api/createMch，要求傳入的商戶名稱是唯一的（業(yè)務(wù)要求），這個時候日志里包含了一個創(chuàng)建商戶的動作，創(chuàng)建了一家小吃店：XX小吃。如果你從日志中提取后，重放這個請求，必然創(chuàng)建失?。簲?shù)據(jù)庫中已經(jīng)存在該商戶。

因此不但需要實(shí)現(xiàn)請求增益能力還需要解決接口冪等性的問題。目前我們兩個思路：

• Havok 接口層面支持自定義關(guān)鍵字偏移修改，避免沖突。
• 被壓服務(wù)層面做好冪等處理。

2、壓測引擎核心功能

壓測引擎主要功能有：

1）支持分布式容器化部署

容器化部署，可以快速擴(kuò)展壓測引擎能力。

2）異步發(fā)送/接收消息

采用異步請求方式處理請求和響應(yīng)，提高并發(fā)能力，Havok基于goroutine來實(shí)現(xiàn),如下好處：

• goroutine的切換沒有內(nèi)核開銷；
• 內(nèi)存占用小，線程棧空間通常是2M，goroutine棧空間通常是2K；
• G-M-P調(diào)度模型。

3）接口請求和響應(yīng)字段的過濾調(diào)整

針對敏感數(shù)據(jù)統(tǒng)一處理；根據(jù)預(yù)定規(guī)則偏移數(shù)據(jù)以方便壓測；針對響應(yīng)進(jìn)行定制化assert。

4）接口層級各個維度的統(tǒng)計(jì)

統(tǒng)計(jì)接口錯誤率、吞吐量、P95等指標(biāo)并上報(bào)給調(diào)度中心。

5）響應(yīng)調(diào)度中心事件下發(fā)處理

處理調(diào)度中心下發(fā)的開始壓測、停止壓測、熔斷等指令。

3、數(shù)據(jù)構(gòu)造

傳統(tǒng)的壓測很大一部分工作就是前期的數(shù)據(jù)構(gòu)造，面臨如下等問題：

• 數(shù)據(jù)樣本類別分布不均衡，多樣性不足；
• 數(shù)據(jù)量偏少；
• 構(gòu)建數(shù)據(jù)耗時過長。

所以我們基于阿里的canal[1]增量同步服務(wù)定制開發(fā)了符合我們壓測要求的功能，比如偏移數(shù)據(jù)等功能。達(dá)到想什么時候壓測就什么開始，相比以往大大提高了執(zhí)行周期效率。

• 敏感數(shù)據(jù)，諸如電話號碼、身份證號等統(tǒng)一脫敏偏移處理。
• 商戶號、門店號、終端號等信息按既定規(guī)則偏移處理，不影響實(shí)際線上商戶使用。

4、Mock第三方服務(wù)接口

針對第三方服務(wù)，我們采取的是mock處理，mock支持延時抖動等特性，同時通過事后的正態(tài)分布分析調(diào)整mock相關(guān)配置，盡量匹配生產(chǎn)相關(guān)處理的生命周期模擬；

• 自研通用mock服務(wù)DeepMock[2]：壓測前，需要注入mock規(guī)則以及響應(yīng)規(guī)則

5、壓測監(jiān)控

線上壓測肯定會線上服務(wù)產(chǎn)生一定影響，所以我們需要做到對相關(guān)鏈路秒級的監(jiān)控，以及針對異常快速做出熔斷等反應(yīng),架構(gòu)如下：

1）施壓端監(jiān)控

壓測引擎會每秒?yún)R總好接口層級的監(jiān)控?cái)?shù)據(jù)上送給調(diào)度中心再處理，指標(biāo)包括接口錯誤率、吞吐量、top90、top95、avg響應(yīng)時間等。

2）服務(wù)端監(jiān)控

由于公司服務(wù)設(shè)施基本部署在云上，所以服務(wù)端監(jiān)控基本依賴現(xiàn)有云端監(jiān)控設(shè)施，包括中間件監(jiān)控。

6、壓測隔離

線上壓測要保證壓測行為真實(shí)、安全且可控，不會影響正常用戶的使用，并且不會對線上環(huán)境造成任何數(shù)據(jù)的污染。要做到這一點(diǎn)，首先需要解決的是壓測流量的識別與透傳問題。有了壓測標(biāo)識后，各服務(wù)與中間件就可以依據(jù)標(biāo)識來進(jìn)行壓測服務(wù)是否隔離、流量是否透傳以及影子表等方案的實(shí)施。

1）壓測標(biāo)識透傳

壓測標(biāo)識，目前我們采取的key:value方式染色壓測流量，同時我們相關(guān)鏈路的服務(wù)以及基礎(chǔ)RPC框架等中間件都已配合改造以識別。

改造原理是將壓測標(biāo)識的 kv 值存入 Context 中，然后發(fā)往下游的請求中都帶上該 Context，下游服務(wù)可以根據(jù) Context 中的壓測標(biāo)識完成對壓測流量的識別和處理。在實(shí)際業(yè)務(wù)中，代碼改造也非常簡單，只需要透傳 Context 即可。

7、數(shù)據(jù)隔離

線上壓測相對比較復(fù)雜的就是如何確保壓測產(chǎn)生的寫數(shù)據(jù)不污染線上數(shù)據(jù)，業(yè)界常見做法比如影子表、影子庫，以及數(shù)據(jù)偏移等。

我們針對不同存儲，采取不同策略：

• MySQL、MongoDB：采用影子表方式，應(yīng)用層面根據(jù)壓測標(biāo)識來區(qū)分壓測流量讀影子表、寫影子表；影子表數(shù)據(jù)的偏移規(guī)則支持[stress_tag]前綴、隨機(jī)字符串、uuid、字符反轉(zhuǎn)等等替換方式。
• Redis：key偏移后使用，壓測完失效或者刪除即可。
• Kafka或者M(jìn)Q：兩種策略，一種業(yè)務(wù)層面直接丟棄不下發(fā)，然后后續(xù)單獨(dú)壓測；或者透傳壓測標(biāo)識，consumer根據(jù)自身業(yè)務(wù)情況改造處理。
• 其他存儲：比如ES，單獨(dú)壓測集群，壓測時啟用。

8、熔斷保護(hù)機(jī)制

1）施壓端熔斷

Havok會實(shí)時分析監(jiān)控指標(biāo)數(shù)據(jù)，根據(jù)業(yè)務(wù)配置閾值，實(shí)時給壓測引擎下發(fā)降低QPS或者停止壓測事件，防止壓垮線上系統(tǒng)。

2）服務(wù)端熔斷

線上業(yè)務(wù)自身具備熔斷能力，基于相應(yīng)中間件實(shí)現(xiàn)，根據(jù)閾值，比如錯誤率自動熔斷。

五、壓測實(shí)施

目前公司部分核心業(yè)務(wù)已經(jīng)接入，包括門店碼支付、被掃支付、小程序支付等等，后續(xù)業(yè)務(wù)也在陸續(xù)推進(jìn)接入中，隨著業(yè)務(wù)線壓測的推進(jìn)，我們從中也學(xué)到了大量的業(yè)務(wù)知識，架構(gòu)知識，接收到不少反饋，持續(xù)推動我們不斷演進(jìn)和優(yōu)化Havok。目前已經(jīng)開源Havok[3]，歡迎志同道合者提出寶貴意見或者PR。

六、總結(jié)與展望

從項(xiàng)目立項(xiàng)到成功投產(chǎn)壓測，得到了產(chǎn)研同學(xué)的大力支持和幫助，尤其是各個業(yè)務(wù)線配合改造，真心感謝，正是在大家的配合下，才能夠初具規(guī)模。展望未來我們還有較長路需要走，期望能夠幫助大家提高研發(fā)效率，及時發(fā)現(xiàn)性能問題。

1、易用性提高

由于多種因素影響，目前我們在用戶易用性上還有待提高，期望后續(xù)在可視化操作上投入更多精力，盡量降低研發(fā)同學(xué)使用難度，傻瓜式操作。

2、壓測與SLA建設(shè)

如何精準(zhǔn)評估業(yè)務(wù)線的容量規(guī)劃？按照目前的壓測數(shù)據(jù)，動態(tài)評估還能支撐多久的業(yè)務(wù)規(guī)模增長？線上機(jī)器資源是否可以優(yōu)化，進(jìn)一步降低成本？如何配合公司層級的混沌測試？這些問題都需要我們推進(jìn)和解決中。