美團彈性伸縮系統的技術演進與落地實踐

彈性伸縮具有應突發、省成本、自動化的業務價值。平台側将各業務零散、閑置資源進行整合，形成一個大規模資源池，通過彈性排程、庫存管控技術在公司營運成本和業務體感中尋求較好的平衡。

本文将介紹美團彈性伸縮系統落地過程中面臨的技術挑戰、推廣以及在營運層面的一些思考。在美團這種多樣化的業務場景中落地彈性伸縮，與業界公有雲、自建私有雲的公司相比，既有共性又有自己的特點，希望能為大家提供新的思路或者啟發。

• 前言
• 一、彈性伸縮系統演進
• 二、挑戰與應對之策
• • 2.1 技術挑戰
  • 2.2 推廣思路
  • 2.3 營運難題
• 三、業務賦能場景
• • 3.1 節假日擴縮容
  • 3.2 日常高峰期擴容
  • 3.3 應急資源保障
  • 3.4 服務鍊路擴縮容
• 四、彈性伸縮未來規劃
• 作者簡介
• 招聘資訊

前言

穩定、高效、可靠的基礎設施是網際網路企業應對業務高峰流量的底層基石。作為美團統一的基礎技術平台，基礎技術部一直緻力于通過業内前沿技術的落地，保障公司内部所有業務線上生産系統所依賴的基礎技術平台能穩定、安全、低成本、可持續地運作與發展。

彈性伸縮系統是基于Docker開發的自動彈性伸縮平台，在美團經曆了多年的發展。

早在2016年，美團就線上上環境中嘗試使用容器環境，推出了基于OpenStack的容器叢集平台Hulk 1.0。随着容器的落地，彈性伸縮1.0版本應運而生，它解決了擴容執行個體慢、擴容上線慢、資源回收慢、計算資源備援等問題。

結合前兩年的探索和實踐以及業界相關領域技術的成熟度，2018年至今，我們對容器叢集平台進行了一次自底向上的的整體更新，也就是現在的Hulk 2.0平台。在底層，Hulk 2.0建設了自研的作業系統、容器引擎，并将OpenStack替換成了容器編排的事實标準Kubernetes；在上層彈性伸縮系統PaaS層面，推出了彈性伸縮系統2.0，解決了彈性伸縮1.0實踐過程中面臨的很多業務痛點，包括：

• 擴出的業務代碼版本不一緻：導緻業務邏輯異常，造成資損。
• 部分服務高峰期資源不足：導緻業務無法有效承載流量，引起資損，
• 平台維護成本高：北京、上海的業務各自一套彈性伸縮使用者端管理平台、彈性邏輯（因為美團、大衆點評合并前期，服務治理架構、CMDB系統、釋出系統尚未标準化）。
• 配置使用靈活性低：業務叢集每增/減一個IDC均需在平台做相比對的配置操作，在資源的調控上無法和公司的流量排程體系包括單元化架構、同地域、同中心調用有效地進行比對。

一、彈性伸縮系統演進

彈性伸縮1.0架構

我們首先看一下，産品演進路線和彈性伸縮1.0架構圖。

産品演進路線

彈性伸縮1.0架構

自左向右、自上而下進行子產品介紹：

• 使用者端Portal：OCTO管理端，OCTO是美團服務治理平台，出于北京業務操作服務節點習慣的考慮，在其上開發了對應的彈性伸縮管理頁面；TTT管理端，TTT是上海側（原大衆點評側）的CMDB管理平台，出于上海側業務操作服務節點習慣的考慮，我們在其上開發了對應的彈性伸縮管理頁面。
• Hulk-ApiServer：Hulk 1.0容器平台的網關服務。
• Hulk-Policy：彈性伸縮系統1.0的業務邏輯子產品，其中涵蓋了具體的名額聚合、擴縮容邏輯、政策等，主從架構模式，使用Zookeeper進行Master選舉，從是冷備。
• Hulk資料源：OCTO，美團服務治理平台；CAT，美團服務端、移動端監控平台，主要負責應用層面；Falcon，基于開源Falcon定制化的系統監控平台，主要負責機器層面。
• Scheduler：Hulk 1.0容器平台的排程系統，基于OpenStack做了二次開發。

