背景

在美團的價值觀中，“以客戶為中心”被放在一個非常重要的位置，所以我們對服務出現(xiàn)故障越來越不能容忍。特別是目前公司業(yè)務正在高速增長階段，每一次故障對公司來說都是一筆非常不小的損失。而整個IT基礎設施非常復雜，包括網(wǎng)絡、服務器、操作系統(tǒng)以及應用層面都可能出現(xiàn)問題。在這種背景下，我們必須對服務進行一次全方位的“體檢”，從而來保障美團多個業(yè)務服務的穩(wěn)定性，提供優(yōu)質的用戶服務體驗。真正通過以下技術手段，來幫助大家吃的更好，生活更好：

• 驗證峰值流量下服務的穩(wěn)定性和伸縮性。
• 驗證新上線功能的穩(wěn)定性。
• 進行降級、報警等故障演練。
• 對線上服務進行更準確的容量評估。
• ……

全鏈路壓測是基于線上真實環(huán)境和實際業(yè)務場景，通過模擬海量的用戶請求，來對整個系統(tǒng)進行壓力測試。早期，我們在沒有全鏈路壓測的情況下，主要的壓測方式有：

• 對線上的單機或集群發(fā)起服務調用。
• 將線上流量進行錄制，然后在單臺機器上進行回放。
• 通過修改權重的方式進行引流壓測。

但以上方式很難全面的對整個服務集群進行壓測，如果以局部結果推算整個集群的健康狀況，往往會“以偏概全”，無法評估整個系統(tǒng)的真實性能水平，主要的原因包括：

• 只關注涉及的核心服務，無法覆蓋到所有的環(huán)節(jié)。
• 系統(tǒng)之間都是通過一些基礎服務進行串聯(lián)，如 Nginx、Redis 緩存、數(shù)據(jù)庫、磁盤、網(wǎng)絡等等，而基礎服務問題在單服務壓測中往往不能被暴露出來。

綜合多種因素考慮，全鏈路壓測是我們準確評估整個系統(tǒng)性能水平的必經(jīng)之路。目前，公司內所有核心業(yè)務線都已接入全鏈路壓測，月平均壓測次數(shù)達上萬次，幫助業(yè)務平穩(wěn)地度過了大大小小若干場高峰流量的沖擊。

解決方案

Quake （雷神之錘）作為公司級的全鏈路壓測平臺，它的目標是提供對整條鏈路進行全方位、安全、真實的壓測，來幫助業(yè)務做出更精準的容量評估。因此我們對 Quake 提出了如下的要求：

• 提供模擬線上真實流量的能力
  • 壓測和 DDoS 攻擊不同的是，壓測有應用場景，而 DDoS 可能只需要一個請求。為了更真實的還原用戶行為，我們需要獲取線上的真實流量進行壓測。
• 具備快速創(chuàng)建壓測環(huán)境的能力
  • 這里的環(huán)境指的是線上環(huán)境，因為如果壓測的是線下環(huán)境，即使不考慮“機器配置是否相同”這個因素，像集群規(guī)模、數(shù)據(jù)庫體量、網(wǎng)絡條件等這些因素，在線下環(huán)境下都無法進行模擬，這樣得出壓測結果，其參考價值并不大。
• 支持多種壓測類型
  • 壓測類型除了支持標準的 HTTP 協(xié)議，還需要對美團內部的 RPC 和移動端協(xié)議進行支持。
• 提供壓測過程的實時監(jiān)控與過載保護
  • 全鏈路壓測是一個需要實時關注服務狀態(tài)的過程，尤其在探測極限的時候，需要具備精準調控 QPS 的能力，秒級監(jiān)控的能力，預設熔斷降級的能力，以及快速定位問題的能力。

Quake 整體架構設計

Quake 集數(shù)據(jù)構造、壓測隔離、場景管理、動態(tài)調控、過程監(jiān)控、壓測報告為一體，壓測流量盡量模擬真實，具備分布式壓測能力的全鏈路壓測系統(tǒng)，通過模擬海量用戶真實的業(yè)務操作場景，提前對業(yè)務進行高壓力測試，全方位探測業(yè)務應用的性能瓶頸，確保平穩(wěn)地應對業(yè)務峰值。

架構圖：

