播放全鏈路壓測實踐之路

01

背 景 

播放鏈路是愛奇藝最重要的業務，鏈路穩定性極其重要，隨着愛奇藝用戶的不斷增長和熱播劇集的推廣，播放鏈路往往面臨着難以預估的用戶流量的突增，考驗着鏈路中各個服務系統的穩定性和性能，這也直接影響着大量用戶的觀影體驗，實施全鏈路壓測已經成爲重要且必要的課題。

• 爲什麼要進行鏈路級的壓測，單機、單系統壓測爲何不可達成目標？
  
  
• 線上容量 ≠ 單機容量 * 數量：線上運行環境是複雜多變的，即使配置相同的機器也不能保證性能的完全一致，並且，除機器本身性能外，線上容量還受制於機器間的網絡通信、資源爭奪、數據庫交互、集羣管理、緩存效率、負載不均等等多方面的影響，任何一點都有觸發性能瓶頸的可能，從而不能單純的只通過單機 * 數量去評估線上容量。
  
  


• 單系統無法體現用戶角度的性能：用戶請求是鏈路級的，而鏈路中各個系統的容量規劃往往不對齊的。受不同的用戶場景，用戶來源，路由策略等影響，流量在鏈路上的分佈情況不是一成不變的，整個鏈路上的瓶頸點非常不易發現和預測。因此需要進行全鏈路的多地域多來源的測試，並構建各種流量參數比例的流量場景模擬不同業務場景的用戶行爲等。
  
  


• 基於線上環境 or 測試環境進行鏈路級壓測？
  
  
• 線上壓測更準確：線上環境更加複雜，測試環境無法保證搭建效果與線上一致，任意一個配置的不一致都可能導致容量的差異，而無法體現真實用戶使用效果，且搭建可用於鏈路級壓測的測試環境資源需求量巨大，可行性不高。
  
  
• 對線上環境進行壓測的風險如何規避？
  
  
• 例如防止壓測數據污染線上數據，污染緩存，干擾線上指標統計，誤觸線上的熔斷降級，避免沒做好準備的外部依賴方被壓測打掛等等。
  
  


方案review+腦暴很重要 ：規避風險的措施需要在實踐過程中反覆分析、討論、解決/規避。
以下以【播放-點播鏈路】爲例闡述壓測實踐過程。

 

02

實踐過程

全鏈路壓測所能達成的效果往往依賴於施壓能力的仿真程度，主要包括鏈路仿真和用戶仿真

鏈路仿真：用戶鏈路 vs 施壓鏈路，考驗施壓鏈路環境的模擬能力

用戶仿真：用戶請求 vs 施壓QPS+詞表，考驗施壓壓力及詞表構造的模擬能力

1. 梳理播放鏈路拓撲

爲什麼先做鏈路拓撲梳理？是後續工作的基礎，重中之重

• 識別鏈路系統，明確核心鏈路，協作目標更聚焦
• 識別鏈路風險，明確對用戶的影響，包括用戶數據、業務指標、監控數據等
• 識別技術依賴，明確業務系統和基礎平臺的改造、升級目標，尋找最折中方案，降低不確定性的同時，工作量最低
• 識別關鍵數據，便於壓測場景（即壓測詞表）的構造

以鏈路入口應用進行系統間調用、數據庫、中間件讀寫的邏輯梳理，進而繼續延伸至上游系統，最終繪製出完整的鏈路拓撲圖

做了哪些工作：

• 推動各系統研發梳理各自業務內拓撲文檔
• 與研發腦暴梳理結果，分析關鍵性能影響點、挖掘問題及風險
• 基於文檔繪製交互拓撲圖
  
  

達成的效果：

• 明確壓測核心鏈路：播放、會員權益系統、會員權益監控系統等
• 識別髒數據風險：數據統計的影響等
• 明確壓測工具需求：
• 流量控制：攔截統計消息
• 數據隔離：支持mysql、redis等的影子庫、影子表，規避線上寫入髒數據
• 流量監控：QPS、響應耗時、CPU、內存、中間件監控、上游服務監控等
• 明確核心性能影響因素：
• 片源時長、付費類型、會員身份
• 明確核心場景：
• 春晚：免費超長視頻（歷史峯值佔比50%，非真實數據）
• 熱劇：付費視頻（付費流量歷史峯值佔比60%，非真實數據）

爲什麼不直接使用單url or 錄製線上流量進行壓測？

• 定製流量更貼近性能目標：單url不具代表性，且鏈路不全，不利於性能影響點的分析；錄製流量在特定場景下有一定意義，比如春晚流量等，但由於難以分析出各場景比例，比如不同時長片源佔比，付費片源佔比，難以精準判斷性能影響點，從而無法有效說明壓測目標及效果

2. 明確壓測目標

壓測目標：在 不同場景 下，綜合評估 播放鏈路 的 容量（QPS）

需根據實際容量評估情況調整目標容量（以下數據僅供說明使用，非正式數據）