彈性伸縮2.0架構

彈性伸縮系統2.0主要在以下四個方面進行了架構演進：

1）排程系統-替換：将OpenStack替換成了容器編排的事實标準Kubernetes，并且在常駐資源池的基礎上，新托管了專區資源池以及應急資源池。 

2）單體服務-微服務化。

a. API-Server：彈性伸縮-網關服務。

b. Engine：彈性伸縮-引擎，負責各服務執行個體擴縮的發起、終止，主從架構模式，使用Zookeeper進行Master選舉，從是熱備。

c. Metrics-Server、Metrics-Data：【新增】彈性伸縮名額服務，負責Raptor、OCTO等資料源的采集&聚合。

d. Resource-Server：【新增】彈性伸縮-庫存管控服務，為各服務自動擴縮的資源需求保駕護航。 

3）服務畫像-資料平台化：Portrait-Server、Portrait-Data，彈性伸縮系統内部自建的服務畫像資料體系。 

4）可觀測性：【新增】Alarm、Scanner，負責彈性伸縮的監控告警、營運治理等工作。

彈性伸縮2.0架構

二、挑戰與應對之策

在介紹前，有必要重點說明下2018年這個時間節點。如前言中所述，2018年以前彈性伸縮1.0這個PaaS平台存在的一些問題，以及整體Hulk 1.0容器平台落地過程中遇到的一些問題，在産品戰略上我們提出了Hulk 2.0的計劃，它涵蓋排程系統、容器引擎、核心隔離增強、彈性伸縮增強等領域；在戰術上，遵循自頂向下的設計原則、自底向上的實施原則。

在2018年4月前比較長的一段時間内，Hulk容器平台的研發主要聚焦在底層系統的更新上（優先打通Hulk 2.0容器編排Kubernetes、容器建立/銷毀的流程），在彈性伸縮PaaS平台的投入約為0.5個人力，增量業務停止接入，存量業務繼續維護。在Hulk 2.0底層系統基本成型後，容器平台團隊一方面開始着手将未接入彈性伸縮平台的Hulk 1.0容器平滑遷移至Hulk 2.0容器。另外一方面，開始着手組建人力建設可對接Hulk 2.0容器平台編排能力的彈性伸縮2.0系統，為已接入彈性伸縮平台的Hulk 1.0容器平滑遷移過來做技術儲備。

在彈性伸縮2.0系統的演進過程中遵循“技術”、“推廣”、“營運”的演進政策。我們可以先來看下在搭建平台的過程中面臨的一些挑戰以及解法。

2.1 技術挑戰

結合當下彈性伸縮系統面臨的處境，并對業界彈性伸縮産品做過一番調研後，在平台搭建上确定了如下三期目标：

• 一期目标：彈性伸縮2.0系統MVP版本，簡單來說是把底層OpenStack相關生态更換成Kubernetes周邊生态，上層功能先維持不變。
• 二期目标：業務上，找同部門業務先行試點，基于回報，小步快跑，快速疊代；技術上，對北京、上海服務治理平台，CMDB系統等相關業務邏輯進行融合。
• 三期目标：1.0系統的使用者端融合為一套，減少業務側的了解成本、研發側的開發/維護成本。

在上述三期目标基本落地後，彈性伸縮2.0系統基本可以跑起來，處于一個不比彈性伸縮1.0系統差的階段，接下來基于過往運維問題彙總以及業務訪談訴求，在後端架構上做了幾個比較大的更新。

2.1.1 彈性排程

正如前言所述，和大部分彈性伸縮産品類似，早期啟用彈性伸縮的過程如下：

• 建立彈性分組：彈性分組是彈性伸縮管理的基本單元，彈性分組用來管理同質化的業務執行個體，在美團的實踐中，主要是同一個IDC中的執行個體。
• 建立彈性伸縮配置：用于确定擴容出來的彈性伸縮執行個體的機型配置，比如：CPU、記憶體、硬碟大小等。
• 建立彈性伸縮規則：具體來講就是擴容幾台、縮容幾台。
• 建立彈性伸縮任務：監控任務、定時任務。