Quake 整體架構上分為：

• Quake-Web：壓測管理端，負責壓測數(shù)據(jù)構造、壓測環(huán)境準備、場景管理、壓測過程的動態(tài)調整以及壓測報表展示等。
• Quake-Brain：調度中心，負責施壓資源的調度、任務分發(fā)與機器資源管理。
• Quake-Agent：壓測引擎，負責模擬各種壓測流量。
• Quake-Monitor：監(jiān)控模塊，統(tǒng)計壓測結果，監(jiān)控服務各項指標。

管理端核心功能

數(shù)據(jù)構造

傳統(tǒng)的數(shù)據(jù)構造，一般由測試人員自己維護一批壓測數(shù)據(jù)。但這種方式存在很大的弊端，一方面維護成本相對較高，另一方面，其構造出的數(shù)據(jù)多樣性也不足夠。在真實業(yè)務場景中，我們需要的是能直接回放業(yè)務高峰期產生的流量，只有面對這樣的流量沖擊，才能真實的反映系統(tǒng)可能會產生的問題。

Quake 主要提供了 HTTP 和 RPC 的兩種數(shù)據(jù)構造方式：

HTTP 服務的訪問日志收集

對于 HTTP 服務，在 Nginx 層都會產生請求的訪問日志，我們對這些日志進行了統(tǒng)一接入，變成符合壓測需要的流量數(shù)據(jù)。架構圖如下：

S3為最終日志存儲平臺

底層使用了 Hive 作為數(shù)倉的工具，使業(yè)務在平臺上可以通過簡單的類 SQL 語言進行數(shù)據(jù)構造。Quake 會從數(shù)倉中篩選出相應的數(shù)據(jù)，作為壓測所需的詞表文件，將其存儲在 S3 中。

詞表：壓測所需的元數(shù)據(jù)，每一行代表一個請求，包含請求的 method、path、params、header、body等等。

RPC 線上流量實時錄制

對于 RPC 服務，服務調用量遠超 HTTP 的量級，所以在線上環(huán)境不太可能去記錄相應的日志。這里我們使用對線上服務進行實時流量錄制，結合 RPC 框架提供的錄制功能，對集群中的某幾臺機器開啟錄制，根據(jù)要錄制的接口和方法名，將請求數(shù)據(jù)上報到錄制流量的緩沖服務（Broker）中，再由 Broker 生成最終的壓測詞表，上傳到存儲平臺（S3）。

• RPC Client：服務的調用方
• Server：服務提供方
• Broker：錄制后流量緩沖服務器
• S3：流量最終存儲平臺

其他優(yōu)化：

流量參數(shù)偏移

有些場景下，構造出來的流量是不能直接使用的，我們需要對用戶 ID、手機號等信息進行數(shù)據(jù)偏移。Quake 也是提供了包含四則運算、區(qū)間限定、隨機數(shù)、時間類型等多種替換規(guī)則。

詞表文件的分片

數(shù)據(jù)構造產生的詞表文件，我們需要進行物理上的分片，以保證每個分片文件大小盡可能均勻，并且控制在一定大小之內。這么做的主要原因是，后續(xù)壓測肯定是由一個分布式的壓測集群進行流量的打入，考慮到單機拉取詞表的速度和加載詞表的大小限制，如果將詞表進行分片的話，可以有助于任務調度更合理的進行分配。

壓測隔離

做線上壓測與線下壓測最大不同在于，線上壓測要保證壓測行為安全且可控，不會影響用戶的正常使用，并且不會對線上環(huán)境造成任何的數(shù)據(jù)污染。要做到這一點，首要解決的是壓測流量的識別與透傳問題。有了壓測標識后，各服務與中間件就可以依據(jù)標識來進行壓測服務分組與影子表方案的實施。

測試標識透傳

對于單服務來說，識別壓測流量很容易，只要在請求頭中加個特殊的壓測標識即可，HTTP 和 RPC 服務是一樣的。但是，要在整條完整的調用鏈路中要始終保持壓測標識，這件事就非常困難。

跨線程間的透傳：

