作者 | 譚霖

本文介紹了美團在如何解決大規(guī)模集群管理的難題、設計優(yōu)秀且合理的集群調(diào)度系統(tǒng)方面的實踐，闡述了美團在落地以Kubernetes為代表的云原生技術時，比較關心的問題、挑戰(zhàn)以及對應的推進策略。同時本文也介紹了針對美團業(yè)務需求場景做的一些特色支持，希望本文能夠?qū)υ圃I域感興趣的同學有所幫助或者啟發(fā)。

• 導語
• 集群調(diào)度系統(tǒng)介紹
• 大規(guī)模集群管理的難題
• 運營大規(guī)模集群的挑戰(zhàn)
• 設計集群調(diào)度系統(tǒng)時的取舍
• 美團集群調(diào)度系統(tǒng)演變之路
• 多集群統(tǒng)一調(diào)度：提升數(shù)據(jù)中心資源利用率
• 調(diào)度引擎服務：賦能PaaS服務云原生落地
• 未來展望：構(gòu)建云原生操作系統(tǒng)

導語

集群調(diào)度系統(tǒng)在企業(yè)數(shù)據(jù)中心中占有舉足輕重的地位，隨著集群規(guī)模與應用數(shù)量的不斷激增，開發(fā)者處理業(yè)務問題的復雜度也顯著提升。如何解決大規(guī)模集群管理的難題，設計優(yōu)秀且合理的集群調(diào)度系統(tǒng)，做到保穩(wěn)定，降成本，提效率？本文將會逐一進行解答。| 備注：文章最早發(fā)布于《新程序員003》云原生時代的開發(fā)者專欄。

集群調(diào)度系統(tǒng)介紹

集群調(diào)度系統(tǒng)，又被稱為數(shù)據(jù)中心資源調(diào)度系統(tǒng)，普遍用來解決數(shù)據(jù)中心的資源管理和任務調(diào)度問題，它的目標是做到數(shù)據(jù)中心資源的有效利用，提升資源的利用率，并為業(yè)務方提供自動化的運維能力，降低服務的運維管理成本。工業(yè)界比較知名的集群調(diào)度系統(tǒng)，如開源的OpenStack、YARN、Mesos和Kubernetes等等，再如知名互聯(lián)網(wǎng)公司Google的Borg、微軟的Apollo、百度的Matrix、阿里巴巴的Fuxi和ASI。集群調(diào)度系統(tǒng)作為各互聯(lián)網(wǎng)公司核心的IaaS基礎設施，在近十幾年經(jīng)歷了多次架構(gòu)演進。伴隨著業(yè)務從單體架構(gòu)向SOA（面向服務的架構(gòu)）演進和微服務的發(fā)展，底層的IaaS設施也從物理機裸機時代逐步跨越到容器時代。雖然在演進過程中我們要處理的核心問題沒有改變，但由于集群規(guī)模和應用數(shù)量的急劇膨脹，問題的復雜度也成指數(shù)級增長。本文將闡述大規(guī)模集群管理的挑戰(zhàn)和集群調(diào)度系統(tǒng)的設計思路，并以美團集群調(diào)度系統(tǒng)落地實踐為例，講述通過打造多集群統(tǒng)一調(diào)度服務，持續(xù)提升資源的利用率，提供Kubernetes引擎服務賦能PaaS組件，為業(yè)務提供更好的計算服務體驗等一系列云原生實踐。

大規(guī)模集群管理的難題

眾所周知，業(yè)務快速增長帶來的是服務器規(guī)模和數(shù)據(jù)中心數(shù)量的暴增。對于開發(fā)者而言，在大規(guī)模集群調(diào)度系統(tǒng)的業(yè)務場景下，必須要解決的兩個難題是：