• 壓測鏈路：播放、會員、用戶鏈路
• 壓測環境：線上各機房+全網
• 壓測場景：春晚（>4h超長視頻佔比50%，非真實數據）、熱劇（付費流量佔比60%，非真實數據）
• 容量目標：不低於歷史峯值n倍容量目標

3. 壓測工具調研

• 施壓能力（LoadMaker）：
• 單機房高壓QPS的發壓能力：可針對施壓集羣進行擴容
• 單機房億級詞表的調度能力（根據施壓QPS+時長制定）：多任務併發實現
• 梯度增壓、暫停增壓能力：用於壓測過程觀測，及時止損
  
  
• 鏈路控制（Rover）：
• 流量控制： 攔截數據統計：支持，Rover平臺配置即可，同時構造測試設備雙重規避
• 數據隔離： 支持影子庫、影子表，規避寫入髒數據：不支持場景可通過構造測試賬號規避
• 流量監控： QPS、響應耗時、CPU、內存、中間件監控、上游服務監控等：支持，並結合業務自身監控觀測數據更全面
  
  
• 工具性能（Rover agent）：
• 對服務性能0/低影響
• 施壓入口（LoadMaker）：
• 支持外網網關：一期優先使用內網網關

4. 構造壓測場景

場景：不同類型 用戶 播放 不同類型 視頻

舉例如：

• 測試數據入庫：測試賬號、測試設備ID、視頻信息（時長、付費類型等）
• 明確不同維度下的屬性比例：
  
  
  
  
  
  
• 詞表生成-支持不同屬性佔比的配置化生成方案：
• 交叉組合：支持多層屬性的組合，可靈活配置不同屬性及下一級屬性的佔比配置

遇到的問題：

• 詞表生成耗時過長：億級詞表單機模式已無法滿足效率需求，評估單純通過優化生成腳本已無法有效提升效率

解決方案：

• 詞表生成容器化：依託內部jenkins服務，基於iks進行容器化部署，實現多容器並行生成詞表，大大提高效率

5. 壓測方案及規劃

梳理各系統現狀：各機房當前及歷史峯值流量

明確按目標QPS及現有詞表流量配比下，各系統能否達成預期流量，是否需要擴容，並給出擴容完成時間

壓測過程：線下單機演練 ->  線上集羣（逐步增加壓測範圍）演練

壓測規劃：

• 根據關鍵時間節點進行時間倒排，保證壓測前各項準備事務全部ready
• 制定壓測場景規劃，明確壓測時間點、各業務負責人、緊急預案，爲儘可能規避對用戶的影響，大QPS壓測需控制在低峯時段，並提前進行郵件審批和周知
  
  

• 制定壓測實施checklist，儘可能詳盡說明每一步操作和確認項，避免遺漏
• 壓測前一天進行一輪線下驗證，確認施壓能力、環境連通性，保證壓測順利實施

容量評估標準：包括但不限於以下幾點

• CPU、內存佔比：<=70%
• 響應耗時：根據業務而定
• 請求錯誤率：0.01%
• 業務錯誤率：0.01%
  
  

6. 壓測執行

• 壓測checklist
  

• 施壓策略：
• 明確併發數及步調時間：提前與研發溝通確認，並可在執行過程中調整優化
• 階梯施壓：緩慢增壓、流量突襲
• 實時反饋觀測結果，如有問題，隨時暫停或停止施壓，及時止損
• 壓測執行過程中數據觀測：
• Rover平臺觀測壓測流量：QPS、耗時、CPU、內存、上游服務QPS
• 各業務內部監控平臺觀測整體流量：QPS、耗時、CPU、內存、上游服務QPS、業務錯誤率、降級/熔斷等災備流量、緩存命中率等
• 數據庫/中間件性能監控
• 分析觀測數據，評估鏈路容量
• 容量評估：應用、數據庫、中間件，最終QPS是否達成，瓶頸在哪裏
• 災備能力評估：降級、熔斷策略，閾值是否合理，在多大QPS下觸發了災備策略，是否仍有優化空間
• 給出壓測結論及待解決問題

03

實踐效果及收益

• 播放鏈路首次線上壓測，且實現對真實用戶0影響
• 完成歷史峯值n倍QPS下播放各系統服務的容量評估
• 協同各業務完成7次擴容、5次災備策略優化、4次性能問題修復等等
• 支撐春晚、熱劇期間大流量下播放不出故障

04

總結和展望

在公司多個團隊、兩個季度的協作下，共同完成了播放全鏈路壓測0-1的建設，並實現了首次超大QPS的線上環境全鏈路壓測，具有里程碑意義。

但目前壓測能力仍有許多不足，未來仍需進一步提升仿真能力，以更好的評估性能及影響瓶頸點：用戶仿真，詞表能力升級，支持更多維度；鏈路仿真，支持外網施壓、多鏈路聯動、多場景聯動等。

本文分享自微信公衆號 - 愛奇藝技術產品團隊（iQIYI-TP）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。