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

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

以下文章來源於美團技術團隊 ，作者塗揚

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

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

• 前言

• 一、彈性伸縮系統演進

• 二、挑戰與應對之策

• 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 的設計理念，爲雲原生業務場景的彈性伸縮做技術儲備。

作者簡介

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

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/xIusjUtr3Oxk7LjGIDZwBg