電商大促作戰指南之全鏈路壓測

電商大促作戰指南請看上一篇：電商大促作戰指南，因篇幅有限，這里單獨對全鏈路壓測進行詳述，

目錄

1. 壓測人員確定

2. 核心鏈路業務梳理

3. 流量預估與壓測模型產出

3.1 入口流量預估

3.2 節點流量預估

3.3 壓測模型產出

4. 壓測資料準備與聯調

5. 壓測執行

5.1 前置作業

5.2 分場景不同時長壓測

5.3 監控指標

5.4 壓測記錄

5.5 壓測結束

6. 壓測恢復

7. 壓測復盤

全鏈路壓測是一項既耗時又耗人力的作業，所以必須要做好詳細且周密的計劃，全鏈路壓測涉及的重要節點如下圖所示：

另外，在做全鏈路壓測前，核心鏈路涉及的應用首先要消滅掉已知的性能問題，否則會影響全鏈路壓測進度，筆者曾經經歷的幾次全鏈路壓測中沒有一次能完整順利地進行的，往往需要2~3次才能壓到預期的結果，下面會針對全鏈路壓測每個環節的流程和注意點進行詳述，

1. 壓測人員確定

壓測人員需要做到廣而精，“廣”是指人員要覆寫到核心鏈路應用負責人、運維、DBA、重要中間件負責人，“精”是指壓測人員需要熟知負責應用的上下游，同時能在壓測期間出現性能問題時能快速解決問題，

2. 核心鏈路業務梳理

核心鏈路業務梳理內容主要包括兩項：應用強弱依賴梳理（限流降級等）、高風險業務梳理（比如上次大促后，存在大版本升級的業務應用或者未經歷過大促的業務），這里最好產出一張應用大盤圖，標注出核心鏈路，示例如下：

圖參考：極客時間《全鏈路壓測30講》

在梳理出核心鏈路后，需要應用owner再梳理出核心介面，主要用于三個場景：性能指標監控、限流等穩定性措施配置、壓測，示例如下：

圖參考：極客時間《全鏈路壓測30講》

另外高風險業務梳理完成后需要給出明確的穩定性方案，比如可降級，需要給出降級方案，不可降級需要給出可替代或者緊急預案，盡量在大促前把所有可能都設想一遍，

3. 流量預估與壓測模型產出

流量預估比較考驗應用負責人的功底，應用負責人要熟悉負責應用的上下游依賴和重要核心介面的性能指標，只有這樣才能合理地進行流量預估，這個階段應用負責人需要做幾下幾項作業：

• 梳理出關鍵路徑的核心介面，包括其上下游依賴應用及性能指標
• 根據歷史大促水位和介面性能指標預估出介面容量，比如介面的qps值
• 輸出應用壓測模型

3.1 入口流量預估

系統流量入口是指呼叫鏈路的起始端，比如首頁、商品詳情頁和串列頁等場景的呼叫始端是指mall、detail等應用，預估的方式通常是參考歷史GMV或者訂單數量或者DAU（筆者所在公司可是使用同時在線的門店數量），在參考的同時也要考慮一些不變的因素，如營銷活動、活動商品的相似性等，以20210518大促流量預估示例，在進行預估時參考了20201215的大促流量，同時營銷活動場景也類似，所以具有很強的參考意義，附流量預估參考GMV通用公式如下：

預估大促qps值=（預估大促GMV/歷史大促GMV）*歷史大促qps值

另外，在預估時要考慮以下不變的因素（因素較多，需要參考具體的業務場景）：

• 營銷活動差異：參考歷史大促進行預估時需要注意到，相同GMV不同的營銷活動場景，相應的大促qps峰值是不同的，所以在進行預估時需要考慮營銷活動的差異性，比如1215和518大促活動玩法、GMV相似，那在整點的qps峰值也是相似的，是很有參考價值的，
• 活動商品的差異：活動商品的差異會影響成交的訂單量，間接影響成交的GMV，最終也會影響到流量預估的準確性，如327大促和518大促GMV一樣，但針對的商品型別不一樣，327大促針對的是A類商品，518針對的是B類商品，B類大促的客單價是高于A類大促的，所以理論上327大促的訂單量會大于518大促的訂單量，即327大促的qps值理論上會高于518大促的qps值，
• 活動時間的差異：事實上518大促的qps值是低于各應用owner給出的qps值，是因為忽略到了季節的差異性，即“一年中的上半年是下單的淡季”，相對于年終來說流量相對較少（年終有春節和元旦重要的節假日），
• ......

