全鏈路壓測自動化實踐

背景

境內度假是一個低頻、與節假日典型相關的業務，流量在節假日較平日會上漲五到十幾倍，會給生產系統帶來很是大的風險。所以，在2018年春節前，咱們把整個境內度假業務接入了全鏈路壓測，來系統性地評估容量和發現隱患，最終確保了春節期間系統的穩定。

在整個過程當中，咱們意識到，全鏈路壓測在整個系統穩定性建設中佔有核心重要的位置，也是最有效的方案。結合實際業務節假日的頻率（基本平均一個月一次），若是可以把它做爲穩定性保障的常規手段，咱們的系統質量也可以獲得很好的保障。同時，爲了解決週期常態化壓測過程當中人力成本高、多個團隊重複工做、壓測安全不可控，風險高等痛點，咱們提出了全鏈路壓測自動化的設想。

經過對壓測實施的具體動做作統一的梳理，在壓測各個階段推動標準化和自動化，盡力提高全流程的執行效率，最終達到常態化的目標，如圖1所示：

另外，在全鏈路壓測的整個週期中，壓測安全和壓測有效性也是須要一直關注的質量屬性。基於這些思考，如圖2所示，咱們把壓測自動化須要解決的關鍵問題進行了歸類和分解：

• 基礎流程如何自動化，提升人效；
• 如何自動作好壓測驗證，保障壓測安全；
• 壓測置信度量化如何計算，保證壓測有效。

最終，基於美團基礎的壓測平臺（Quake在整個系統，主要提供流量錄製、回放、施壓的功能），設計並實現了全鏈路自動化壓測系統，爲不一樣業務實施全鏈路壓測提效，並確保壓測安全。該系統：

• 提供鏈路梳理工具，可以自動構建壓測入口鏈路完整的依賴信息，輔助鏈路梳理；
• 支持鏈路標註和配置功能，對於無需壓測觸達的依賴接口，能夠經過配置化手段，完成相關接口的Mock配置，不用在業務代碼中嵌入壓測判斷邏輯；
• 提供抽象的數據構造接口，經過平臺，用戶能夠配置任意的數據構造邏輯和流程；
• 在壓測前/壓測中，自動對壓測服務和流量作多項校驗，保障壓測安全性；
• 在平日，基於壓測計劃提供週期性小流量的壓測校驗，使得業務迭代變動帶來的壓測安全風險被儘早發現；
• 提供壓測計劃管理功能，經過系統自動調度和控制施壓過程，解放人力；同時強制前置預壓測，也提升了安全性；
• 一鍵壓測，自動生成報告，收集鏈路入口和告警信息，提供問題記錄和跟進功能。

系統設計

系統整體設計

系統的整體邏輯架構，如圖3所示，主要包括鏈路構建/比對、事件/指標收集、鏈路治理、壓測配置管理、壓測驗證檢查、數據構造、壓測計劃管理、報告輸出等功能模塊。經過這些模塊，爲全鏈路壓測的整個流程提供支持，盡力下降業務部門使用全鏈路壓測的門檻和成本。

鏈路構建/比對：負責服務接口方法調用鏈路的構建、更新、存儲。

鏈路治理：基於構建的鏈路關係，提供鏈路中核心依賴、出口Mock接口等標註、上下游分析、展現，以及出口Mock的配置等功能。

壓測配置管理：自動發現註冊服務的Mafka（美團基於Kafka開發的一個分佈式消息中間件綜合解決方案）/Cellar（基於Tair開發的分佈式KV存儲服務）/Squirrel（基於Redis-Cluster模式進行二次開發的分佈式緩存系統）/Zebra（美團數據庫訪問層中間件）的壓測配置，輔助壓測方覈查和配置相關配置項。

壓測驗證檢查：確保系統可壓測，經過多種校驗手段和機制設計，來保證壓測的安全性。

數據構造：爲不一樣業務壓測實施準備基礎和流量數據。

壓測計劃管理：設定壓測執行計劃，並依賴「壓測控制」模塊，自動調度整個壓測執行過程。

故障診斷：依據收集的關鍵業務/服務指標、報警等信息，判斷分析服務是否異常，以及是否終止壓測。

置信度評估：從數據覆蓋、鏈路覆蓋、技術指標等維度評估壓測結果的置信度，即與真實流量狀況下各評估維度的類似性。

非功能性需求說明：

• 可擴展性

  • 可以兼容不一樣業務線數據構造邏輯的差別性。
  • 可以支持不一樣的流量錄製方式。

• 安全性

  • 集成SSO，按用戶所屬團隊分組，展現所屬的壓測服務信息。對關鍵操做留存操做日誌。
  • 壓測驗證檢查，是確保壓測安全的關鍵。支持週期性壓測驗證，能發現待壓測服務可壓測性隨時間的退化。