1. 如何管理好數(shù)據(jù)中心大規(guī)模集群部署調(diào)度，特別是在跨數(shù)據(jù)中心場景下，如何實現(xiàn)資源的彈性和調(diào)度能力，在保障應用服務質(zhì)量的前提下盡可能地提升資源的利用率，充分降低數(shù)據(jù)中心成本。
2. 如何改造底層基礎設施，為業(yè)務方打造云原生操作系統(tǒng)，提升計算服務體驗，實現(xiàn)應用的自動化容災響應和部署升級等，減少業(yè)務方對底層資源管理的心智負擔，讓業(yè)務方可以更專注于業(yè)務本身。

運營大規(guī)模集群的挑戰(zhàn)

為了在真實的生產(chǎn)環(huán)境解決上述兩個難題，具體又可以再拆分成以下四個大規(guī)模集群運營管理挑戰(zhàn)：

1. 如何解決用戶多樣化需求并快速響應。業(yè)務的調(diào)度需求和場景豐富且動態(tài)多變，作為集群調(diào)度系統(tǒng)這樣的平臺型服務，一方面需要能夠快速交付功能，及時滿足業(yè)務需求；另一方面還需要把平臺打造得足夠通用，將業(yè)務個性化需求抽象為可落地到平臺的通用能力，并長期進行迭代。這非?？简炂脚_服務團隊的技術演進規(guī)劃，因為一不小心，團隊就會陷入無休止的業(yè)務功能開發(fā)中，雖然滿足了業(yè)務需求，卻會造成團隊工作低水平重復的現(xiàn)象。
2. 如何提高在線應用數(shù)據(jù)中心的資源利用率且同時保障應用服務質(zhì)量。資源調(diào)度一直是業(yè)界公認的難題，隨著云計算市場快速發(fā)展，各云計算廠商不斷加大對數(shù)據(jù)中心的投入。數(shù)據(jù)中心的資源使用率卻非常低，更加劇了問題的嚴重性。Gartner調(diào)研發(fā)現(xiàn)全球數(shù)據(jù)中心服務器CPU利用率只有6%～12%，即使是亞馬遜彈性計算云平臺（EC2，Elastic Compute Cloud）也只有7%～17%的資源利用率，可見資源浪費有多嚴重。究其原因，在線應用對于資源利用率非常敏感，業(yè)界不得不預留額外資源以保障重要應用的服務質(zhì)量（QoS，Qualityof Service）。集群調(diào)度系統(tǒng)需要在多應用混合運行時消除應用間的干擾，實現(xiàn)不同應用之間的資源隔離。
3. 如何為應用，特別是有狀態(tài)應用提供實例異常自動處理，屏蔽機房差異，降低用戶對底層的感知。隨著服務應用規(guī)模的持續(xù)擴大，以及云計算市場的日趨成熟，分布式應用往往會配置在不同地域的數(shù)據(jù)中心，甚至是跨越不同的云環(huán)境，實現(xiàn)了多云或混合云部署。而集群調(diào)度系統(tǒng)需要為業(yè)務方提供統(tǒng)一的基礎設施，實現(xiàn)混合多云架構(gòu)，屏蔽底層的異構(gòu)環(huán)境。同時降低應用運維管理的復雜性，提升應用的自動化程度，為業(yè)務提供更好的運維體驗。
4. 如何解決單集群過大或集群數(shù)量過多，而帶來的與集群管理相關的性能和穩(wěn)定性風險。集群本身的生命周期管理復雜度會伴隨集群規(guī)模和數(shù)量的增多而增大。以美團為例，我們所采取的兩地多中心多集群方案，雖然在一定程度上規(guī)避了集群規(guī)模過大的隱患，解決了業(yè)務隔離性、地域延遲等問題。隨著邊緣集群場景和數(shù)據(jù)庫等PaaS組件上云需求的出現(xiàn)，可以預見小集群數(shù)量將會有明顯的上漲趨勢。隨之帶來的是集群管理復雜度、監(jiān)控配置成本、運維成本的明顯增加，這時集群調(diào)度系統(tǒng)需要提供更有效的操作規(guī)范，并保證操作安全性、報警自愈和變更效率。

設計集群調(diào)度系統(tǒng)時的取舍

