全鍊路壓測平台（Quake）在美團中的實踐

總第283篇

2018年 第75篇

背景

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

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

全鍊路壓測是基于線上真實環境和實際業務場景，通過模拟海量的使用者請求，來對整個系統進行壓力測試。早期，我們在沒有全鍊路壓測的情況下，主要的壓測方式有：

• 對線上的單機或叢集發起服務調用。
• 将線上流量進行錄制，然後在單台機器上進行回放。
• 通過修改權重的方式進行引流壓測。

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

• 隻關注涉及的核心系統，無法覆寫到所有的環節。
• 系統之間都是通過一些基礎服務進行串聯，如 Nginx、Redis 緩存、資料庫、磁盤、網絡等等，而基礎服務問題在單機壓測中往往不能被暴露出來。

綜合多種因素考慮，全鍊路壓測是我們準确評估整個系統性能水準的必經之路。截止目前，全鍊路壓測已在外賣、貓眼、酒旅、金融等10多個核心業務線全面投入使用，月平均壓測次數達上萬次，幫助業務平穩地度過了大大小小若幹場高峰流量的沖擊。

解決方案

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

• 提供模拟線上真實流量的能力
  • 壓測和 DDoS 攻擊不同的是，壓測有應用場景，而 DDoS 可能隻需要一個請求。為了更真實的還原使用者行為，我們需要擷取線上的真實流量進行壓測。
• 具備快速建立壓測環境的能力
  • 這裡的環境指的是線上環境，因為如果壓測的是線下環境，即使不考慮“機器配置是否相同”這個因素，像叢集規模、資料庫體量、網絡條件等這些因素，線上下環境下都無法進行模拟，這樣得出壓測結果，其參考價值并不大。
• 支援多種壓測類型
  • 壓測類型除了支援标準的 HTTP 協定，還需要對美團内部的 RPC 和移動端協定進行支援。
• 提供壓測過程的實時監控與過載保護
  • 全鍊路壓測是一個需要實時關注服務狀态的過程，尤其在探測極限的時候，需要具備精準調控 QPS 的能力，秒級監控的能力，預設熔斷降級的能力，以及快速定位問題的能力。

Quake整體架構設計

Quake 集資料構造、壓測隔離、場景管理、動态調控、過程監控、壓測報告為一體，壓測流量盡量模拟真實，具備分布式壓測能力的全鍊路壓測系統，通過模拟海量使用者真實的業務操作場景，提前對業務進行高壓力測試，全方位探測業務應用的性能瓶頸，確定平穩地應對業務峰值。

架構圖

Quake 整體架構上分為：

• Quake-Web：壓測管理端，負責壓測資料構造、壓測環境準備、場景管理、壓測過程的動态調整以及壓測報表展示等。
• Quake-Brain：排程中心，負責施壓資源的排程、任務分發與機器資源管理。
• Quake-Agent：壓測引擎，負責模拟各種壓測流量。
• Quake-Monitor：監控子產品，統計壓測結果，監控服務各項名額。

管理端核心功能

資料構造

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

Quake 主要提供了 HTTP 和 RPC 的兩種資料構造方式：

HTTP 服務的通路日志收集

對于 HTTP 服務，在 Nginx 層都會産生請求的通路日志，我們對這些日志進行了統一接入，變成符合壓測需要的流量資料。架構圖如下：

• S3為最終日志存儲平台

底層使用了 Hive 作為數倉的工具，使業務在平台上可以通過簡單的類 SQL 語言進行資料構造。Quake 會從數倉中篩選出相應的資料，作為壓測所需的詞表檔案，将其存儲在 S3 中。

• 詞表：壓測所需的中繼資料，每一行代表一個請求，包含請求的 method、path、params、header、body等等。

  

RPC 線上流量實時錄制

對于 RPC 服務，服務調用量遠超 HTTP 的量級，是以線上上環境不太可能去記錄相應的日志。這裡我們使用對線上服務進行實時流量錄制，結合 RPC 架構提供的錄制功能，對叢集中的某幾台機器開啟錄制，根據要錄制的接口和方法名，将請求資料上報到錄制流量的緩沖服務（Broker）中，再由 Broker 生成最終的壓測詞表，上傳到存儲平台（S3）。

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