在美團的落地場景中，我們遇到如下問題：

• 該擴未擴，業務叢集新部署一個IDC的執行個體時，不容易聯想到需要給這個IDC執行個體建立彈性分組，導緻的問題是高峰期其他IDC可正常擴容，這個IDC無法正常擴容。
• 不該擴卻擴，業務叢集不再使用某個IDC後，未聯想到需要關停這個彈性分組，導緻的問題是一些定時任務依舊擴容出這個IDC的執行個體，部分情況下會引發業務異常。
• IDC視角的擴縮局限性，未站在“上帝視角”做擴縮容決策，會導緻部分IDC資源緊缺時，比較難以Fail-Fast。
• 業務在不同IDC的業務邏輯不一緻，部分業務把具體的政策耦合在業務邏輯中，一個業務叢集使用一套鏡像彈性擴容，會引發業務異常。

基于以上種種原因，我們拉通了各PaaS方，梳理了流量分組、彈性分組、釋出分組之間的關系，以保證彈性伸縮在美團私有雲中的擴容準确性。

分組關系圖

• 流量分組：劃分來源于美團服務治理平台-OCTO、SET化平台-大禹，比如這個服務走的是SET化方式（類業界單元化架構），那麼每一個SET就是一個流量分組；依次類推，設定的是無差别調用方式，那麼全局就是一個流量分組；設定的是同地域（Region）調用方式，那麼每個Region就是一個流量分組；設定的是同中心調用方式，那麼每個中心就是一個流量分組；設定的是同IDC優先調用方式，那麼每個IDC就是一個流量分組。
• 彈性分組：無需手動劃分，一個流量分組就對應一個彈性分組，直接Mapping建立即可。
• 釋出分組：劃分來源于美團釋出平台-Plus，對于未采用SET化架構的業務叢集，則僅有一個Default-釋出分組；針對采用SET化架構的叢集，每個SET對應一個SET-釋出分組，它們的代碼/鏡像可以不一樣；基于同一個SET下又可能有多個地域、多個中心、多個IDC（目前美團的SET化架構以同IDC調用為主），是以和流量分組之間是1對N的關系。

同地域通路的方式比較有代表性，這裡對同地域調用&未SET化、同地域調用&SET化的業務叢集自動擴容方式進行展開說明，其他組合可依次類推。

分組明細圖

2.1.2 庫存管控

彈性伸縮系統如果隻是單純地提供一個IaaS資源的自動供給能力，這件事情并不難。然而實際情況下，彈性伸縮系統在落地過程中需要解決資源上面臨的問題。

• 業務關注點：資源如何保障？過往在彈性伸縮系統1.0遇到過多次擴不出資源的情況。
• 組織關注點：彈性資源池該劃分為多大合适？如果儲備大量的資源，卻無法較好的進行分時複用，作為PaaS平台本身會造成資源閑置。

針對業務的這個關注點，目前業界公有雲廠商的做法基本是不做SLA承諾或者說很難做到SLA承諾，是以也自然不會面臨到組織的關注點問題。具體來說，在美團主要是通過以下幾個措施來解決。

2.1.2.1 多租戶管理

資源多租戶圖

平台給到每個業務線的資源并非無限，會給每個業務叢集的彈性分組，設定一個預設的資源Quota。如果業務覺得預設Quota不夠，可通過工單的方式進行一輪評估調整（從實踐來看，絕大部分情況無需調整）。針對這個資源Quota，平台側承諾的SLA：99.9%的擴容成功率。

這裡會有個問題：是不是給業務Quota後，這部分資源就直接劃分給這個業務獨占了？答案：不是的。這隻是一個邏輯上的劃分，資源本身是各業務混用的，平台需控制資源閑置率，本身會做些“超售”，但過程中需解決好“超售”可能面臨的問題，這就是水位線監管機制。

2.1.2.2 常态-資源保障

正常-資源保障，指的是平日、小節假日下的資源供給機制，這部分的資源來源于常駐資源池（架構圖所示），平台會對已接入平台的所有服務，進行小時粒度的資源重預估。具體示意圖如下：