為了解決上述挑戰(zhàn)，一個好的集群調(diào)度器將發(fā)揮關鍵作用。但現(xiàn)實中從來不存在一個完美的系統(tǒng)，所以在設計集群調(diào)度系統(tǒng)時，我們需要根據(jù)實際場景在幾個矛盾中做出取舍：

1. 集群調(diào)度系統(tǒng)的系統(tǒng)吞吐量和調(diào)度質(zhì)量。系統(tǒng)吞吐量是我們通常評估一個系統(tǒng)好壞很重要的標準，但在面向在線服務的集群調(diào)度系統(tǒng)里更重要的是調(diào)度質(zhì)量。因為每次調(diào)度結(jié)果的影響是長期的（數(shù)天、數(shù)周甚至數(shù)月），非異常情況不會調(diào)整。所以如果調(diào)度結(jié)果錯誤，會直接導致服務時延增高。而調(diào)度質(zhì)量越高則意味著需要考慮的計算約束條件越多，而且調(diào)度性能越差的話，系統(tǒng)吞吐量越低。
2. 集群調(diào)度系統(tǒng)的架構(gòu)復雜度和可擴展性。系統(tǒng)對上層PaaS用戶開放的功能和配置越多，通過支持更多功能來提升用戶體驗（比如支持應用資源搶占回收和應用實例異常自愈），也就意味著系統(tǒng)復雜度越高，各子系統(tǒng)越容易發(fā)生沖突。
3. 集群調(diào)度系統(tǒng)的可靠性和單集群規(guī)模。單集群規(guī)模越大，則可調(diào)度范圍則越大，但對集群的可靠性挑戰(zhàn)也越大，因為爆炸半徑會增加，出現(xiàn)故障的影響也越大。單集群規(guī)模較小的情況下，雖然可以提升調(diào)度并發(fā)度，但可調(diào)度范圍變小，調(diào)度失敗概率變高，且集群管理復雜度變大。

目前，業(yè)內(nèi)的集群調(diào)度系統(tǒng)按照架構(gòu)區(qū)分，可以分為單體式調(diào)度器、兩級調(diào)度器、共享狀態(tài)調(diào)度器、分布式調(diào)度器和混合調(diào)度器這五種不同架構(gòu)（見下圖1），都是根據(jù)各自的場景需求做了不同的選擇，沒有絕對的好與壞。

圖1 集群調(diào)度系統(tǒng)架構(gòu)分類（摘自Malte Schwarzkopf - The evolution of cluster scheduler architectures）

• 單體式調(diào)度器使用復雜的調(diào)度算法結(jié)合集群的全局信息，計算出高質(zhì)量的放置點，不過延遲較高。如Google的Borg系統(tǒng)、開源的Kubernetes系統(tǒng)。
• 兩級調(diào)度器通過將資源調(diào)度和作業(yè)調(diào)度分離，解決單體式調(diào)度器的局限性。兩級調(diào)度器允許根據(jù)特定的應用做不同的作業(yè)調(diào)度邏輯，且同時保持了不同作業(yè)之間共享集群資源的特性，可是無法實現(xiàn)高優(yōu)先級應用的搶占。具有代表性的系統(tǒng)是Apache Mesos和Hadoop YARN。
• 共享狀態(tài)調(diào)度器通過半分布式的方式來解決兩級調(diào)度器的局限性，共享狀態(tài)下的每個調(diào)度器都擁有一份集群狀態(tài)的副本，且調(diào)度器獨立對集群狀態(tài)副本進行更新。一旦本地的狀態(tài)副本發(fā)生變化，整個集群的狀態(tài)信息就會被更新，但持續(xù)資源爭搶會導致調(diào)度器性能下降。具有代表性的系統(tǒng)是Google的Omega和微軟的Apollo。
• 分布式調(diào)度器使用較為簡單的調(diào)度算法以實現(xiàn)針對大規(guī)模的高吞吐、低延遲并行任務放置，但由于調(diào)度算法較為簡單并缺乏全局的資源使用視角，很難達到高質(zhì)量的作業(yè)放置效果，代表性系統(tǒng)如加州大學的Sparrow。
• 混合調(diào)度器將工作負載分散到集中式和分布式組件上，對長時間運行的任務使用復雜算法，對短時間運行的任務則依賴于分布式布局。微軟Mercury就采取了這種這種方案。