其他優化

• 流量參數偏移

有些場景下，構造出來的流量是不能直接使用的，我們需要對使用者 ID、手機号等資訊進行資料偏移。Quake 也是提供了包含四則運算、區間限定、随機數、時間類型等多種替換規則。

• 詞表檔案的分片

資料構造産生的詞表檔案，我們需要進行實體上的分片，以保證每個分片檔案大小盡可能均勻，并且控制在一定大小之内。這麼做的主要原因是，後續壓測肯定是由一個分布式的壓測叢集進行流量的打入，考慮到單機拉取詞表的速度和加載詞表的大小限制，如果将詞表進行分片的話，可以有助于任務排程更合理的進行配置設定。

壓測隔離

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

測試辨別透傳

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

• 跨線程間的透傳

對于涉及多線程調用的服務來說，要保證測試辨別在跨線程的情況下不丢失。這裡以 Java 應用為例，主線程根據壓測請求，将測試辨別寫入目前線程的 ThreadLocal 對象中（ThreadLocal 會為每個線程建立一個副本，用來儲存線程自身的副本變量），利用 InheritableThreadLocal 的特性，對于父線程 ThreadLocal 中的變量會傳遞給子線程，保證了壓測辨別的傳遞。而對于采用線程池的情況，同樣對線程池進行了封裝，在往線程池中添加線程任務時，額外儲存了 ThreadLocal 中的變量，執行任務時再進行替換 ThreadLocal 中的變量。

• 跨服務間的透傳

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

鍊路診斷

由于鍊路關系的複雜性，一次壓測涉及的鍊路可能非常複雜。很多時候，我們很難确認間接依賴的服務又依賴了哪些服務，而任何一個環節隻要出現問題，比如某個中間件版本不達标，測試辨別就不會再往下進行透傳。Quake 提供了鍊路比對分析的能力，通過平台試探性地發送業務實際需要壓測的請求，根據 Mtrace提供的資料，幫助業務快速定位到标記透傳失敗的服務節點。

• 鍊路診斷總覽

  

• 鍊路診斷詳情定位

壓測服務隔離

一些大型的壓測通常選擇在深夜低峰時期進行，建議相關的人員要時刻關注各自負責的系統名額，以免影響線上的正常使用。而對于一些日常化的壓測，Quake 提供了更加安全便捷的方式進行。在低峰期，機器基本都是處于比較空閑的狀态。我們将根據業務的需求線上上對整條鍊路快速建立一個壓測分組，隔出一批空閑的機器用于壓測。将正常流量與測試流量在機器級别進行隔離，進而降低壓測對服務叢集帶來的影響。

依賴辨別透傳的機制，在 Quake 平台上提供了基于 IP、機器數、百分比不同方式的隔離政策，業務隻需提供所需隔離的服務名，由 Quake 進行一鍵化的開啟與關閉。

壓測資料隔離

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

對于 KV 存儲，也是類似的思路。這裡講一下 MQ（消息隊列）的實作，MQ 包括生産和消費兩端，業務可以根據實際的需要選擇在生産端忽略帶測試辨別的消息，或者在消費端接收消息後再忽略兩種選擇。

排程中心核心設計

排程中心作為整個壓測系統的大腦，它管理了所有的壓測任務和壓測引擎。基于自身的排程算法，排程中心将每個壓測任務拆分成若幹個可在單台壓測引擎上執行的計劃，并将計劃以指令的方式下發給不同的引擎，進而執行壓測任務。

資源計算

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

主要參考的資料包括：

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

事件注入機制

因為整個壓測過程一直處在動态變化之中，業務會根據系統的實際情況對壓力進行相應的調整。在整個過程中産生的事件類型比較多，包括調整 QPS 的事件、觸發熔斷的事件、開啟事故注入、開啟代碼級性能分析的事件等等，同時觸發事件的情況也有很多種，包括使用者手動觸發、由于系統保護機制觸等等。是以，我們在架構上也做了相應的優化，其大緻架構如下：

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