資源保障圖

新增/更新服務的伸縮任務、伸縮規則時，會對目前變更對整體資源池水位的影響進行預估，如果在疊加時間點将超過整體資源池的水位，平台會拒絕執行變更操作，并給到使用者和平台管理者消息推送，使用者可通過工單方式進行資源請求說明（需保障存量服務的資源可靠性）。

庫存&實時用量

庫存&預估用量

2.1.2.3 應急-資源保障

常駐資源池的大小是有限的，應急-資源保障指的是業務拉新、大促、大節假日等非常态的資源供給機制，這部分的資源來源于常駐資源池+應急資源池（如架構圖所示）。應急資源池簡單來說就是，我們按用量計費模式購買的公有雲資源，這是一種更靈活的資源池模式（具備一定的租約）。在此基礎上，我們建構了更省成本的混合雲彈性排程能力（在此之前僅在私有雲的常駐資源池排程）。

• 彈性擴容：常駐資源池執行個體優先占用，應急資源池執行個體次之。
• 彈性縮容：應急資源池執行個體先縮容，常駐資源池執行個體次之。

以下示意圖展示的是一個服務在大促期間（維持T天）需要208台容器執行個體，其中8台為常态下的資源訴求，200台為應急資源訴求。

大促前：

大促後（T+1）：

T+1天後，這些應急資源池将被騰退回公有雲廠商，公司無需為後續繼續付費。多業務都應急的場景其實會偏複雜些；特殊情況下，需要采用重排程、治理。

2.2 推廣思路

在2020年之前，是彈性伸縮2.0系統的練内功階段，并未大規模向業務推廣Hulk 2.0彈性伸縮系統，主要原因歸結為兩方面：

• 公司還處在從虛拟機、Hulk 1.0容器遷移至Hulk 2.0容器階段，Hulk 2.0容器執行個體還處于打磨以及逐漸赢得業務信任的過程中，推廣彈性彈性伸縮2.0系統，容器化是第一步。
• Hulk 2.0系統在基礎功能上不足以滿足相對複雜的業務場景，比如SET化架構的業務。

截止2020年年底，共接入了約500個服務。這裡主要以彈性伸縮1.0系統中平滑遷移過來的服務，同部門的服務（Eat Your Own Dog Food）為主。

在2020年-2021年，是彈性伸縮2.0系統的規模化階段。

• 資料驅動：從數萬個服務中，通過自建的服務畫像資料體系挖掘出數千個美團适合接入彈性伸縮的服務，主要是參考高低峰、是否有狀态、執行個體配置、業務叢集規模等因素，并将其下鑽到各業務部門，共建設30+營運大盤，鎖定了平台側希望去賦能的業務群體。
• 價值量化：這裡面經曆了一些認知疊代的過程，最後提煉出來主要是三方面：“應突發”、“省成本”、“自動化”。
• 深入業務：在前面500多個服務相對比較穩定之後，大概花了兩三個月，和美團的各個業務線負責人去聊，主要圍繞業務介紹（隻有了解它，才有可能為它賦能），彈性伸縮價值介紹（橫向拉通其他業務的最佳實踐），業務今年的OKR是哪幾塊（評估彈性伸縮三方面的價值是否可以幫助業務更好的達成業績、合作共赢），一起讨論目前業務接入後可能看到的收益。
• 技術教育訓練：根據前期深入業務，獲得的回報。業務比較關注技術原理、接入成本、系統健壯性、最佳實踐、有哪些潛在的坑。團隊同學把這些進行了提煉總結，輸出了彈性伸縮白皮書（技術原理、FAQ手冊、最佳實踐等）、避坑指南，并在有需要的業務部門進行VIP式的技術分享，一次不夠、可以來兩次，大大小小的業務團隊、公司級的分享，我們做了十幾二十次。
• 管道閉環：公司層面上要做一些大促活動，如“安心複蘇計劃”、“517吃貨節”、“1001夜直播”，這些活動隻要我們知道了，我們就主動加入進去看看能幫助哪些，從結果來看，效果還是挺好的。我們還在公司的COE系統（故障複盤分析工具）去搜“負載”、“秒殺”、“暴漲”、“擴容”之類的關鍵字，學習問題的處理過程以及待辦事項，評估後發現能幫上的，我們就主動聯系業務去溝通。
• 業務回訪：雖然我們會在技術支援群内會做答疑，且每周會進行值班問題的彙總Review，但相對來說會偏零散些。我們開始是采用問卷調查的方式去擷取回報，但是踐行下來效果比較一般。是以，我們還是采用比較原始的方式——“促膝長談”，我們主動從業務側去拉取接入後遇到的問題，在評估優先級後快速疊代系統本身。