所以，如何評價一個調(diào)度系統(tǒng)的好壞，主要取決于實際的調(diào)度場景。以業(yè)內(nèi)使用最廣泛的YARN和Kubernetes為例，雖然兩個系統(tǒng)都是通用資源調(diào)度器，實際上YARN專注于離線批處理短任務，Kubernetes專注于在線長時間運行的服務。除了架構(gòu)設計和功能的不同（Kubernetes是單體式調(diào)度器，YARN是兩級調(diào)度器），二者的設計理念和視角也不同。YARN更專注任務，關注資源復用，避免遠程數(shù)據(jù)多次拷貝，目標是以更低成本、更高速度執(zhí)行任務。Kubernetes更專注服務狀態(tài)，關注錯峰、服務畫像、資源隔離，目標是保障服務質(zhì)量。

美團集群調(diào)度系統(tǒng)演變之路

美團在落地容器化的過程中，根據(jù)業(yè)務場景需求，集群調(diào)度系統(tǒng)核心引擎由OpenStack轉(zhuǎn)變?yōu)镵ubernetes，并在2019年底完成了在線業(yè)務容器化覆蓋率超過了98%的既定目標。但依然面臨資源利用率低、運維成本高等問題：

• 集群整體的資源利用率不高。如CPU資源平均利用率還處于業(yè)內(nèi)平均水平，相較于其他一線互聯(lián)網(wǎng)公司差距較大。
• 有狀態(tài)服務的容器化率程度不夠，特別是MySQL、Elasticsearch等產(chǎn)品沒有使用容器，業(yè)務運維成本和資源成本存在較大的優(yōu)化空間。
• 從業(yè)務需求考慮，VM產(chǎn)品會長期存在，VM調(diào)度和容器調(diào)度是兩套環(huán)境，導致團隊虛擬化產(chǎn)品運維成本較高。

因此，我們決定開始對集群調(diào)度系統(tǒng)進行云原生改造。打造一個具有多集群管理和自動化運維能力、支持調(diào)度策略推薦和自助配置、提供云原生底層擴展能力，并在保障應用服務質(zhì)量的前提下提升資源使用率的大規(guī)模高可用調(diào)度系統(tǒng)。核心工作圍繞保穩(wěn)定、降成本、提效率三大方向來構(gòu)建調(diào)度系統(tǒng)。

• 保穩(wěn)定：提升調(diào)度系統(tǒng)的健壯性、可觀測性；降低系統(tǒng)各模塊之間的耦合，減少復雜度；提升多集群管理平臺的自動化運維能力；優(yōu)化系統(tǒng)核心組件性能；確保大規(guī)模集群的可用性。
• 降成本：深度優(yōu)化調(diào)度模型，打通集群調(diào)度和單機調(diào)度鏈路。從資源靜態(tài)調(diào)度轉(zhuǎn)向資源動態(tài)調(diào)度，引入離線業(yè)務容器，形成自由競爭與強控結(jié)合，在保障高優(yōu)業(yè)務應用服務質(zhì)量的前提下，提升資源使用率，降低IT成本。
• 提效率：支持用戶自助調(diào)整調(diào)度策略，滿足業(yè)務個性化需求，積極擁抱云原生領域，為PaaS組件提供包括編排、調(diào)度、跨集群、高可用等核心能力，提升運維效率。

圖2 美團集群調(diào)度系統(tǒng)架構(gòu)圖

最終，美團集群調(diào)度系統(tǒng)架構(gòu)按照領域劃分為三層（見上圖2），調(diào)度平臺層、調(diào)度策略層、調(diào)度引擎層：

