?一、背景

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

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

老板或者運營同學說，我們馬上要做活動，線上能支撐得住吧？

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

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

二、解決方案

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

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

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

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

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

2、現(xiàn)在方案

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

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

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

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

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

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

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

4）支持多種壓測類型

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

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

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

三、系統(tǒng)架構設計

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

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

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

• Havok-mock【mock服務】：提供mock服務功能。

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

四、主要模塊功能介紹

1、調度中心核心功能

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

1）為什么采取回放方式

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

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

場景設置外，還有其他諸如：

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

這么多場景構造，很麻煩...

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

2）如何做到高仿真

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

3）增益能力

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

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

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

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

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

2、壓測引擎核心功能

壓測引擎主要功能有：

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

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

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

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

• goroutine的切換沒有內核開銷；
• 內存占用小，線程?？臻g通常是2M，goroutine?？臻g通常是2K；
• G-M-P調度模型。

3）接口請求和響應字段的過濾調整

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

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

統(tǒng)計接口錯誤率、吞吐量、P95等指標并上報給調度中心。

5）響應調度中心事件下發(fā)處理

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

3、數(shù)據(jù)構造

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

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

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

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

4、Mock第三方服務接口

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

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

5、壓測監(jiān)控

線上壓測肯定會線上服務產生一定影響，所以我們需要做到對相關鏈路秒級的監(jiān)控，以及針對異?？焖僮龀鋈蹟嗟确磻?架構如下：

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

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

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

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

6、壓測隔離

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

1）壓測標識透傳

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

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

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

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

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

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

8、熔斷保護機制

1）施壓端熔斷

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

2）服務端熔斷

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

五、壓測實施

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

六、總結與展望

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

1、易用性提高

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

2、壓測與SLA建設

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