本文是美團點評基礎架構系列文章之一。這個系列將全面介紹支撐數億用戶、超千萬日訂單的美團點評平臺諸多業務的公共基礎架構相關技術。系列已經發布的文章包括： - 《分布式會話跟蹤系統架構設計與實踐》 - 《Leaf——美團點評分布式ID生成系統》 - 《深度剖析開源分布式監控CAT》

背景

美團點評作為國內最大的O2O平臺，業務熱度的高峰低谷非常顯著且規律，如果遇到節假日或促銷活動，流量還會在短時間內出現成倍的增長。過去傳統虛擬機的服務運行及部署機制在應對服務快速擴容、縮容需求中存在諸多不足：

• 資源實例創建慢，需要預先安裝好運行所需的環境，比如JDK等。
• 擴容后的實例，需要經過代碼部署流程，一些情況下還需要修改配置后才能承接流量。
• 資源申請容易回收難，促銷活動后做相關資源的回收下線會比較漫長。
• 由于業務存在典型的高峰低谷，為保障業務穩定，資源實例數要保障能抗高峰期容量峰值的1-2倍，從而導致非高峰期資源大量閑置，整體利用效率低。

注意到上面這些問題后，我們經過調研與測試，結合業界的實踐經驗，決定基于Docker容器技術來實現服務的彈性伸縮，有效應對快速擴縮容需求、提升資源利用效率。

Docker容器技術也是一類虛擬化技術，不同于虛擬機的硬件虛擬化，容器是基于操作系統內核的隔離機制實現。容器省去了模擬底層硬件、指令等操作，直接基于宿主機內核，并隔離出獨立的系統環境、加以資源限制，能有效提升啟動速度和性能。

HULK容器平臺簡介

美團點評基礎架構團隊在2015年中旬啟動了公司級的容器集群管理及彈性伸縮平臺——HULK項目，目標是提供Docker容器平臺，推動公司的服務容器化，實現自動的彈性擴容、縮容，提升資源利用率、業務運維效率并降低IT運維成本。

HULK是美國漫威漫畫旗下超級英雄“綠巨人”，擁有強大的變身能。變身后的綠巨人對各類疾病、射線、毒藥及物理攻擊有很高的免疫力，加上超強的再生能力使得其非常強大。

我們選擇HULK作為項目名，就是希望美團點評服務在接入HULK之后可以擁有綠巨人般強大的變身能力（彈性擴縮），進而在此基礎上提升服務的健壯性、穩定性及資源利用率。

在HULK所有模塊中，調度系統負責對資源池進行統一的調度分配與管理。主要職責包括：

接受上層彈性伸縮及集群管理模塊的資源申請、回收請求，執行資源分配。

綜合多種資源利用、服務優化的調度算法，決策最優資源部署位置，提高資源利用率、節約成本并保障服務穩定性。

對接云平臺IaaS層。

本文將主要對HULK容器平臺的調度系統進行介紹，包括當前調度系統的設計、考量指標、相關算法等。

HULK調度系統介紹

核心指標

從HULK彈性調度系統的設計以及后續的演進過程來看，一個完善的調度系統主要需要關注以下三個指標：

• 資源利用率：即提高整體物理集群的資源利用率。一個優秀的調度系統可以把資源利用率提高到30%~70%，而簡陋的調度系統甚至會使資源利用率降低到10%以下。
• 業務最優化：即保障運行業務的穩定高可用，以及服務相互調用的優化。比如，如果調度系統一味的追求資源利用率，將宿主機上堆砌超過其負載能力的實例，又或一臺宿主機/機架的故障會影響到一個服務下所有實例的運行，都在業務穩定性上打了折扣。
• 并發調度能力：調度系統請求處理能力的體現。一個大規模的物理集群上，往往運行了數以千百計的業務，當出現調度請求高峰的場景下，調度系統要有能力在短時間內給出答案，即使這個答案可能只是全局近似最優解。

調度系統設計難題

調度系統設計的難題，在于幾個調度核心指標在實現上存在的矛盾關系，類似于CAP理論中的三要素，無法同時滿足。

在CAP理論中，Consistency（一致性）、Availability（可用性）與Partition Tolerance（分區容錯性）無法同時滿足。如果追求可用性與分區容錯性，則需要犧牲強一致性，只能保證最終一致性；而如果要保障強一致性與可用性，如果出現網絡故障將無法正常工作。

類似的，在調度系統中，如果要追求極限的資源利用率，則每一次調度的結果必須是基于當前資源池狀態的最優解，因此不管調度隊列還是調度處理計算只能是“單行道”，效率低下是毋庸置疑的，大批量伸縮調度場景下任務堆積嚴重。

如果追求高效的調度能力，則所有調度請求需要并發處理。但底層資源池只有一個，很容易出現多個調度請求爭搶同一份資源的情況。這種情況下，就要采取措施來保障資源層數據一致性，且調度所得的結果不能保證是全局最優解（無法最大化資源利用率）。

業界解決思路

Mesos