• 平臺層負責業(yè)務接入，打通美團基礎設施，封裝原生接口和邏輯，提供容器管理接口（擴容、更新、重啟、縮容）等功能。
• 策略層提供多集群統(tǒng)一調(diào)度能力，持續(xù)優(yōu)化調(diào)度算法和策略，結(jié)合業(yè)務的服務等級和敏感資源等信息，通過服務分級提升CPU使用率和分配率。
• 引擎層提供Kubernetes服務，保障多個PaaS組件的云原生集群穩(wěn)定性，并把通用能力下沉到編排引擎，降低業(yè)務云原生落地的接入成本。

通過精細化運營和產(chǎn)品功能打磨，我們一方面統(tǒng)一納管了美團近百萬的容器/虛擬機實例，另一方面將資源利用率從業(yè)內(nèi)平均水平提升到了一流水平，同時還支撐了PaaS組件的容器化和云原生落地。

多集群統(tǒng)一調(diào)度：提升數(shù)據(jù)中心資源利用率

評估考核集群調(diào)度系統(tǒng)的好壞，資源利用率是最重要的指標之一。因此，雖然我們在2019年完成了容器化，不過容器化不是目的，只是手段。我們的目標是通過從VM技術棧切換到容器技術棧，為用戶帶來更多的收益，比如全面降低用戶的計算成本。而提升資源利用率受限于集群的個別熱點宿主，一旦擴容，業(yè)務容器就有可能擴容到熱點宿主，業(yè)務的性能指標如TP95耗時會出現(xiàn)波動，以至于我們只能像業(yè)界其他公司一樣，通過增加資源冗余來保障服務質(zhì)量。究其原因，Kubernetes調(diào)度引擎的分配方式僅簡單考慮了Request/Limit Quota（Kubernetes為容器設定了請求值Request和約束值Limit，作為用戶申請容器的資源配額），屬于靜態(tài)資源分配。導致不同宿主機雖然分配了同樣多的資源，卻因宿主機的服務差異性使得宿主機的資源利用率也存在較大的差異。在學術界和工業(yè)界中，有兩種常用的方法解決資源使用效率和應用服務質(zhì)量之間的矛盾。第一種方法是通過高效的任務調(diào)度器在全局角度解決；第二種方法是通過單機資源管理手段來加強應用之間的資源隔離。不管是哪一種方法，都意味著我們需要全面掌握集群狀態(tài)，所以我們做了三件事：

• 系統(tǒng)地建立了集群狀態(tài)、宿主狀態(tài)、服務狀態(tài)的關聯(lián)，并結(jié)合調(diào)度仿真平臺，綜合考慮了峰值利用率和平均利用率，實現(xiàn)了基于宿主歷史負載和業(yè)務實時負載的預測和調(diào)度。
• 通過自研的動態(tài)負載調(diào)節(jié)系統(tǒng)和跨集群重調(diào)度系統(tǒng)，實現(xiàn)了集群調(diào)度和單機調(diào)度鏈路的聯(lián)動，根據(jù)業(yè)務分級實現(xiàn)了不同資源池的服務質(zhì)量保障策略。
• 經(jīng)過三版迭代，實現(xiàn)了自有集群聯(lián)邦服務，較好地解決了資源預占和狀態(tài)數(shù)據(jù)同步問題，提升了集群間的調(diào)度并發(fā)度，實現(xiàn)了計算分離、集群映射、負載均衡和跨集群編排控制（見下圖3）。

圖3 集群聯(lián)邦V3版本架構(gòu)

集群聯(lián)邦服務第三版本按照模塊拆分為Proxy層和Worker層，獨立部署：

• Proxy層會綜合集群狀態(tài)的因子及權重選擇合適的集群進行調(diào)度，并選擇合適的Worker分發(fā)請求。Proxy模塊使用etcd做服務注冊、選主和發(fā)現(xiàn)，Leader節(jié)點負責調(diào)度時預占任務，所有節(jié)點都能負責查詢?nèi)蝿铡?/span>
• Worker層對應處理一部分Cluster的查詢請求，當某集群任務阻塞，可以快速擴容一臺對應的Worker實例緩解問題。當單集群規(guī)模較大時會對應多個Worker實例，Proxy將調(diào)度請求分發(fā)給多個Worker實例處理，提升調(diào)度并發(fā)度，并減少每一個Worker的負載。