對于涉及多線程調用的服務來說，要保證測試標識在跨線程的情況下不丟失。這里以 Java 應用為例，主線程根據(jù)壓測請求，將測試標識寫入當前線程的 ThreadLocal 對象中（ThreadLocal 會為每個線程創(chuàng)建一個副本，用來保存線程自身的副本變量），利用 InheritableThreadLocal 的特性，對于父線程 ThreadLocal 中的變量會傳遞給子線程，保證了壓測標識的傳遞。而對于采用線程池的情況，同樣對線程池進行了封裝，在往線程池中添加線程任務時，額外保存了 ThreadLocal 中的變量，執(zhí)行任務時再進行替換 ThreadLocal 中的變量。

跨服務間的透傳：

對于跨服務的調用，架構團隊對所有涉及到的中間件進行了一一改造。利用 Mtrace （公司內部統(tǒng)一的分布式會話跟蹤系統(tǒng)）的服務間傳遞上下文特性，在原有傳輸上下文的基礎上，添加了測試標識的屬性，以保證傳輸中始終帶著測試標識。下圖是 Mtrace 上下游調用的關系圖：

鏈路診斷

由于鏈路關系的復雜性，一次壓測涉及的鏈路可能非常復雜。很多時候，我們很難確認間接依賴的服務又依賴了哪些服務，而任何一個環(huán)節(jié)只要出現(xiàn)問題，比如某個中間件版本不達標，測試標識就不會再往下進行透傳。Quake 提供了鏈路匹配分析的能力，通過平臺試探性地發(fā)送業(yè)務實際需要壓測的請求，根據(jù) Mtrace提供的數(shù)據(jù)，幫助業(yè)務快速定位到標記透傳失敗的服務節(jié)點。

鏈路診斷總覽

鏈路診斷詳情定位

壓測服務隔離

一些大型的壓測通常選擇在深夜低峰時期進行，建議相關的人員要時刻關注各自負責的系統(tǒng)指標，以免影響線上的正常使用。而對于一些日常化的壓測，Quake 提供了更加安全便捷的方式進行。在低峰期，機器基本都是處于比較空閑的狀態(tài)。我們將根據(jù)業(yè)務的需求在線上對整條鏈路快速創(chuàng)建一個壓測分組，隔出一批空閑的機器用于壓測。將正常流量與測試流量在機器級別進行隔離，從而降低壓測對服務集群帶來的影響。

依賴標識透傳的機制，在 Quake 平臺上提供了基于 IP、機器數(shù)、百分比不同方式的隔離策略，業(yè)務只需提供所需隔離的服務名，由 Quake 進行一鍵化的開啟與關閉。

壓測數(shù)據(jù)隔離

還有一個比較棘手的問題是針對寫請求的壓測，因為它會向真實的數(shù)據(jù)庫中寫入大量的臟數(shù)據(jù)。我們借鑒了阿里最早提出的“影子表”隔離的方案。“影子表”的核心思想是，使用線上同一個數(shù)據(jù)庫，包括共享數(shù)據(jù)庫中的內存資源，因為這樣才能更接近真實場景，只是在寫入數(shù)據(jù)時會寫在了另一張“影子表”中。

對于 KV 存儲，也是類似的思路。這里講一下 MQ（消息隊列）的實現(xiàn)，MQ 包括生產和消費兩端，業(yè)務可以根據(jù)實際的需要選擇在生產端忽略帶測試標識的消息，或者在消費端接收消息后再忽略兩種選擇。

調度中心核心設計

調度中心作為整個壓測系統(tǒng)的大腦，它管理了所有的壓測任務和壓測引擎。基于自身的調度算法，調度中心將每個壓測任務拆分成若干個可在單臺壓測引擎上執(zhí)行的計劃，并將計劃以指令的方式下發(fā)給不同的引擎，從而執(zhí)行壓測任務。

資源計算

不同的壓測場景，需要的機器資源不一樣。以 HTTP 服務為例，在請求/響應體都在 1K 以內，響應時間在 50ms 以內和 1s 左右的兩個請求，單個施壓機能達到的極限值完全不同。影響壓測能力的因素有很多，計算中心會依據(jù)壓測模型的不同參數(shù)，進行資源的計算。

主要參考的數(shù)據(jù)包括：

• 壓測期望到達的 QPS。
• 壓測請求的平均響應時間和請求/響應體大小。
• 壓測的詞表大小、分片數(shù)。
• 壓測類型。
• 所需壓測的機房。