• 可重用性

  • 長遠看，鏈路構建、事件/指標收集/故障診斷等模塊，在穩定性領域是可重用的基礎設施，按獨立通用模塊建設。

約束說明：

• 基於Quake搭建，流量的錄製、回放、施壓等依賴Quake。

如下對部分關鍵模塊設計作詳細介紹。

鏈路治理模塊設計

鏈路治理模塊是基於鏈路構建模塊實現的。鏈路構建模塊，底層是以閉包表的方式存儲兩個維度（服務和接口）的鏈路關係的，會週期自動地構建或更新。

鏈路治理模塊主要提供鏈路入口選取、鏈路標註、服務出口分析、出口Mock配置等功能。如圖4所示，註冊壓測的服務構成了壓測服務的範圍，也就肯定了各個鏈路的邊界。經過系統自動構建的樹結構方式的鏈路關係，能夠輔助壓測方對整個鏈路的梳理，它解決了以往鏈路梳理靠翻代碼等低效手段，缺乏全鏈路視角沒法作到完備梳理等問題。

同時，針對整個壓測範圍，依賴接口能夠作人工標註。哪些須要Mock，哪些不須要Mock，如此壓測特有的鏈路信息可以獲得持續的維護。

對於須要Mock的外部接口（如圖4中的接口C），待壓測系統經過引入專有SDK的方式，得到出口配置化Mock的能力。如圖5所示，這裏使用了美團酒旅Mock平臺的基礎能力，採用JVM-Sandbox做爲AOP工具，對配置的須要Mock的外部接口作動態能力加強。在接口調用時，判斷是不是壓測流量，是的話走Mock邏輯，作模擬時延處理，返回提早配置的響應數據。這樣的話，第一，簡化了出口Mock的操做，業務代碼裏Mock邏輯0侵入；第二，把以前本地Mock與藉助Mockserver的兩種解決方案用一種方案替代，便於統一管理；第三，在實際壓測時，平臺還能夠經過SDK收集Mock邏輯執行的數據，自動與後臺標註的Mock數據對比，來確保應該被Mock的出口確實被Mock掉。

數據構造模塊設計

數據構造模塊是爲了解決不一樣業務對於基礎數據和流量數據的差別化構造流程。提出了兩個關鍵的概念：數據構造邏輯和數據構造流程。數據構造邏輯，是數據構造的細粒度可複用的基本單元，由一段Java代碼表示。平臺提供統一抽象的數據構造接口，基於Java動態編譯技術，開發了一個Java版的腳本引擎，支持構造邏輯的在線編輯與更新。同時，基於美團RPC中間件泛化調用能力，構建了泛化調用工具，幫助用戶把外部基礎數據構造接口的調用集成到一個數據構造邏輯中。

數據構造流程，定義了壓測基礎數據和流量數據生成的整個流程。經過與Quake的交互，獲取原始真實的線上數據；構建了一個簡版的流程引擎，在統一設定的流程中，如圖6所示，經過在標準擴展槽中，配置不一樣類型的數據構造邏輯和執行順序，來定義整個數據構造執行的流程；最後，把構造的流量數據與Quake壓測場景綁定，做爲後續Quake壓測施壓中，場景回放流量的來源。

經過這樣的設計，可以支持任意數據構造邏輯，通用靈活。同時集成了Quake已有的流量錄製功能，一鍵執行數據構造流程，大大地提高了效率。

壓測驗證模塊設計

對於壓測安全性的保障，一直是自動化的難點。以前的經驗可能是在非生產環境壓測或預壓測過程當中，依靠不一樣服務相關負責人的人工確認。這裏針對壓測驗證，提供兩條新的思考角度：一個是從待壓測服務系統可壓測性的角度看；一個是從壓測流量特徵的角度看。對於第一個角度，一個服務支持壓測須要知足壓測數據和流量的隔離。對於不一樣的系統生態，須要知足的點是不一樣的，對於美團生態下的服務，可壓測的條件包括組件版本支持壓測、影子存儲配置符合預期等等。

從這些條件出發，就能夠獲得下面這些靜態的校驗項：

• 服務依賴中間件版本要求校驗；
• Zebra壓測配置校驗；
• Cellar/Squirrel壓測配置校驗；
• Mafka壓測開關同步及校驗；
• 服務Mock邏輯存在性校驗。

而從第二個角度來看，就是關注壓測流量下會產生哪些特有的流量特徵數據，經過這些特有的數據來確保壓測的安全性。這裏主要有三類數據：美團分佈式追蹤系統（MTrace）中調用鏈路的壓測標記數據（正常的壓測鏈路應該是一直帶有壓測標記，直到壓測範圍的邊界節點，可參考圖4）；標記Mock的外部接口被調用時，上報的運行數據；基於監控系統獲得的壓測流量特有的監控數據。利用這些數據，咱們設計了三種動態的校驗項，發現壓測標記丟失、Mock出口被調用等異常狀況：