最終通過多集群統(tǒng)一調(diào)度，我們實現(xiàn)了從靜態(tài)資源調(diào)度模型轉(zhuǎn)向動態(tài)資源調(diào)度模型，從而降低了熱點宿主比例，減少了資源碎片比例，保障了高優(yōu)業(yè)務應用的服務質(zhì)量，將在線業(yè)務集群的服務器CPU利用率均值提升了10個百分點。集群資源利用率均值計算方式：Sum(nodeA.cpu.當前使用核數(shù) + nodeB.cpu.當前使用核數(shù) + xxx) / Sum(nodeA.cpu.總核數(shù) + nodeB.cpu.總核數(shù) + xxx），一分鐘一個點，當天所有值取平均。

調(diào)度引擎服務：賦能PaaS服務云原生落地

集群調(diào)度系統(tǒng)除了解決資源調(diào)度的問題之外，還解決服務使用計算資源的問題。正如《Software Engineering at Google》一書中提到的，集群調(diào)度系統(tǒng)作為Compute as a Service中關鍵組件之一，既要解決資源調(diào)度（從物理機拆解到CPU/Mem這樣的資源維度）和資源競爭（解決“吵鬧鄰居”），還需要解決應用管理（實例自動化部署、環(huán)境監(jiān)控、異常處理、保障服務實例數(shù)、確定業(yè)務需求資源量、不同服務種類等）。而且從某種程度上來說應用管理比資源調(diào)度更重要，因為這會直接影響業(yè)務的開發(fā)運維效率和服務容災效果，畢竟互聯(lián)網(wǎng)的人力成本比機器成本更高。復雜的有狀態(tài)應用的容器化一直是業(yè)界難題，因為這些不同場景下的分布式系統(tǒng)中通常維護了自己的狀態(tài)機。當應用系統(tǒng)發(fā)生擴縮容或升級時，如何保證當前已有實例服務的可用性，以及如何保證它們之間的可連通性，是相較無狀態(tài)應用復雜許多的棘手問題。雖然我們已經(jīng)把無狀態(tài)服務都容器化了，但我們還沒有充分發(fā)揮出一個良好的集群調(diào)度系統(tǒng)的全部價值。如果要想管好計算資源，必須管理好服務的狀態(tài)，做到資源和服務分離，提升服務韌性，而這也是Kubernetes引擎所擅長的。我們基于美團優(yōu)化定制的Kubernetes版本，打造了美團Kubernetes引擎服務MKE：

• 加強集群運維能力，完善了集群的自動化運維能力建設，包括集群自愈、報警體系、Event日志分析等，持續(xù)提升集群的可觀測性。
• 豎立重點業(yè)務標桿，與幾個重要的PaaS組件深入合作，針對用戶的痛點如Sidecar升級管理、Operator灰度迭代、報警分離做快速優(yōu)化，滿足用戶的訴求。
• 持續(xù)改進產(chǎn)品體驗，持續(xù)優(yōu)化Kubernetes引擎，除了支持用戶使用自定義Operator之外，也提供了通用的調(diào)度和編排框架（見圖4），幫助用戶以更低的成本接入MKE，獲得技術紅利。

圖4 美團Kubernetes引擎服務調(diào)度和編排框架

在我們推進云原生落地過程中，一個廣泛被關注的問題是：基于Kubernetes云原生方式來管理有狀態(tài)應用，相比于之前自己打造管理平臺有什么區(qū)別？對于這個問題，需要從問題根源——可運維性考慮：

• 基于Kubernetes意味著系統(tǒng)做到了閉環(huán)，不用擔心兩套系統(tǒng)經(jīng)常出現(xiàn)的數(shù)據(jù)不一致問題。
• 異常響應可以做到毫秒級別，降低了系統(tǒng)的RTO（Recovery Time Objective，即恢復時間目標，主要指所能容忍的業(yè)務停止服務的最長時間，也是從災難發(fā)生到業(yè)務系統(tǒng)恢復服務功能所需要的最短時間周期）。
• 系統(tǒng)運維復雜度也降低了，服務做到了自動化容災。除了服務本身之外，服務依賴的配置和狀態(tài)數(shù)據(jù)都可以一起恢復。
• 相比于之前各個PaaS組件“煙囪式”的管理平臺，通用能力可以下沉到引擎服務，減少開發(fā)維護成本，而通過依托于引擎服務，可以屏蔽底層異構(gòu)環(huán)境，實現(xiàn)跨數(shù)據(jù)中心和多云環(huán)境的服務管理。

未來展望：構(gòu)建云原生操作系統(tǒng)

我們認為，云原生時代的集群管理，會從之前的管理硬件、資源等職能全面轉(zhuǎn)變?yōu)橐詰脼橹行牡脑圃僮飨到y(tǒng)。以此為目標，美團集群調(diào)度系統(tǒng)還需從以下幾方面發(fā)力：