經過以上這些工作，我們80%+的服務接入了彈性，覆寫了公司90%+的業務線。回到那句話，如果彈性伸縮系統隻是單純地提供一個IaaS資源的自動供給能力，這件事情并不難，而我們的定位是PaaS平台。

2.3 營運難題

這部分主要介紹向業務傳遞彈性容器執行個體後，碰到的三類典型問題：配置、啟動、性能。這些問題大部分不是彈性伸縮2.0這個PaaS平台本身領域内可直接閉環解決的事項，這往往取決于各PaaS平台是否已全量标準化、業務自身邏輯、以及基礎設施層性能等因素，催化我們多去做這一步的原因隻有一個：彈性擴容出的執行個體隻有很好的幫助業務分擔負載，才可真正幫助業務解決問題。

2.3.1 配置問題

2.3.2 啟動問題

啟動問題，大部分解決的是容器的這種開箱即用方式所面臨的問題，而非過往的采用先申請機器、再在這上面釋出代碼包的方式。而且這裡面會經常要面臨着業務的質疑，為什麼我手動釋出的時候不存在這個問題，采用彈性擴容就出現了？

2.3.3 性能問題

生産環境中，業務容器的性能問題其實是比較複雜的，可能涉及到重IO容器影響、主控端Load過高、多個容器突發占用CPU過高導緻影響某個業務容器問題。相對于不使用彈性時囤積算力的穩定場景，彈性擴縮容場景中，因對資源的頻繁調配會更容易遇到資源性能的問題。為了保障使用效果，Hulk項目組主要從三個角度對性能問題完整解決：

• 事前：服務粒度配置個性化排程政策。
• 事中：基于服務畫像資料平台提供服務時序特征、主控端時序特征，建設多元度資源打散能力的排程算法。
• 事後：針對存量Node上的重IO、重CPU等容器進行重排程。

三、業務賦能場景

3.1 節假日擴縮容

業務場景：有着明顯的“七節二月”特性，就流量而言周末是工作日的1.5倍左右，節假日流量是周末的3~5倍左右。服務機器基本上是按照節假日的流量部署，平時機器使用率很低。

如何使用彈性伸縮：

• 接入彈性伸縮定時任務，節假日期間彈性擴容，應對節假日流量高峰；非節假日高峰，彈性縮容，減少伺服器資源開銷。
• 任務配置示例：節前配置定時任務擴容；節後配置定時任務縮容；監控擴容任務作為托底。

接入效果：業務側平均節約成本20.4%。

3.2 日常高峰期擴容

業務場景：配送是外賣服務的下遊，具有明顯的午高峰特性。

如何使用彈性伸縮：

• 設定定時任務：在午高峰來臨前擴容出足量的機器，在午高峰結束後縮掉富餘的機器，如示例，分組【global - banner-east - 無swimlane】綁定了2個定時任務，每天09:55擴容125台機器；每天14:00縮容125台機器。

接入效果：接入彈性之前，為應對午高峰流量，該服務需要常駐機器2420台；接入彈性之後常駐機器釋放了365台，高峰期彈性機器占總機器數的15%。

3.3 應急資源保障

業務場景：風控反爬服務，是公司業務的服務安全盾和資料安全盾。目前，已有上百個業務方接入反爬服務，每天處理百億級重點流量，為各大業務方防控惡意流量，保障業務穩定、資料安全及統計資料的正确性。風控反爬相關服務，活動節假日期間，服務負載會受業務影響增長明顯，需要活動節假日期間補充大量資源。