• MTrace鏈路標記校驗，從壓測鏈路入口出發，收集壓測鏈路信息，校驗壓測標記信息傳遞是否符合預期。

• 服務Mock邏輯壓測標記校驗，經過加強的校驗邏輯，把執行信息上報到平臺，與Mock配置時的標註數據對比驗證。

• 壓測與真實鏈路比對校驗，利用鏈路治理模塊構建鏈路的能力，採集壓測監控數據重構鏈路，與真實鏈路對比驗證。

除了明確靜態和動態兩類壓測校驗規則，在具體流程安排上，在壓測時和平日兩個時期執行這些規則。既能把壓測校驗的壓力分散到平時，也能儘快地發現服務因代碼迭代引入的新風險。

在壓測時，經過強制前置預壓測的流程設計以及靜態/動態壓測校驗項的自動執行，保障安全這個事情。校驗不經過，給出告警，甚至在容許的狀況下直接終止設定的壓測計劃。

在平日，經過執行週期性小流量壓測校驗，在施壓過程當中對QPS作個位數的精細控制，以儘可能小的代價快速發現壓測範圍內壓測安全性的退化。

壓測計劃管理模塊設計

壓測計劃管理模塊，提供壓測計劃的提早設定，而後模塊可以自動調度和控制整個施壓過程。如圖11所示，這裏的壓測計劃是多個壓測場景的組合，包含QPS的增加計劃等信息，主要分爲預壓測和正式壓測兩個階段。壓測計劃的自動實施，可以解決尤爲多場景組合壓測，操做耗時多、多場景壓測QPS沒法同步變動、壓測方沒法兼顧操做和觀測等問題，提高了效率。同時，在壓測計劃執行狀態機裏，預壓測正常執行完成，狀態才能遷移到正式壓測的開始狀態，提升了壓測安全性。

從圖11能夠看到，壓測計劃模塊，是整個自動化壓測的核心，協同起了各個模塊。經過具體的計劃任務執行產生的事件，觸發了壓測驗證檢查、壓測進展播報、收集壓測監控/告警等數據，來檢測服務是否異常，並根據配置來終止壓測，可以故障時及時止損。最後，報告生成模塊收到壓測終止事件，彙總各類信息，自動生成包括壓測基本信息等多維度信息的壓測報告，節省了一些壓測後分析的時間。

案例分享

如下以實際壓測的過程來作個案例分享。

團隊/服務註冊

• 設定實施壓測的虛擬團隊和壓測覆蓋範圍的應用服務。

鏈路治理

• 選定壓測鏈路入口，能夠獲得入口如下的接口鏈路關係樹，便於梳理。
• 明確須要Mock的外部接口，並作配置，參考「鏈路治理模塊設計」一節。

應用改造與壓測配置

• 對待接入壓測應用改造，知足「服務的可壓測條件」，參考圖7。
• 壓測應用依賴中間件配置，系統依據構建的鏈路信息，可以自動發現。提供統一配置和核對的頁面功能。

Quake準備

• 壓測自動化系統是基於Quake構建的，流量錄製、回放、施壓等依賴於此。所以須要到Quake上配置流量錄製的「流量任務」和壓測執行的「壓測場景」。

數據構造

• 配置數據構造邏輯，固然已有的邏輯都是可複用的單元，能夠先查看已有邏輯是否能知足本身的須要。

• 配置數據構造流程。

壓測實施

• 設定壓測計劃，到啓動時間，系統會自動啓動壓測。

• 壓測中，注意關注壓測驗證校驗的告警信息，及時處理。

• 壓測後，可查看壓測報告。記錄和跟進發現的問題。

總結與展望

目前，壓測自動化系統已經投入使用，美團酒店和境內度假的所有團隊已經接入，有效地提高了壓測效率。後續會在兩個大方向上持續建設升級，一個是把全鏈路壓測放到「容量評估與優化」領域來看，不只關注總體系統的穩定性，同時也指望兼顧成本的平衡；另外一個是與穩定性其餘子領域的生態集成，好比故障演練、彈性伸縮等等，在更多場景發揮壓測的做用。最後，經過這些努力，使得線上系統的穩定性成爲一個肯定性的事情。

參考資料

• [1] 全鏈路壓測平臺（Quake）在美團中的實踐
• [2] 阿里JVM-Sandbox
• [3] Dubbo的泛化調用
• [4] Java的動態編譯

做者簡介

• 歐龍，美團研發工程師，2013年加入美團，目前主要負責境內度假交易穩定性建設等工做。

歡迎加入美團基礎架構技術交流羣，跟做者零距離交流。進羣方式：請加美美同窗微信（微信號：MTDPtech02），回覆：壓測，美美會自動拉你進羣。