背景
愛奇藝除了每天都爲數以億計的用戶提供優質的視頻服務，同時還有體育、直播、文學等業務服務於更多的圈層用戶，海量的業務幾乎每天都在進行營銷活動，由此帶來的流量隨時可能會給我們的服務引入不確定性。愛奇藝支付團隊爲各業務線提供全面的收付款服務，保障用戶的付費體驗，團隊除了保障服務的穩定性外，還要應對隨時可能爆發的流量挑戰。對於支付系統來說做好準確的容量評估和預案是非常重要的，全鏈路壓測在這方面提供了有力保障。
全鏈路壓測是基於生產環境，模擬業務高峯時的海量請求，對整個系統鏈路進行壓力測試，繼而進行有效的容量評估和系統調優。因爲支付業務對數據敏感同時業務複雜，使得系統間調用鏈路難以準確全面評估，實施壓測比較困難，在沒有實施全鏈路壓測前，我們經常會遇到以下問題：
- 生產環境流量構成複雜，單機壓測結果難以有效評估生產環境容量；
- 流量轉化評估與實際用戶行爲不匹配，導致預案不能達到預期效果；
- 公共資源/服務很難在局部壓測中暴露瓶頸，需要真實的高峯流量來驗證；
- 鏈路容量不能對齊導致整體受限於短板服務，同時也產生了嚴重的資源浪費。
以上問題歸結原因主要是沒有在生產環境使用真實場景的流量去壓測系統，也就無法做出準確評估，爲了解決以上問題，我們開始了全鏈路壓測在以支付業務爲核心場景的探索與實踐。
問題探索與方法實踐
開展全鏈路壓測我們主要從幾下方面進行了探索與實踐：
- 核心鏈路梳理， 明確壓測目標鏈路和分支鏈路，排除壓測風險；
- 壓測環境準備， 壓測全鏈路能夠透傳壓測標識並正確處理壓測流量；
- 流量構造， 結合真實的數據和需求策略分析制定壓測流量模型；
- 執行與保護， 實施前做好業務驗證，按計劃實施，做好監控和覆盤。
1 核心鏈路梳理
核心鏈路梳理將多個業務線串聯到一起，在實施過程中，我們由各業務團隊梳理自己的核心鏈路，明確對下游服務的依賴，同時梳理出旁路依賴。將各業務線的核心鏈路進行彙總，得到最終的壓測全鏈路。核心鏈路中可能會耦合外部服務但又不能參與壓測，比如支付系統依賴的第三方渠道。在實踐中我們通過自建渠道mock服務支持了多種渠道的支付請求，同時模擬渠道的支付成功率，支付回調延遲，支付通知等，形成支付全鏈路的閉環。
旁路依賴的梳理也是重要的一環，準確全面的梳理是後續順利進行壓測的保障。旁路依賴根據實際業務情況評估，如風控系統我們進行了mock，賬務服務通過消息組件實現了服務降級。
在與票務業務的一個搶票場景做鏈路梳理後，核心點主要涉及用戶的登錄鑑權、票務活動、出票、收銀臺、支付和通知6個服務，對風控、推薦、push等旁路依賴評估後做了降級處理，對支付渠道和票務渠道的重要服務指標進行mock，最終形成一個業務閉環的核心鏈路，如下圖：
2 壓測環境準備
核心鏈路依賴的環境除了業務的服務器外還涉及數據庫、消息、緩存、日誌等，在這一階段我們主要對以下幾點進行了考慮和支持：
-
壓測標識透傳
通過在入口流量中注入約定的標識用於區分壓測流量，全鏈路識別並透傳該標識是實現全鏈路壓測的基礎。我們的系統通過接入APM（Application Performance Management）對系統進行監控管理和調用跟蹤，天然實現了一次調用在http、rpc、線程池以及中間件的信息保持，因此APM成爲壓測標識的首選載體，在實踐過程中我們通過對APM簡單改造實現了壓測標識的透傳和識別。
-
存儲數據隔離
壓測流量會影響包含寫業務的數據庫，造成數據混亂，這一點對支付業務尤爲重要。對關係數據庫，通過新建與原表結構一致的影子表，並將壓測流量引入到影子表，實現壓測數據的隔離。如何路由影子流量到影子表看項目的具體情況，我們通過ShardingJDDC和Mybatis攔截器兩種方式實現了影子表的路由。
-
消息
消息中間件我們沒有采用新增topic的方式，而是在消息體中加入了壓測標識，需要降級的消費端通過訂閱策略處理壓測消息，例如我們在RocketMQ的消息體中附加約定的UserProperty屬性，消費者按需訂閱。
-
水位
中間件對壓測流量的處理基本採用了數據隔離的方式，壓測實施前將影子表等填充到與原始表相同的水位是很有必要的。一張空表和一張含有上千萬數據的表性能表現是不一樣的。
核心鏈路上可能會有很多技術組件要支持壓測流量，原則和方案都是類似的，根據實際業務情況做好數據隔離即可。如Redis可以使用影子key或者影子集羣，MongoDB使用影子collection， ElasticSearch使用影子索引，日誌新建影子目錄。下圖是愛奇藝的支付系統在全鏈路壓測環境準備好後，核心鏈路對壓測流量的處理情況：
![]()
3 流量構造
單接口壓測時我們會提前生成好一批符合接口規範的數據備用，但這種數據過於單一，並不符合真實的業務場景。比較理想的方式是在網關層抓取生產環境的日誌數據進行二次處理後對流量進行回放。我們在初期的探索階段並沒有實現這種方式，我們對已有的數據和接口調用量進行分析，結合業務策略對數據模型進行調整，得到最終的壓測模型。例如在支付業務的全鏈路壓測中，我們通過數據分析得出用戶在生產環境中選擇各支付方式的佔比、各服務調用佔比，同時結合業務策略對用戶購買指數的影響，微調收銀臺轉化率，最終確定下單服務、渠道通知、訂單查詢等服務調用量配比模型。
4 壓測執行與保護
執行壓測前，對全鏈路進行業務和環境驗證是必不可少的，各業務確保壓測旁路已做好降級和數據隔離，保證壓測流量不影響正常業務數據。
監控是全鏈路壓測實施過程中評估系統健康的重要手段，幫助我們發現問題，及時止損。在壓測過程中我們事先準備了以下維度的指標：
- 核心鏈路服務調用量，成功率，耗時；
- 消息積壓監控，redis水位、命中率，數據庫負載等性能指標；
- 機器的基礎指標。
各業務負責人需要在壓測前做好自身的限流和降級，同時還要爲正常的業務流量預留安全的buff，不能完全依靠壓測平臺的熔斷條件。壓測也會檢驗我們的限流值是否合理，降級預案是否能正常執行，是否符合預期。
壓測實踐與結果
全鏈路壓測能力打通後，我們主要基於以下兩個方面實施了全鏈路壓測：
1 業務容量驗證
支付團隊與直播、票務等團隊在營銷、搶購活動中進行全鏈路壓測，以滿足業務需求容量爲目標，有效定位全鏈路中的短板服務，通過擴容、異步化、降級等方式處理，保證了全鏈路的容量達到預期目標。同時對限流、降級策略進行驗證，保證業務在高峯時的可用性。
壓測時支付系統提供多種支付方式的支持，渠道mock服務提供貼近真實的拉起延遲、訂單成功率mock、同步響應、異步服務器通知、通知延遲等場景，形成全鏈路壓測閉環。
2 系統極限壓測
支付系統本身也是一個結構複雜的系統，收銀臺、賬務、風控、認證、渠道等相關服務都由相關團隊維護，任何一個環節保護不到位都可能影響整體系統的穩定性，因此對支付系統的全鏈路壓測是很有必要的。
實施中主要拆分爲兩個方向：
-
虛幣消費壓測
虛幣消費的特點是不涉及第三方渠道，但它也是一種標準的支付方式，具有與其他支付方式(如微信、支付寶)一樣的生命週期。好處是不依賴第三方渠道，有效驗證支付系統自身的容量。
在起初的壓測中，我們發現虛幣支付的TPS只能達到設計容量的60%，通過對鏈路的耗時分析發現在訂單號生成服務出現了部分降級，拉高了整體的RT。進一步分析發現是分佈式訂單號的自增序列依賴redis，在與redis的交互中出現抖動，與中間件團隊確認後最終定位到是RDB持久化時fork子進程引起了服務停頓。根據當前場景的需求，我們關閉了RDB，配合降級策略的優化，幾輪壓測調優後支付系統的TPS基本接近目前部署服務的可負載容量極限。
-
混合壓測
基於我們對生產環境的數據分析，構造多種支付方式以一定配比對收銀臺服務進行壓測，這個場景可以真實的模擬支付系統的上游流量，覆蓋更全面的業務場景。通過壓測，定位到一些服務節點容量不匹配問題，通過服務水平擴容和代碼優化，最終將容量對齊。
全鏈路壓測需要跨業務部門合作，每一次壓測都要做好事前計劃：目標是什麼，需要哪些數據衡量，需要哪些預案，壓測流量策略如何設置和執行等，同時做好覆盤和結果跟進，保障壓測在有序可控的前提下實施。
未來規劃
在整個全鏈路壓測實踐中涉及到的需求點很多而且分散，如數據模型、流量調度、監控跟蹤、性能分析等，很多細節處於探索階段。後續結合更多的實踐經驗，進行統一規劃形成一站式的解決方案，降低全鏈路壓測的接入難度和實施成本。
對於涉及支付系統的全鏈路壓測，流量來自上游業務，對支付方式多樣性的構建是有一定成本的，後續計劃支持將上游單一流量自動配比爲多樣化的支付請求。支付相關業務對數據比較敏感，提供支付壓測數據報告給上游業務以及賬務等相關業務，可以在必要時滿足覈對需求。
本文轉載自公衆號愛奇藝技術產品團隊（ID：iQIYI-TP）。
原文鏈接：