• 應用鏈路交付管理。隨著業(yè)務規(guī)模和鏈路復雜度的增大，業(yè)務所依賴的PaaS組件和底層基礎設施的運維復雜度早已超過普遍認知，對于剛接手項目的新人更是難上加難。所以我們需要支持業(yè)務通過聲明式配置交付服務并實現(xiàn)自運維，給業(yè)務提供更好的運維體驗，提升應用的可用性和可觀測性，減少業(yè)務對底層資源管理的負擔。
• 邊緣計算解決方案。隨著美團業(yè)務場景的不斷豐富，業(yè)務對邊緣計算節(jié)點的需求增長，比預期快很多。我們會參考業(yè)內(nèi)最佳實踐，形成適合在美團落地的邊緣解決方案，盡快為有需求的服務提供邊緣計算節(jié)點管理能力，實現(xiàn)云邊端協(xié)同。
• 在離線混部能力建設。在線業(yè)務集群的資源利用率提升是有上限的，根據(jù)Google在論文《Borg: the Next Generation》中披露的2019年數(shù)據(jù)中心集群數(shù)據(jù)，刨去離線任務，在線任務的資源利用率僅為30%左右，這也說明了再往上提升風險較大，投入產(chǎn)出比不高。后續(xù)，美團集群調(diào)度系統(tǒng)將持續(xù)探索在離線混部，不過由于美團的離線機房相對獨立，我們的實施路徑會與業(yè)界的普遍方案有所不同，會先從在線服務和近實時任務的混部開始，完成底層能力的構(gòu)建，再探索在線任務和離線任務的混部。

總結(jié)

美團集群調(diào)度系統(tǒng)在設計時，整體遵循合適原則，在滿足業(yè)務基本需求的情況下，保證系統(tǒng)穩(wěn)定后再逐步完善架構(gòu)，提升性能和豐富功能。因此，我們選擇了：

• 在系統(tǒng)吞吐量和調(diào)度質(zhì)量中我們選擇優(yōu)先滿足業(yè)務對系統(tǒng)的吞吐量需求，不過度追求單次調(diào)度質(zhì)量，而是通過重調(diào)度調(diào)整完善。
• 在架構(gòu)復雜度和可擴展性中我們選擇降低系統(tǒng)各模塊之間的耦合，減少系統(tǒng)復雜度，擴展功能必需可降級。
• 在可靠性和單集群規(guī)模中我們選擇通過多集群統(tǒng)一調(diào)度來控制單集群規(guī)模，保障系統(tǒng)可靠性，減少爆炸半徑。

未來，我們也會根據(jù)同樣的邏輯持續(xù)優(yōu)化迭代美團的集群調(diào)度系統(tǒng)，徹底轉(zhuǎn)變?yōu)橐詰脼橹行牡脑圃僮飨到y(tǒng)。

作者簡介

譚霖，來自美團基礎研發(fā)平臺/基礎技術部。