事件注入機制

因為整個壓測過程一直處在動態(tài)變化之中，業(yè)務會根據(jù)系統(tǒng)的實際情況對壓力進行相應的調整。在整個過程中產生的事件類型比較多，包括調整 QPS 的事件、觸發(fā)熔斷的事件、開啟事故注入、開啟代碼級性能分析的事件等等，同時觸發(fā)事件的情況也有很多種，包括用戶手動觸發(fā)、由于系統(tǒng)保護機制觸等等。所以，我們在架構上也做了相應的優(yōu)化，其大致架構如下：

在代碼設計層面，我們采用了觀察者和責任鏈模式，將會觸發(fā)事件的具體情況作為觀察主題，主題的訂閱者會視情況類型產生一連串執(zhí)行事件。而在執(zhí)行事件中又引入責任鏈模式，將各自的處理邏輯進行有效的拆分，以便后期進行維護和能力擴充。

機器管理

調度中心管理了所有的施壓機資源，這些施壓機分布在北京、上海的多個機房，施壓機采用容器化方式進行部署，為后續(xù)的動態(tài)擴容、施壓機灰度升級以及異常摘除的提供了基礎保障。

動態(tài)擴容

業(yè)務對壓測的需求有高低峰之分，所以平臺也需要事先部署一部分機器用于日常的業(yè)務壓測。當業(yè)務申請資源不足時，平臺會按需通過容器化方式動態(tài)的進行擴容。這樣做的好處，一方面是節(jié)省機器資源，另一方面就是便于升級。不難想象，升級50臺機器相對升級200臺機器，前者付出的代價肯定更小一些。

灰度升級

整個機器池維護著幾百臺機器，如果需要對這些機器進行升級操作，難度系數(shù)也比較高。我們以前的做法是，在沒有業(yè)務壓測的時候，將機器全部下線，然后再批量部署，整個升級過程既耗時又痛苦。為此，我們引入了灰度升級的概念，對每臺施壓機提供了版本的概念，機器選擇時，優(yōu)先使用穩(wěn)定版的機器。根據(jù)機器目前使用的狀態(tài)，分批替換未使用的機器，待新版本的機器跑完基準和回歸測試后，將機器選擇的策略改為最新版。通過這種方式，我們可以讓整個升級過程，相對平順、穩(wěn)定，且能夠讓業(yè)務無感知。

異常摘除

調度中心維持了與所有施壓機的心跳檢測，對于異常節(jié)點提供了摘除替換的能力。機器摘除能力在壓測過程中非常有必要，因為壓測期間，我們需要保證所有的機器行為可控。不然在需要降低壓力或停止壓測時，如果施壓機不能正常做出響應，其導致的后果將會非常嚴重。

壓測引擎優(yōu)化

在壓測引擎的選擇上，Quake 選擇了自研壓測引擎。這也是出于擴展性和性能層面的考慮，特別在擴展性層面，主要是對各種協(xié)議的支持，這里不展開進行闡述。性能方面，為了保證引擎每秒能產生足夠多的請求，我們對引擎做了很多性能優(yōu)化的工作。

性能問題

通常的壓測引擎，采用的是 BIO 的方式，利用多線程來模擬并發(fā)的用戶數(shù)，每個線程的工作方式是：請求-等待-響應。

通信圖：

這種方式主要的問題是，中間的等待過程，線程資源完全被浪費。這種組合模式下，性能問題也會更嚴重（組合模式：即模擬用戶一連串的用戶行為，以下單為例，請求組中會包含用戶登錄、加入購物車、創(chuàng)建訂單、支付訂單、查看支付狀態(tài)。這些請求彼此間是存在先后關系的，下一個請求會依賴于上一個請求的結果。），若請求組中有5個串聯(lián)請求，每個請求的時長是200ms，那完成一組請求就需要 1s 。這樣的話，單機的最大 QPS 就是能創(chuàng)建的最大線程數(shù)。我們知道機器能創(chuàng)建的線程數(shù)有限，同時線程間頻繁切換也有成本開銷，致使這種通信方式能達到的單機最大 QPS 也很有限。