Mesos采用雙層調度的理念，把應用相關的管理交由上層Framework來做，這也是Mesos與Kubernetes等系統最大的不同點。Mesos只是分布式系統內核，即管理分布式資源、對外暴露標準接口來操作集群資源（屏蔽資源層細節）。在雙層調度的模式下，Mesos只負責在不同的Framework之間分派資源，將資源作為Offer的形式提供給Framework。

這種做法把上述調度設計矛盾丟給了Framework，但如果只從提供資源Offer的角度來看，這是一種并發調度的形式（同一個Mesos資源池，資源要提供給上層多個Framework）。Mesos解決并發調度、資源池數據一致性的方案是，資源Offer同時只會分派給一個Framework。這種資源分派方式是悲觀的，資源被Framework獨占，直到返回或超時。

顯然，這種悲觀鎖導致了Mesos雙層調度的并發粒度較小，但是在多數情況下，同個Mesos集群上層的Framework數量不會太多，有時只有一個Framework在獨享資源，因此這種悲觀鎖的方案一般不會存在分配調度的瓶頸問題。

Omega

Omega同樣采用了將資源分派給上層應用的調度方式，與Mesos的悲觀鎖不同，Omega采用了樂觀鎖（MVCC，基于多版本的并發訪問控制）解決并發調度的問題，因此Omega也被稱為共享狀態調度器。

由于將資源層信息作為共享數據提供給上層所有應用，Omega為了解決數據一致性，會對所有應用調度的提交沖突做解決，本質上是為每個節點維護了一個狀態關系數據庫。從這個角度看，Omega也存在一些缺點：

共享調度時沖突發生的頻率，直接影響了整體調度器的性能。

由于沒有集中的調度模塊，難以對所有資源分組（Namespace）或用戶的資源使用量做精確限制。

上層調度器數量仍然不能很多，并行分發完整的集群狀態的開銷較大。

Borg與Kubernetes

Borg據說現在已經逐漸演進吸收了Omega的很多設計思想，包括共享狀態調度模式，然而Kubernetes默認調度plugin的做法仍然是串行處理隊列中的調度任務，這也符合Kubernetes追求的簡潔優雅。

HULK調度解決方案

對于調度器設計難題，我們認為針對不同的場景，指標的側重點不同。

比如對于分布式系統的CAP，大多數互聯網場景下都會保證AP而舍棄C（只保證最終一致性），因為在互聯網分布式集群規模大、網絡故障頻發的場景下，要保證服務高可用只能犧牲強一致；而對于金融等涉及錢財的領域，則一般保證CA、舍棄P，即使遇到網絡故障時只讀不寫，也必須保證強一致性。

同理對于調度器資源層設計，在互聯網高并發、彈性伸縮頻發的場景下，可以犧牲部分資源利用率從而提高并發調度能力。

HULK調度系統模型如下：

如圖，HULK調度系統分為調度請求隊列、調度計算模塊、調度資源池這三個模塊。工作流程如下：

上層HULK彈性伸縮系統，將調度任務ID寫入調度請求隊列中。

HULK調度系統消費調度請求隊列，取出的調度任務ID將由調度計算池執行調度計算，決策出備選的部署位置，并向調度資源池申請資源。

調度資源池維護管理宿主機集群資源，全部資源會提供給所有調度任務共享（與Omega類似），資源池中每個宿主機都有一個對應的Actor來負責管理。

調度計算模塊（資源調度算法）

HULK調度系統的調度計算方式與諸多業界調度系統類似，通過過濾+打分的方式篩選出“最優部署位置”：

• 宿主機（Host）：調度資源池中共享的宿主機集群，支持pool級別硬隔離，如在線服務與數據庫/緩存的實例部署在不同的物理機集群中；支持資源軟隔離，如在線服務離線任務混布部署，通過cgroups等機制隔離和設置權重。
• 過濾（Filter）：預選（Predicates）的概念，通過超售、打散限制策略，排除掉一部分不合需求的宿主機。
• 打分（Rank）：優選（Priorities）的概念，通過在線離線混布、不同資源類型混布、宿主機負載均衡等策略和對應權重，最終計算出一個rank值，根據rank值排序最終得出最優部署位置。

超售

不管是在傳統虛擬機時代還是容器時代，超售始終是一個讓人又愛又恨的機制。

超售在一定程度上提高了集群的資源利用率，因為機器在申請之時往往提高對真實資源消耗的預估，也就是在服務運行中，絕大多數情況用不到申請的所有資源。然而正因為超售，常常會帶來各種因資源爭用引發的服務異常，嚴重的情況下會導致宿主機上所有實例的不可用。

HULK容器調度同樣采用了超售機制，我們和IaaS層對資源進行了分類，可壓縮資源（如CPU、I/O等）使用超售機制，而不可壓縮資源（如Memory、Disk）只允許在一些測試環境超售。

相比于是否開啟超售，超售系數才是更為棘手的難題，它直接關系到資源利用率和服務穩定性。我們采用了超售上限+動態系數的機制，從IaaS層設置的超售上限固定了資源超售的上限比例，超過上限的實例創建將會失敗，而HULK調度系統會根據具體場景決定超售系數：