3.2 節點流量預估

作為流量入口鏈路上的節點同樣在大促中給出流量預估值，如營銷核心應用smc應用和mrc應用，節點流量由入口流量根據流量分支模型，按比例轉化而來，分支流量模型以系統鏈路為計算基礎，遵循以下幾個原則：

• 同一入口，不同鏈路占比流量獨立計算
• 針對同一鏈路上同一節點，若存在多次呼叫，需計算按倍數同比放大
• DB寫流量重點關注

舉例說明，mrc應用中 multiMatchForKeyDataId 介面是營銷的核心介面，流量預估時首先切分上游的流量，如下圖

multiMatchForKeyDataId的上游流量除應用owner評估外，還需要同各上游確認預估值是否能滿足上游呼叫（如icm的1.085\%的流量大本次大促預估中是否有流量發生變化，若有變化，變化系數多少，一般這個值是由上游應用owner來確認），見下表：

上表統合上面計算出mrc應用multiMatchForKeyDataId介面預估出2010，同時做好客戶端和服務端限流即可，該預估方式得出的值與1222號大促值十分接近，在理想情況下應該有個介面呼叫地圖，地圖中每個應用的核心介面做為節點，節點連線表示呼叫關系，連線的值作為qps值，

3.3 壓測模型產出

在各應用做好流量預測后，便可以初步得出壓測模型，如下圖所示，該壓測模型用于后期與壓測得出模型、大促真實流量模型進行對比，用于驗證流量預測的偏差，為后續大促支持積累寶貴的壓測經驗，

附圖中值是示例值，僅供參考

4. 壓測資料準備與聯調

壓測資料準備包括影子庫申請、流量錄制和壓測資料初始化（影子庫），其中壓測資料初始化是指將流量錄制時間點的資料快照初始化到影子庫中，筆者所在公司壓測平臺采用的是流量平臺進行流量錄制（GoReplay），錄制回放程序中使用壓測標透傳整個鏈路，透傳到DB層使用影子庫進行隔離，這里不詳述全鏈路壓測的技術方案，壓測資料準備程序中需要注意以下幾點：

• 流量錄制的場景盡量選擇與大促相似的場景
• 流量錄制時間點的線上資料要保存快照初始化到影子庫中，前后時間不能相差太大，否則會出現壓測請求得不到正常回應
• 壓測資料重點關注導購和營銷資料的時效性，往往流量錄制時間點和真正壓測時間不在同一個時間段，經常會出現活動資料失效的場景

基于以上資料準備后，便可進行小比例流量進行除錯，在不影響線上業務的前提下確保流量入口介面請求成功率100%、回應資料能正常寫入影子庫、確保所有的監控都已到位等，

5. 壓測執行

壓測執行是壓測程序中最關鍵的環節，壓測的目的是指出系統的“最大”和“最佳”點，如下圖所示（參考關于性能測驗的幾個要點）：

上圖中在輕負載區域和重負載區域交界處稱為"最佳點"，而重負載區域和負載失效區域交界處稱為"最大點"，

• 當系統的負載等于“最佳點”時，系統的整體效率最高，系統資源利用率適中，用戶請求能夠得到快速回應
• 當系統負載處于"最佳點"和"最大點"之間時，系統可以繼續作業，但是回應時間開始變長，系統資源利用率較高，并持續保持該狀態，如果負載一直持續，將最侄訓導致少量的用戶無法忍受而放棄
• 當系統負載大于“最大點”時，將會導致較多用戶因無法忍受超長的等待而放棄使用系統，有時甚至會出現系統崩潰而無法回應用戶請求的情況發生

