彈性伸縮具有應突發、省成本、自動化的業務價值。平臺側將各業務零散、閒置資源進行整合，形成一個大規模資源池，通過彈性調度、庫存管控技術在公司運營成本和業務體感中尋求較好的平衡。本文將介紹美團彈性伸縮系統落地過程中面臨的技術挑戰、推廣以及在運營層面的一些思考。在美團這種多樣化的業務場景中落地彈性伸縮，與業界公有云、自建私有云的公司相比，既有共性又有自己的特點，希望能爲大家提供新的思路或者啓發。
前言
穩定、高效、可靠的基礎設施是互聯網企業應對業務高峯流量的底層基石。作爲美團統一的基礎技術平臺，基礎技術部一直致力於通過業內前沿技術的落地，保障公司內部所有業務在線生產系統所依賴的基礎技術平臺能穩定、安全、低成本、可持續地運行與發展。
彈性伸縮系統是基於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架構圖。
自左向右、自上而下進行模塊介紹：
- 用戶端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，負責彈性伸縮的監控告警、運營治理等工作。
二、挑戰與應對之策
在介紹前，有必要重點說明下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 應急資源保障
業務場景：風控反爬服務，是公司業務的服務安全盾和數據安全盾。目前，已有上百個業務方接入反爬服務，每天處理百億級重點流量，爲各大業務方防控惡意流量，保障業務穩定、數據安全及統計數據的正確性。風控反爬相關服務，活動節假日期間，服務負載會受業務影響增長明顯，需要活動節假日期間補充大量資源。
如何使用彈性策略：活動節假日期間，風控反爬業務，申請彈性應急資源（採購公有云宿主機），提升活動期間彈性擴容總量，提升服務穩定性。活動節假日過後，縮容應急資源，騰退公有云宿主機，節約資源。
接入效果：爲風控業務支持了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的設計理念，爲雲原生業務場景的彈性伸縮做技術儲備。
作者簡介
塗揚，現任基礎架構部彈性策略團隊負責人。
招聘信息
閱讀美團技術團隊更多技術文章合集
前端 | 算法 | 後端 | 數據 | 安全 | 運維 | iOS | Android | 測試
| 在公衆號菜單欄對話框回覆【2020年貨】、【2019年貨】、【2018年貨】、【2017年貨】等關鍵詞，可查看美團技術團隊歷年技術文章合集。