參考宿主機實時監控，如Load負載、內存使用、帶寬占用等指標。

不同的實例類型（在線、離線）調度時超售系數不同。

業務實例打散

隨著物理集群規模的擴大，宿主機故障頻次也會響應提高。如果一個在線服務的所有實例都部署在同一個宿主機上，很可能出現宿主機宕機后服務整體不可用，這是我們不能接受的。

業務用戶在HULK上配置不同的伸縮組，每個組對應了一個機房（數據中心），同個機房調度過程中會把同個服務的實例打散到不同的宿主機上，并優先在不同的交換機（機架）下。此外，針對數據庫/緩存類的實例還有更嚴格的容災策略，比如Redis實例調度部署時，不允許同一個交換機下部署超過該Redis集群25%的實例數量。

在線離線混布

一般來說，在線服務（如外賣、酒旅等服務）和離線任務（如定時任務、爬蟲、大數據計算）的需求資源類型和高峰/執行時間不盡相同，將這兩種實例進行混布可以有效提高物理集群的資源利用率。

Borg系統中對prod與non-prod實例的一類處理方式是，根據宿主機上實例運行狀況，實時調整實例的資源配置。比如當在線服務迎來流量高峰、宿主機內存告急時，Borg會調整宿主機上non-prod任務的內存配額，以保證在線服務的穩定性。

但這種方案對Google中的部分C/C++服務適用，在美團點評Java服務的場景下，實例內存配額調整可能會導致OOM，而重啟服務非我們所愿。

目前HULK平臺上的離線任務主要還是定時任務與爬蟲，HULK針對在線離線混布場景從資源分配、時間錯峰上優化。根據美團點評的服務特性，HULK會盡量保證在早晚高峰的時期動態擴容在線服務承接流量，而在低峰期會對應縮容在線服務，并調度部署離線任務執行。

宿主機負載均衡

在調度計算的打分過程中，還會參考當前宿主機的負載情況。

HULK會從監控系統中獲取宿主機的系統監控數據，包括了CPU、Load、Memory、IO等指標。針對負載較低的宿主機我們給予較高的權重，而負載較高的宿主機，即使物理資源較為空閑，也不會優先選擇部署。

調度資源池（資源申請算法）

當調度計算過程決策出一個根據調度rank權重排序好的資源可部署位置列表后，調度任務會取列表前n個元素，依次向對應的宿主機Actor申請資源，直到宿主機Actor返回批準（調度成功）；如果取出的前n個均被拒絕，調度任務需要根據新的全局資源池共享狀態再次調度計算。

如果兩個調度任務基于共享資源狀態同時申請某個宿主機上同一塊資源，則宿主機Actor會根據mailbox中消息的順序來處理，資源先到先得，后者調度任務會繼續向下一個備選資源的宿主機Actor嘗試申請。

這種資源調度的架構下，調度的并發度相比串行調度有了顯著的提高，即使出現提交沖突，重試機制也是非常輕量的，一般都可以在前n次之內完成。

這里另一個核心問題在于n取值的權衡。如果n取值1，則每次失敗后就需要根據當前的集群資源狀態重新調度計算，這種情況下調度資源利用率較高，但效率較低；而若n取值大于1，則重試后的調度位置往往并非當前最佳調度位置，且n越大這里的最優調度偏差就越大。我們考慮的是根據當前整個系統中的調度請求數量來確定這個動態的n變量取值，當調度任務較少時n取較小值，當調度任務較多、彈性伸縮頻繁時，n的取值會相應調大。

調度模式總結

總的來看，HULK調度系統的共享狀態資源調度模式與Omega比較相似，不同的是Omega采用MVCC為每個節點維護一個狀態關系數據庫，而HULK使用Actor模型來解決提交沖突。另外，HULK調度任務的n次最優重試機制，在互聯網的彈性伸縮場景下可以帶來更高效的調度能力。

結束語

彈性調度系統作為HULK平臺的核心模塊之一，有著下接美團云IaaS平臺、抽象化資源層，上承彈性伸縮系統、處理調度請求的職責。我們從美團點評的服務特殊性出發，打造適用于大規模容器化場景的調度體系，后續還會在大數據離線任務場景下做更優化的深層智能調度。

此外，我們對Kubernetes等開源解決方案同樣抱有極大的興趣，從Kubernetes近年來的發展上能看到未來容器平臺的標準雛形，我們也在積極參與和回饋開源社區。

作者簡介

思宇，2015年加入美團點評，目前是美團點評基礎架構團隊高級工程師，負責容器集群管理與彈性調度平臺的設計開發工作，主攻調度、容器研發、集群管理等方向。

最后發個廣告，美團點評基礎架構部長期招聘容器研發、彈性調度、集群管理、機器學習以及Linux內核方面的人才，有興趣的同學可以發送簡歷到zhangxi##meituan.com。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的美团点评容器平台HULK的调度系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。