機器管理

排程中心管理了所有的施壓機資源，這些施壓機分布在北京、上海的多個機房，施壓機采用容器化方式進行部署，為後續的動态擴容、施壓機灰階更新以及異常摘除的提供了基礎保障。

• 動态擴容

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

• 灰階更新

整個機器池維護着幾百台機器，如果需要對這些機器進行更新操作，難度系數也比較高。我們以前的做法是，在沒有業務壓測的時候，将機器全部下線，然後再批量部署，整個更新過程既耗時又痛苦。為此，我們引入了灰階更新的概念，對每台施壓機提供了版本的概念，機器選擇時，優先使用穩定版的機器。根據機器目前使用的狀态，分批替換未使用的機器，待新版本的機器跑完基準和回歸測試後，将機器選擇的政策改為最新版。通過這種方式，我們可以讓整個更新過程，相對平順、穩定，且能夠讓業務無感覺。

• 異常摘除

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

壓測引擎優化

在壓測引擎的選擇上，Quake 選擇了自研壓測引擎。這也是出于擴充性和性能層面的考慮，特别在擴充性層面，主要是對各種協定的支援，這裡不展開進行闡述。性能方面，為了保證引擎每秒能産生足夠多的請求，我們對引擎做了很多性能優化的工作。

性能問題

通常的壓測引擎，采用的是 BIO 的方式，利用多線程來模拟并發的使用者數，每個線程的工作方式是：請求-等待-響應。

通信圖：

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

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

IO 模型優化

我們先看下 NIO 的實作機制，從用戶端發起請求的角度看，存在的 IO 事件分别是建立連接配接就緒事件（OP_CONNECT）、IO 就緒的可讀事件 （OP_READ） 和 IO 就緒的可寫事件（OP_WRITE），所有 IO 事件會向事件選擇器（Selector）進行注冊，并由它進行統一的監聽和處理，Selector 這裡采用的是 IO 多路複用的方式。

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

優化一：采用 Reactor 多線程模型

這裡主要耗時都在 IO 的讀寫事件上，為了達到機關時間内盡可能多的發起壓測請求，我們将連接配接事件與讀寫事件分離。連接配接事件采用單線程 Selector 的方式來處理，讀寫事件分别由多個 Worker 線程處理，每個 Worker 線程也是以 NIO 方式進行處理，由各自的 Selector 處理 IO 事件的讀寫操作。這裡每個 Worker 線程都有自己的事件隊列，資料彼此隔離，這樣做主要是為了避免資料同步帶來的性能開銷。

優化二：業務邏輯與 IO 讀寫事件分離

這裡說的業務邏輯主要是針對請求結果的處理，包括對請求資料的采樣上報，對壓測結果的解析校驗，對請求轉換率的比對等。如果将這些邏輯放在 Worker 線程中處理，必然會影響 IO 讀取的速度。因為 Selector 在監聽到 IO 就緒事件後，會進行單線程處理，是以它的處理要盡可能的簡單和快速，不然會影響其他就緒事件的處理，甚至造成隊列積壓和記憶體問題。

記憶體優化

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

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

為了解決 GC 的問題，主要從應用自身的記憶體管理和 JVM 參數兩個次元來進行優化。

合理配置設定記憶體對象

• 請求對象加載機制優化

引擎首先加載詞表資料到記憶體中，然後根據詞表資料生成請求對象進行發送。對于詞表資料的加載，需要設定一個大小上限，這些資料是會進入“老年代”，如果“老年代”占用的比例過高，那就會頻發出現 Full GC 的情況。這裡對于詞表資料過大的情況，可以考慮采用流式加載的方式，在隊列中維持一定數量的請求，通過邊回放邊加載的方式來控制記憶體大小。

• 請求對象的快用快銷

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