這種模型第二個問題是，線程數(shù)控制的粒度太粗，如果請求響應很快，僅幾十毫秒，如果增加一個線程，可能 QPS 就上漲了將近100，通過增加線程數(shù)的方式無法精準的控制 QPS，這對探測系統(tǒng)的極限來說，十分危險。

IO 模型優(yōu)化

我們先看下 NIO 的實現(xiàn)機制，從客戶端發(fā)起請求的角度看，存在的 IO 事件分別是建立連接就緒事件（OP_CONNECT）、IO 就緒的可讀事件 （OP_READ） 和 IO 就緒的可寫事件（OP_WRITE），所有 IO 事件會向事件選擇器（Selector）進行注冊，并由它進行統(tǒng)一的監(jiān)聽和處理，Selector 這里采用的是 IO 多路復用的方式。

在了解 NIO 的處理機制后，我們再考慮看如何進行優(yōu)化。整個核心思想就是根據(jù)預設的 QPS，保證每秒發(fā)出指定數(shù)量的請求，再以 IO 非阻塞的方式進行后續(xù)的讀寫操作，取消了 BIO 中請求等待的時間。優(yōu)化后的邏輯如下：

優(yōu)化一：采用 Reactor 多線程模型

這里主要耗時都在 IO 的讀寫事件上，為了達到單位時間內盡可能多的發(fā)起壓測請求，我們將連接事件與讀寫事件分離。連接事件采用單線程 Selector 的方式來處理，讀寫事件分別由多個 Worker 線程處理，每個 Worker 線程也是以 NIO 方式進行處理，由各自的 Selector 處理 IO 事件的讀寫操作。這里每個 Worker 線程都有自己的事件隊列，數(shù)據(jù)彼此隔離，這樣做主要是為了避免數(shù)據(jù)同步帶來的性能開銷。

優(yōu)化二：業(yè)務邏輯與 IO 讀寫事件分離

這里說的業(yè)務邏輯主要是針對請求結果的處理，包括對請求數(shù)據(jù)的采樣上報，對壓測結果的解析校驗，對請求轉換率的匹配等。如果將這些邏輯放在 Worker 線程中處理，必然會影響 IO 讀取的速度。因為 Selector 在監(jiān)聽到 IO 就緒事件后，會進行單線程處理，所以它的處理要盡可能的簡單和快速，不然會影響其他就緒事件的處理，甚至造成隊列積壓和內存問題。

內存優(yōu)化

壓測引擎另一個重要的指標是 Full GC 的時間，因為如果引擎頻繁出現(xiàn) Full GC，那會造成實際壓測曲線（QPS）的抖動，這種抖動會放大被壓服務真實的響應時間，造成真實 QPS 在預設值的上下波動。嚴重的情況，如果是長時間出現(xiàn) Full GC，直接就導致預壓的 QPS 壓不上去的問題。

下面看一組 Full GC 產生的壓測曲線：

為了解決 GC 的問題，主要從應用自身的內存管理和 JVM 參數(shù)兩個維度來進行優(yōu)化。

合理分配內存對象

請求對象加載機制優(yōu)化

引擎首先加載詞表數(shù)據(jù)到內存中，然后根據(jù)詞表數(shù)據(jù)生成請求對象進行發(fā)送。對于詞表數(shù)據(jù)的加載，需要設置一個大小上限，這些數(shù)據(jù)是會進入“老年代”，如果“老年代”占用的比例過高，那就會頻發(fā)出現(xiàn) Full GC 的情況。這里對于詞表數(shù)據(jù)過大的情況，可以考慮采用流式加載的方式，在隊列中維持一定數(shù)量的請求，通過邊回放邊加載的方式來控制內存大小。

請求對象的快用快銷

引擎在實際壓測過程中，假設單機是 1W 的 QPS，那它每秒就會創(chuàng)建 1W 個請求對象，這些對象可能在下一秒處理完后就會進行銷毀。如果銷毀過慢，就會造成大量無效對象晉升老年代，所以在對響應結果的處理中，不要有耗時的操作，保證請求對象的快速釋放。