所以壓測程序中要考慮壓測時長，比如180s、300s、600s系統指標是怎么樣的，進而找到系統的“最佳”和“最大”性能點，因為有個很形象的說法就 是：你能夠承擔100千克的重量，而且也能走，但是你能否承擔100千克的重量行走1個月，筆者曾經做單介面壓測時就走入了一個誤區，只要發現某個場景某個輪次達到系統“個人理解”意義的最高點，便停止壓測了，事實上這個最高點是位于“最佳”點，還是位于“最大點”卻不得而知，即無法得出系統（或者介面）的真正水位，

5.1 前置作業

快取預熱、介面限流值關閉等，另外壓測執行前還需要確定施壓流量的地域分布，應盡量擬合真實的用戶分布，才能保證測驗結果真實可信，對于區域性的在線業務，施壓機分布在當地的同一機房，是可以理解的，如果是全國性的在線業務，施壓機也應該按照用戶分布，在全國各地域部署，

5.2 分場景不同時長壓測

壓測場景需要按大促業務場景來定制，比如本次大促有秒殺券，則構造基礎資料與流量錄入環節需要考慮相應的場景，確定好壓測場景好再按系統容量可分為基線、容量摸高、穩定性和例外場景，最后分不同時長壓測來觀察系統穩健度，所以壓測執行前需要規劃好壓測場景、壓測輪次和每輪壓測持續的時長，這是一項比較復雜的作業，

5.3 監控指標

在壓測程序中需要時刻觀察系統指標，包括但不限于：

• 服務器指標：機器cpu、記憶體、網路流入流出、jvm指標等
• 資料庫指標：慢sql數量、qps、索引命中率、鎖等待時長等
• 業務指標：下單趨勢、下單成功率等
• 系統指標：核心介面qps、平均rt、失敗率等
• ......

一旦指標出現例外則停止壓測，所以這里有必要梳理出壓測啟動、停止和結束準則（不再詳述），壓測結束后，壓測報告中重點觀察三個核心指標（需要具體到秒級別的統計，往往系統高峰期會產生秒級曲線）：請求成功率、介面（系統）qps、介面（系統）平均rt，

5.4 壓測記錄

壓測程序中還需要做好壓測指標、壓測問題和壓測現場記錄，因壓測參與人多，壓測時間比較寶貴，記錄方式可以采用截圖結合概要記錄的方式來進行壓測記錄，只要做到重要資訊不遺漏即可，方便壓測結束后進行壓測結果分析，

5.5 壓測結束

壓測執行結束后，一般全鏈路壓測結果會有兩種場景：

1. 低于大促性能要求，需要解決系統瓶頸，再次進行全鏈路壓測，直到系統滿足大促目標容量
2. 達到大促性能要求（一般達到大促預估容量1.5倍以上），則可嘗試對系統進行進一步摸高，壓出系統的瓶頸點

下圖是筆者壓測執行程序示例（僅供參考）：

6. 壓測恢復

壓測恢復是指壓測后進行的一系列有關壓測資源回收和資料清理的操作，比如回收壓測機器、應用縮容、回收影子庫、清理壓測資料等，為避免排查壓測性能問題時監控資訊丟失（比如影子庫監控是隨著影子庫的回收而回收），資源的回收資訊需要同步到壓測技術群，筆者曾經為了排查壓測產生的慢sql問題，因影子庫回收而不得不自行進行一次壓測來恢復現場，

7. 壓測復盤

壓測復盤是對壓測程序進行分析總結，并根據以下點來決定是否要再進行一次全鏈路壓測：

• 是否達到大促性能要求
• 是否出現影響大促的性能問題，如果出現性能問題，則需要分析具體性能問題并給出解決方案

如果壓測結論符合預期，可以得出系統的性能指標，并據此來配置限流降級策略來保證系統穩定性，下圖示例為筆者在一次全鏈路壓測時遇到的性能問題總結示例提供參考：

如轉載，請注明出處！歡迎關注微信公眾號：方辰的博客