?一、背景

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

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

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

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

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

二、解決方案

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

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

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

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

• 費(fèi)時(shí)費(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。作為公司層級(jí)的全鏈路壓測平臺(tái)，主要設(shè)計(jì)目標(biāo)就是為公司業(yè)務(wù)提供真實(shí)、安全的仿真流量輸出，同時(shí)給業(yè)務(wù)團(tuán)隊(duì)提供準(zhǔn)確的容量評(píng)估數(shù)據(jù)，所以我們主要提供如下能力：

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

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

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

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

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

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

4）支持多種壓測類型

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

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

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

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

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

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

• Havok-replayer【壓測引擎】：負(fù)責(zé)根據(jù)既定規(guī)則回放dispatcher訂閱的壓測請(qǐng)求、支持回放請(qǐng)求的增益調(diào)整、支持壓測數(shù)據(jù)的規(guī)則調(diào)整等功能。
• Havok-monitor【監(jiān)控平臺(tái)】：收集并展示壓測引擎的數(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í)時(shí)增量清洗。

四、主要模塊功能介紹

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

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

1）為什么采取回放方式

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

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

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

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

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

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

2）如何做到高仿真

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

3）增益能力

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

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

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

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

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

2、壓測引擎核心功能

壓測引擎主要功能有：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5、壓測監(jiān)控

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

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

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

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

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

6、壓測隔離

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

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

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

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

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

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

我們針對(duì)不同存儲(chǔ)，采取不同策略：

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

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

1）施壓端熔斷

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

2）服務(wù)端熔斷

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

五、壓測實(shí)施

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

六、總結(jié)與展望

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

1、易用性提高

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

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

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