這里放棄對象復用的原因是，請求的基本信息占用的內存空間比較小。可一旦轉換成了待發(fā)送對象后，占用的內存空間會比原始數(shù)據(jù)大很多，在 HTTP 和 RPC 服務中都存在同樣的問題。而且之前使用 Apache HttpAsyncClient 作為 HTTP 請求的異步框架時，發(fā)現(xiàn)實際請求的 Response 對象掛在請求對象身上。也就是說一個請求對象在接收到結果后，該對象內存增加了響應結果的空間占用，如果采用復用請求對象的方式，很容易造成內存泄露的問題。

JVM 參數(shù)調優(yōu)

這里以 JVM 的 CMS 收集器為例，對于高并發(fā)的場景，瞬間產生大量的對象，這些對象的存活時間又非常短，我們需要：

• 適當增大新生代的大小，保證新生代有足夠的空間來容納新產生的對象。當然如果老年代設置的過小，會導致頻繁的 Full GC。
• 適當調大新生代向晉升老年代的存活次數(shù)，減少無效對象晉升老年代的機率；同時控制新生代存活區(qū)的大小，如果設置的過小，很容易造成那些無法容納的新生代對象提前晉升。
• 提前觸發(fā)老年代的 Full GC，因為如果等待老年代滿了再開始回收，可能會太晚，這樣很容易造成長時間的 Full GC。一般設在 70% 的安全水位進行回收。而且回收的時候，需要觸發(fā)一次 Young GC，這可以減少重新標記階段應用暫停的時間，另一方面，也防止在回收結束后，有大量無效的對象進入老年代中。
• 設置需要進行內存壓縮整理的 GC 次數(shù)，內存整理，很多時候是造成長時間 GC 的主要原因。因為內存整理是采用 Serial Old 算法，以單線程的方式進行處理，這個過程會非常慢。尤其是在老年代空間不足的情況下，GC 的時間會變得更長。

監(jiān)控模塊

壓測肯定會對線上服務產生一定的影響，特別是一些探測系統(tǒng)極限的壓測，我們需要具備秒級監(jiān)控的能力，以及可靠的熔斷降級機制。

客戶端監(jiān)控

壓測引擎會將每秒的數(shù)據(jù)匯總后上報給監(jiān)控模塊，監(jiān)控模塊基于所有上報來的數(shù)據(jù)進行統(tǒng)計分析。這里的分析需要實時進行處理，這樣才能做到客戶端的秒級監(jiān)控。監(jiān)控的數(shù)據(jù)包括各 TP 線的響應情況、QPS 曲線波動、錯誤率情況以及采樣日志分析等等。

實時 QPS 曲線

錯誤率統(tǒng)計

采樣日志

服務端監(jiān)控

除了通過引擎上報的壓測結果來進行相應的監(jiān)控分析之外，Quake 還集成了公司內部統(tǒng)一的監(jiān)控組件，有監(jiān)控機器指標的 Falcon 系統(tǒng)（小米開源），還有監(jiān)控服務性能的 CAT系統(tǒng)（美團已經(jīng)開源）。Quake 提供了統(tǒng)一的管理配置服務，讓業(yè)務能在 Quake 上方便觀察整個系統(tǒng)的健康狀況。

熔斷保護機制

Quake 提供了客戶端和服務端兩方面的熔斷保護措施。

首先是客戶端熔斷，根據(jù)業(yè)務自定義的熔斷闕值，Quake 會實時分析監(jiān)控數(shù)據(jù)，當達到熔斷闕值時，任務調度器會向壓測引擎發(fā)送降低 QPS 或者直接中斷壓測的指令，防止系統(tǒng)被壓掛。

被壓服務同樣也提供了熔斷機制，Quake 集成了公司內部的熔斷組件（Rhino），提供了壓測過程中的熔斷降級和限流能力。與此同時，Quake 還提供了壓測故障演練的能力，在壓測過程中進行人為的故障注入，來驗證整個系統(tǒng)的降級預案。

項目總結

最后，總結一下做 Quake 這個項目的一些心得。

小步快跑

其實在 Quake 出來之前，美團公司內部已有一個壓測平臺（Ptest ），它的定位是針對單服務的性能壓測。我們分析了 Ptest 平臺存在的一些問題，其壓測引擎能力也非常有限。在美團發(fā)展早期，如果有兩個大業(yè)務線要進行壓測的話，機器資源往往會不足，這需要業(yè)務方彼此協(xié)調。因為準備一次壓測，前期投入成本太高，用戶需要自己構造詞表，尤其是 RPC 服務，用戶還需要自己上傳 IDL 文件等等，非常繁瑣。

