自2015年開始，隨著網際網路行業的快速發展，餓了麼公司的業務也進入了快速擴張階段，餓了麼線上外賣平臺使用者量達2.6億，覆蓋全國2000多個城市。

外賣業務本身具備以下特點：

• 時效性: 從使用者下單到商家接單再到物流配送到家，整個流程要控制在一定時間範圍之內，對時效性的要求非常高；

• 高併發: 大量使用者產生的千萬訂單集中分佈在中午和傍晚兩個時間段內，對整個系統的衝擊可想而知；

• 秒殺活動: 為了充分利用閒時的機器資源，會在幾個整點進行秒殺活動，整點活動產生的瞬時流量甚至能超過午高峰的最高值；

• 常規化: 這種大流量的衝擊不是偶發的，而是一個常態化的過程，這對系統的穩定性提出了極高的要求；

基於這些因素，再加上線上不斷有容量引發的問題發生，對整體系統進行全鏈路壓測勢在必行。

辛酸歷程

1. 測試環境硬體資源以及壓測資料與線上差別太大，壓測出來的資料指標參考價值不大；

2. 服務間依賴關係錯綜複雜，測試環境很難模擬且不夠穩定。

整個全鏈路的壓測也不是一蹴而就的，中間主要經歷了三個階段。

1. 縮減伺服器

在低峰時間段，通過一臺臺縮減叢集內伺服器的數量，使得單臺伺服器的請求量不斷加大，從而評估當前叢集容量及預估後續隨著單量的增長所需伺服器的數量。

• 優點

真實流量，評估出的容量最真實;

不用編寫壓測用例和準備壓測資料，節省大量壓測準備的時間;

無髒資料產生;

• 缺點:

風險性比較高，一旦發現達到瓶頸必須立馬恢復;

由於請求量恆定，通過縮減伺服器數量的方式並不能評估出底層基礎元件的容量，如DB,MQ等基礎元件，從而會導致容量評估不準確;

對於訪問流量有一定要求，流量太小的話達不到瓶頸;

2. 單獨業務壓測

針對單個業務在低峰期進行壓測，這就需要壓測人員對業務有一定的敏感度，對業務和系統架構有比較深的瞭解。

來個例項，下面是商戶系統的一個簡單架構圖

商戶讀請求呼叫API, 寫請求呼叫EOSAPI，其中EOSAPI是訂單基礎服務，壓測流量從商戶系統進來繼而評估容量，這樣壓測得到的資料比實際線上真實情況會偏優，因為線上EOSAPI不僅只有商戶系統在呼叫，下單服務也會同時呼叫。

基於以上種種情況，最終我們決定在線上進行全鏈路壓測。

3. 線上全鏈路壓測

模擬外賣平臺下單，開放平臺下單(如手淘)，商戶接單和物流配送，模擬大量的使用者查詢操作，覆蓋所有關鍵路徑的介面，通過不斷從各個入口加壓，既能做到對各個服務的容量做到評估，也能觀測底層服務(包括各個中介軟體)的效能指標，對整個業務系統的容量評估也相對精準。

當然，這樣做也會帶來一些問題，最典型的就是寫請求產生的髒資料怎麼處理。最開始我們想把涉及到寫資料的地方把壓測流量通過識別寫到隔離的位置，但是後來發現要改造的地方(包括各個業務，中介軟體等)太多，而我們又急需解決線上容量問題，最後決定對壓測資料做邏輯隔離，即對壓測資料做特殊的標識與真實資料區分開來，後面做大資料統計分析，清結算等也會通過特殊標記把壓測資料過濾掉。

實施

具體怎麼來做好全鏈路壓測呢？主要包括以下幾個方面。

1. 業務模型的梳理

業務模型梳理需要結合業務本身和業務系統的架構，這一步至關重要，梳理的是否完善直接關係到最終壓測結果是否具有參考價值。

舉個例子：下面是全鏈路壓測中某個業務的系統架構圖。

其中，不僅僅需要關注X Service服務本身提供API的效能情況，還需要關注X Service Cache MQ Consumer的消費能力。業務模型的梳理對壓測人員的業務架構敏感度要求非常高。

具體的架構梳理主要有以下幾個方面：

• 是否關鍵路徑

• 業務的呼叫關係

• 業務的提供的介面列表

• 介面型別(http、thrift、soa等)

• 讀介面還是寫介面？

• 各介面之間的比例關係

2. 資料模型的構建

資料模型的構建總的原則：緊貼業務場景，最大可能地模擬真實使用者的請求。

例項一: 寫請求

壓測場景： 使用者下單

壓測方法：

• 使用者、商戶、菜品等在數量上與線上等比例縮放；

• 對壓測流量進行特殊標記；

• 根據壓測標記對支付，簡訊等環節進行mock；

• 根據壓測標記進行資料清理；

例項二: 讀請求

壓測場景： 商家列表及關鍵詞查詢

壓測方法：

• 拉取線上日誌，根據真實介面比例關係進行回放

例項三: 無日誌新服務

壓測場景： 商家資質查詢

壓測方法：

• 構建壓測資料使快取命中率為0%時，服務介面效能，資料庫效能；

• 快取命中率為100%時，服務介面效能；

• 快取命中率達到業務預估值時，服務介面效能；

當然，曾經也因為壓測資料碰到過一些坑(跟真實場景有差異):

• 壓測使用者資料未考慮sharding分佈，導致DB單點過熱

• 使用者數量過少，導致單個測試使用者訂單量過多

• 商家數量過少，導致菜品減庫存鎖爭搶激烈

可見，壓測資料模型的構建也不是一蹴而就的，這是一個持續調整持續優化的過程，需要同時考慮資料的真實性，時效性，安全性等。

3. 壓測工具的選型

目前餓了麼壓測工具以Jmeter為主，主要基於以下幾點：

• 開源輕量級，能夠了解甚至修改其每個控制元件的實現

• 方便開發外掛，可以支援如thrift等型別請求

• 支援豐富(如RemoteServer，設定集合點等)

• 壓測結果資料與公司監控指標吻合

4. 壓測指標的監控與收集

應用層面

• 錯誤率

• 吞吐量

• 響應時間(中位線，90線，95線，99線)

• GC

伺服器資源

• CPU利用率及負載

• 記憶體

• 磁碟I/O

• 網路I/O

• 連線數

基礎服務

• MQ

• Redis

• DB

• 其他中介軟體

注意點

• 響應時間不要用平均響應時間，關注95線；

• 吞吐量和響應時間掛鉤

• 吞吐量和成功率掛鉤

後續規劃

本文介紹了全鏈路壓測探索和實踐的過程，但其中還是需要大量的人力介入，包括壓測資料的準備、壓測的執行、壓測結果的分析等。

作者簡介

嚴佳奇，2015年加入餓了麼，現任餓了麼測試基礎設施部資深測試開發工程師，負責餓了麼全鏈路壓測工作。