這裡放棄對象複用的原因是，請求的基本資訊占用的記憶體空間比較小。可一旦轉換成了待發送對象後，占用的記憶體空間會比原始資料大很多，在 HTTP 和 RPC 服務中都存在同樣的問題。而且之前使用 Apache HttpAsyncClient 作為 HTTP 請求的異步架構時，發現實際請求的 Response 對象挂在請求對象身上。也就是說一個請求對象在接收到結果後，該對象記憶體上增加響應結果的大小空間，如果采用複用請求對象的方式，很容易造成記憶體洩露的問題。

JVM 參數調優

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

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

監控子產品

壓測肯定會對線上服務産生一定的影響，特别是一些探測系統極限的壓測，我們需要具備秒級監控的能力，以及可靠的熔斷降級機制。

用戶端監控

壓測引擎會将每秒的資料彙總後上報給監控子產品，監控子產品基于所有上報來的資料進行統計分析。這裡的分析需要實時進行處理，這樣才能做到用戶端的秒級監控。監控的資料包括各 TP 線的響應情況、QPS 曲線波動、錯誤率情況以及采樣日志分析等等。

• 實時 QPS 曲線

• 錯誤率統計

采樣日志

服務端監控

除了通過引擎上報的壓測結果來進行相應的監控分析之外，Quake 還內建了公司内部統一的監控元件，有監控機器名額的 Falcon 系統（小米開源），還有監控服務性能的 CAT系統（美團已經開源）。Quake 提供了統一的管理配置服務，讓業務能在 Quake 上友善觀察整個系統的健康狀況。

熔斷保護機制

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

首先是用戶端熔斷，根據業務自定義的熔斷阙值，Quake 會實時分析監控資料，當達到熔斷阙值時，任務排程器會向壓測引擎發送降低 QPS 或者直接中斷壓測的指令，防止系統被壓挂。

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

項目總結

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

小步快跑

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

Quake 針對業務的這些痛點，整個團隊大概花費一個多月的時間開發出了第一個版本，并且快速實作了上線。當時，正面臨貓眼十一節前的一次壓測，那也是 Quake 的第一次亮相，而且取得了不錯的成績。後續，我們基本平均兩周實作一次疊代，然後逐漸加入了機器隔離、影子表隔離、資料偏移規則、熔斷保護機制、代碼級别的性能分析等功能。

快速響應

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

項目推廣

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

随着 Quake 整體功能趨于完善，同時解決了 Ptest（先前的壓測系統）上的多個痛點，我們逐漸在各個業務線進行了全面推廣和内部教育訓練。從目前收集的資料看，美團超過 90% 的業務已從 Ptest 遷移到了 Quake 。而且整體的統計資料，也比 Ptest 有了明顯的提升。

開放生态

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

同時，Quake 也提供了很多 API 供其他平台進行接入，一些業務高度定制化的工作，就由業務平台獨自去完成。平台僅提供基礎的能力和資料支援，我們團隊把核心精力聚焦在對平台發展更有價值的事情上。

跨團隊合作

其實，全鍊路壓測整個項目涉及的團隊非常之多，上述提到的很多元件都需要架構團隊的支援。在跨團隊的合作層面，我們應該有“雙赢”的心态。像 Quake 平台使用的很多監控元件、熔斷元件以及性能分析工具，有一些也是兄弟團隊剛線上沒多久的産品。 Quake 将其內建到平台中，一方面是減少自身重複造輪子；另一方面也可以幫助兄弟團隊推動産品的研發工作。

作者簡介

耿傑，美團點評進階工程師。2017年加入美團點評，先後負責全鍊路壓測項目和 MagicDB 資料庫代理項目。目前主要負責這兩個項目的整體研發和推廣工作，緻力于提升公司的整體研發效率與研發品質。

歡迎加入美團基礎架構技術交流群，跟作者零距離交流。請加美美同學的微信（微信号：MTDPtech01），回複：基礎架構，美美會自動拉你進群。

----------  END  ----------

招聘資訊

美團基礎研發平台長期招聘 Java、Go、算法、AI 等技術方向的工程師，Base 北京、上海，歡迎有興趣的同學投遞履歷到[email protected]。

也許你還想看

深度剖析開源分布式監控CAT

Leaf——美團點評分布式ID生成系統