Quake 針對業(yè)務的這些痛點，整個團隊大概花費一個多月的時間開發(fā)出了第一個版本，并且快速實現(xiàn)了上線。當時，正面臨貓眼十一節(jié)前的一次壓測，那也是 Quake 的第一次亮相，而且取得了不錯的成績。后續(xù)，我們基本平均兩周實現(xiàn)一次迭代，然后逐步加入了機器隔離、影子表隔離、數(shù)據(jù)偏移規(guī)則、熔斷保護機制、代碼級別的性能分析等功能。

快速響應

項目剛線上時，客服面臨問題非常多，不僅有使用層面的問題，系統(tǒng)自身也存在一些 Bug 缺陷。當時，一旦遇到業(yè)務線大規(guī)模的壓測，我們團隊都是全員待命，直接在現(xiàn)場解決問題。后續(xù)系統(tǒng)穩(wěn)定后，我們組內采用了客服輪班制度，每個迭代由一位同學專門負責客服工作，保障當業(yè)務遇到的問題能夠做到快速響應。尤其是在項目上線初期，這點非常有必要。如果業(yè)務部門使用體驗欠佳，項目口碑也會變差，就會對后續(xù)的推廣造成很大的問題。

項目推廣

這應該是所有內部項目都會遇到的問題，很多時候，推廣成果決定項目的生死。前期我們先在一些比較有代表性的業(yè)務線進行試點。如果在試點過程中遇到的問題，或者業(yè)務同學提供的一些好的想法和建議，我們能夠快速地進行迭代與落地。然后再不斷地擴大試點范圍，包括美團外賣、貓眼、酒旅、金融等幾個大的 BG 都在 Quake 上進行了幾輪全流程、大規(guī)模的全鏈路壓測。

隨著 Quake 整體功能趨于完善，同時解決了 Ptest（先前的壓測系統(tǒng)）上的多個痛點，我們逐步在各個業(yè)務線進行了全面推廣和內部培訓。從目前收集的數(shù)據(jù)看，美團超過 90% 的業(yè)務已從 Ptest 遷移到了 Quake 。而且整體的統(tǒng)計數(shù)據(jù)，也比 Ptest 有了明顯的提升。

開放生態(tài)

Quake 目標是打造全鏈路的壓測平臺，但是在平臺建設這件事上，我們并沒有刻意去追求。公司內部也有部分團隊走的比較靠前，他們也做一些很多“試水性”的工作。這其實也是一件好事，如果所有事情都依托平臺來完成，就會面臨做不完的需求，而且很多事情放在平臺層面，也可能無解。

同時，Quake 也提供了很多 API 供其他平臺進行接入，一些業(yè)務高度定制化的工作，就由業(yè)務平臺獨自去完成。平臺僅提供基礎的能力和數(shù)據(jù)支持，我們團隊把核心精力聚焦在對平臺發(fā)展更有價值的事情上。

跨團隊合作

其實，全鏈路壓測整個項目涉及的團隊非常之多，上述提到的很多組件都需要架構團隊的支持。在跨團隊的合作層面，我們應該有“雙贏”的心態(tài)。像 Quake 平臺使用的很多監(jiān)控組件、熔斷組件以及性能分析工具，有一些也是兄弟團隊剛線上沒多久的產品。 Quake 將其集成到平臺中，一方面是減少自身重復造輪子；另一方面也可以幫助兄弟團隊推動產品的研發(fā)工作。

作者簡介

• 耿杰，美團點評高級工程師。2017年加入美團點評，先后負責全鏈路壓測項目和 MagicDB 數(shù)據(jù)庫代理項目，目前主要負責這兩個項目的整體研發(fā)和推廣工作，致力于提升公司的整體研發(fā)效率與研發(fā)質量。

招聘

團隊長期招聘 Java、Go、算法、AI 等技術方向的工程師，Base 北京、上海，歡迎有興趣的同學投遞簡歷到gengjie02@meituan.com。

總結

以上是生活随笔為你收集整理的全链路压测平台（Quake）在美团中的实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。