如何使用彈性政策：活動節假日期間，風控反爬業務，申請彈性應急資源（采購公有雲主控端），提升活動期間彈性擴容總量，提升服務穩定性。活動節假日過後，縮容應急資源，騰退公有雲主控端，節約資源。

服務A

服務B

接入效果：為風控業務支援了5次大規模線上活動，基于彈性伸縮的應急-資源保障機制，累計提供公有雲資源700+台高配容器，約7000+CPU資源。

3.4 服務鍊路擴縮容

業務場景：餐飲SaaS采取“火車模型釋出的模式”傳遞功能，需要為70+服務申請專用的灰階鍊路機器，用于雲端功能的灰階驗證。但機器每月僅需使用2~3個工作日，一直持有機器，造成機器資源浪費；最初團隊是通過每月定時手動申請、釋放機器來解決，耗費較大人力，一定程度上影響到了研發的效率。

如何使用彈性政策：

• 配置鍊路拓撲。
• 每月活動開始前，配置鍊路任務，設定：擴縮容時間、機器SET/LiteSet辨別、鍊路服務擴容機器數量。
• 到達設定時間，自動擴容、縮容機器。

接入效果

• 使用前：火車發版涉及70+服務，每月需要70+服務負責人各自在發版前擴容機器，驗證完成後縮容機器。
• 使用後：首次配置鍊路拓撲後，此後每月僅需一名RD同學，統一配置一個鍊路任務，達到預設時間，自動擴、縮容，大大提高效率。

四、彈性伸縮未來規劃

随着彈性伸縮系統2.0在美團的規模化落地，我們未來會從穩定性、易用性、業務解決方案、新技術探索四個方面去做深、做廣：

1）穩定性：基礎服務的穩定性是一切的基石，而這往往是不少研發同學容易忽視的一點，研發同學需“在晴天時修屋頂”。

• 系統自身的健壯性：叢集全鍊路拆分（縮爆炸半徑）、池化、資源QoS保障能力建設。
• 彈性執行個體的穩定性：加強發現能力，持續完善異常檢測工具（差別于正常的健康檢測，會從異構算力的主控端、不同核心參數、各系統名額層面進行綜合決策），自動進行異常執行個體的替換；加強資料營運，提升回報能力，持續協同排程算法進行演進。

2）易用性

• 強化預演模式：可以預測目前的彈性伸縮規則，服務接下來24小時的擴縮是怎麼樣的。這塊我們目前做了個MVP版本，接下來除了會進一步提升使用者觸達率，另外也計劃在使用者端為接入的使用者呈現使用後收益資料。
• 自動任務配置：基于門檻值的配置方式不小程度上取決于工程師經驗，可能會因為工程師過于“年輕”而沒有做正确的配置，導緻一些異常；目前在接入側已經對部分業務放開了任務推薦的功能；計劃基于營運資料進一步打磨工具後，會周期性的自動幫助業務調整配置。

3）業務解決方案

• 鍊路伸縮：目前已經實作了基于鍊路拓撲批量配置、對各服務伸縮規則進行拆分的能力；接下來會将服務與服務之間，服務與中間件、存儲之間的背壓回報作用于彈性決策中。
• 專區彈性伸縮：目前已在金融業務線、美團七層負載均衡服務網關Oceanus中發揮彈性伸縮系統的“應突發”價值，未來計劃為更多有專區場景的業務提供彈性伸縮支援。

4）新技術探索：借鑒Knative、Keda的設計理念，為雲原生業務場景的彈性伸縮做技術儲備。

作者簡介

塗揚，現任基礎架構部彈性政策團隊負責人。

更多幹貨請點選：
【視訊】《華為100張面孔》（三集全）

推薦系統解構.pdf（附下載下傳連結）

GitHub2020年數字洞察報告.pdf（附下載下傳連結）如何建構一個生産環境的推薦系統？美團大腦系列之：商品知識圖譜的建構及應用推薦系統架構與算法流程詳解使用者畫像和精準化平台系統實踐
關注我們
           

省時查報告 專業、及時、全面的行研報告庫

長按并識别關注