揭開阿里巴巴複雜任務資源混合調度技術面紗

做者 | 黃濤、汪萌海
來源|阿里巴巴雲原生公衆號

做爲更進一步的雲計算形態，雲原生正在成爲雲時代的技術新標準，經過重塑整個軟件生命週期，成爲釋放雲價值的最短路徑。

在企業內部，將雲原生基礎架構做爲企業內部的統一架構已成爲大勢所趨。與此同時，也必然帶來了由各類基礎平臺整合帶來的兼容性問題，特別是規模越大、歷史沉澱越多的企業，這種「技術債務」體現得越明顯。

本文分享的經驗來自於阿里巴巴過去數年來在混合調度方面積累的生產實踐積累，具備很強的生產實用價值。內容由淺入門，逐漸深刻到調度器內幕，講述在大規模容器調度場景下，阿里巴巴針對雲原生應用設計的統一基礎設施 ASI（Alibaba Serverless infrastructure）調度器如何管理阿里巴巴如此複雜、繁忙的資源調度任務；並嘗試經過一些具體的案例讓您得以充分理解，相信會爲有相似問題的讀者打開設計思路，並提供落地借鑑。經過本文，相信您將系統地理解阿里巴巴複雜任務場景下的資源混合調度。

調度器總覽

ASI 在阿里集團內部引領着容器全面上雲的實施，承擔了包括阿里集團內部輕量級容器架構演進、運維體系雲原生化等職責，並進一步加速促進了新興的技術包括 Mesh、Serverless、Faas 等在阿里集團內的落地；支撐了包括淘寶、天貓、優酷、高德、餓了麼、UC、考拉等幾乎全部經濟體內部業務、阿里云云產品衆多場景及生態。

ASI 的核心基於 Kubernetes，並提供完整的雲原生技術棧支持。現在的 ASI 也已成功實現與阿里雲容器服務 ACK（Alibaba Cloud Container Service for Kubernetes）的會師；而 ACK 既保留了雲上的各類能力，也能成功應對阿里集團複雜的業務環境。

ASI 調度器是 ASI 雲原生的核心組件之一。在 ASI 雲原生的發展歷程中，調度器的做用相當重要。最直觀的認知是：阿里巴巴規模龐大的在線電商交易容器，例如購物車、訂單、淘寶詳情等，每一臺容器的分佈，包括容器編排、單機計算資源、內存資源，均由調度器分配和調度；特別是在 雙11 零點峯值場景下，少數容器編排錯誤都有可能給業務帶來致命影響，調度器需負責把控峯值時每一臺容器計算的質量，其重要性可想而知。

ASI 調度器起源於 2015 年在線電商交易容器調度，這一年最先的調度器僅涵蓋在線交易 T4（阿里早期基於LXC和Linux Kernel定製的容器技術）和 Alidocker 場景，出生即責任重大，並在 2015 年扛住 雙11 流量峯值中發揮做用。

ASI 調度器的演進之路也伴隨着雲原生髮展的全過程。它經歷了最先期的在線交易容器調度器、Sigma 調度器、Cerebulum 調度器、ASI 調度器；到現在咱們正在建設的下一代調度器 Unified-Scheduler，它將進一步吸取並融合過去數年阿里巴巴 ODPS（伏羲）、Hippo 搜索、在線調度在各個領域的先進經驗。各階段的調度解讀以下圖：

在 ASI 調度器的演進過程當中有很是多的挑戰須要解決，主要體如今：

• 調度器調度的任務種類豐富多樣，有海量的在線長生命週期容器和 POD 實例、Batch 任務、衆多形態的 BestEffort 任務等不一樣 SLO 等級的任務；有計算型、存儲型、網絡型、異構型等衆多不一樣資源類型的任務，不一樣任務的訴求和場景又千差萬別。

• 調度之上的宿主資源各異。調度管理着阿里集團內部數量龐大的宿主資源，包括衆多機型的存量非雲物理機、雲上神龍、ECS、異構機型如 GPU/FPGA 等。

• 調度器服務場景普遍。例如：最典型的泛交易場景；最複雜的中間件場景；Faas/Serverless/Mesh/Job 等衆多新興計算場景；餓了麼、考拉、神馬等新興生態場景；公共雲上伴隨着多租安全隔離的調度訴求；還有全球範圍內都很是具備挑戰性的 ODPS（伏羲）、Hippo、螞蟻、ASI 統一調度場景。

• 在基礎設施層的職責衆多。調度器部分承擔着基礎設施機型定義、計算存儲網絡資源整合、收斂硬件形態、透明化基礎設施等衆多職責。

關於阿里雲原生詳細的發展歷程，有興趣的同窗能夠經過《一個改變世界的「箱子」》這篇文章來了解。下面，咱們重點來分享 ASI 調度器是如何管理着阿里如此龐大規模、如此複雜繁忙的計算資源調度任務。

調度器初探

1. 調度器是什麼

調度器在 ASI 衆多組件中的做用很是核心。調度器是雲原生容器平臺調度系統內衆多核心組件之一；調度器是資源交付的基石。調度器是 ASI 雲原生的大腦。調度器的價值主要體如今：

• 能力強大 & 場景豐富的資源交付(計算、存儲)

• 成本最優的資源交付

• 業務運行時穩定最優的資源交付

更通俗地講，調度器要作的是：

• 一次做業調度的最優：在集羣內選擇一臺最合適的宿主機，並在這臺宿主機上，以最佳的資源使用姿式，作到最少的相互干擾（如 CPU 分佈、IO 爭搶）來運行用戶提交的計算做業。

• 集羣全局調度的最優：確保全局資源編排最優（如碎片等）、資源運行最穩定、全局成本最優。

在 ASI 雲原生體系中，中心調度器所在的位置以下圖（其中標紅的框框所示）：

2. 廣義的調度器

在大部分時候，業界講到調度器指的是「中心調度器」，例如社區的 K8s kube-scheduler。但真實的調度場景複雜，每一次調度都是一個複雜又靈活的綜合體協同。做業提交後，它須要中心調度器、單機調度、內核調度多層次調度共同協調，並進一步在 K8s 組件 kubelet、controller 等配合下完成執行；在線調度場景，又有着批量編排調度器；而重調度下的屢次調度則確保集羣老是保持最優。

ASI 廣義的調度器理解爲：中心調度器、單機調度、內核調度、重調度、規模化編排調度、多層調度 一體的綜合體。

1）中心調度器

中心調度器負責計算每個（或一批）做業的資源編排計算，它確保一次調度最優。中心調度器爲這個具體的任務計算肯定諸如集羣、地域、執行節點（宿主機）等信息，更進一步細化節點上的 CPU 分配、存儲、網絡資源分配。

中心調度器在 K8s 生態組件協同下，管理着大部分任務的生命週期。

ASI 雲原生的演進之路中，中心調度器即上文描述的 Sigma 調度器、Cerebulum 調度器、ASI 調度器等等。

2）單機調度

主要負責兩類職責：

第一類職責：統籌協同單機內多 POD 的最佳運行。ASI 在接受到中心調度器的節點選擇指令後，將任務調度到具體的節點上執行，單機調度即開始工做：

• 單機調度將馬上、或週期性、或運維式 動態確保單機內多 POD 的工做最優，這意味着它將在單機內統籌協同資源，例如：每個 POD 的 CPU 核分配的最佳調整。
• 實時根據 POD 的運行指標如負載、QPS 等，針對部分運行時資源執行單機內的 VPA 擴縮容、或對低優先級的任務執行驅逐等操做。例如：動態擴展 POD 的 CPU 容量。

第二類職責：單機資源信息的採集、上報、匯聚計算，爲中心調度提供決策依據。在 ASI 內，單機調度組件主要指 SLO-Agent、Kubelet 的部分加強能力；在正在建設的 Unified-Scheduler 調度內，單機調度主要指 SLO-Agent、Task-Agent、以及 Kubelet 的部分加強能力。

3）內核調度

單機調度從資源視角統籌單機內多 POD 的最佳運行，但任務的運行態實際由內核控制。這就須要內核調度。

4）重調度

中心調度器確保了每次任務的最佳調度，即一次性調度問題；但中心調度器並不能實現集羣維度的全局最優，這就須要重調度。

5）規模化編排調度

規模化編排調度是阿里巴巴大規模在線調度的特有場景，自 17 年開始建設，如今已經很是成熟，並仍在持續加強中。

利用規模化編排能力，咱們能夠一次性調度數萬、數十萬容器，一次性確保集羣維度全部容器的全局最佳編排。它很是巧妙地彌補了一次性中心調度的弊端，規避了大規模建站場景下需反覆重調度的複雜度。

關於內核調度、重調度、規模化編排調度，咱們將在下面的章節中詳細展開。

6）調度分層

另外一個維度，咱們也會定義調度分層，包括 一層調度、二層調度、三層調度...等；Sigma 在離線混部場景甚至引入了零層調度的概念。每一個調度系統對調度分層的理解和定義會不同，並都有各自的概念。例如，在過去的 Sigma 體系內，調度分爲 0 層、1 層 和 2 層調度：

• 0 層調度器負責的職責是負責全局資源視圖和管理，並承接各個 1 層調度間的調度仲裁，以及具體執行；1 層調度主要是對應 Sigma 調度器、伏羲調度器 [也能夠包含其它調度器]。
• 在 Sigma 體系中，Sigma 調度器做爲 1 層調度，負責資源層的分配。
• 2 層調度交由不一樣的接入業務各自實現（例如電商交易、廣告 Captain、數據庫 AliDB 等）。2 層調度充分貼近和理解各自業務，並站在業務全局視角作衆多優化，建設調度能力，如業務驅逐、有狀態應用故障自動運維等，作到貼心服務。

Sigma 的調度分層體系的致命弊端是，各個二層調度的技術能力和投入良莠不齊；例如廣告的二層調度系統很是優秀，但並非全部的二層調度對業務貼心到極致。ASI 吸收教訓，將衆多能力下沉至 ASI 內，並進一步標準化上層 PAAS，簡化上層的同時加強上層能力。

而今天正在建設的下一代調度器概念內，也分爲多層，例如：計算負載層（主要指 Workload 的調度管理）、計算調度層（如 DAG 調度、MR 調度等）、業務層（同 Sigma 2 層的概念）。

3. 調度資源類型

我嘗試用正在建設的 Unified-Scheduler 調度器來讓你們更好地理解。在 Unified-Scheduler 調度器內，調度着 Product 資源、Batch 資源、BE 計算資源三種分等級的資源形態。

不一樣調度器對分等級的資源形態有不一樣的定義，但本質上大同小異。爲了讓你們更好地理解這一精髓，我在後續的章節對 ASI 調度器也作了詳細講解。

1）Product（在線）資源

有 Quota 預算的資源，且調度器需保障其最高級別的資源可用性。典型表明是在線電商核心交易的長生命週期 POD 實例。最經典的例子就是 雙11 核心鏈路上的購物車（Cart2）、訂單（tradeplatform2）等交易核心的業務 POD。這些資源要求算力的嚴格保障、高優先級、實時性、響應低延時、不可被幹擾等等。

舉例來講，在線交易的長生命週期 POD 的存在時間很長，數天、數月、甚至數年。大部分應用研發同窗申請的應用，在構建完畢後須要申請數臺長生命週期實例，這些都是 Product 資源。淘寶、天貓、聚划算、高德、友盟、合1、菜鳥、國際化、閒魚....等等衆多業務研發同窗申請的 POD（或容器）實例，至關大部分都是 product 資源。

Product 資源不只僅指在線長生命週期的 POD；凡是符合上述定義的資源請求，都是 Product 資源。但並非全部的長生命週期 POD 都是 Product 資源。例如阿里內部「Aone 實驗室」用於執行 CI 構建任務的 POD，能夠長生命週期存在，但它能夠被低成本驅逐搶佔。

2）Batch 資源

在線業務使用的 Product 資源的 Allocate 和 Usage 之間的 Gap 在一段時間內是比較穩定的，這個 Gap 和 Prod 未分配的資源就做爲BE資源，售賣給針對 latency 不那麼敏感和可是對資源穩定性有必定需求的業務。Batch 有 quota 預算，可是保證一段時間內（例如 10 分鐘）的必定機率（例如 90%）的資源可用性。

也就是說，Product（在線）資源申請走了帳面上的資源，但實際上從負載利用率指標來看可能有衆多算力未被使用；此時將發揮調度器的差別化 SLO 分等級調度能力，將那些未跑滿的部分，做爲超發資源充分使用，售賣給 Batch 資源。

3）Best Effort(BE)資源

指沒有 Quota 預算，不保障資源可用性，隨時能夠被壓制和搶佔；節點上已分配在節點的 Usage 低於一個水位的時候，調度器認爲這部分 Gap 是一個「比較不穩定/不記帳」的資源，那麼這個 Gap 就稱爲 BE 資源。

咱們能夠這樣來比方：Product、Batch 資源負責大塊吃肉，BE 資源則負責消費 Product 和 Batch 不要的殘渣。例如：平常開發工做中，研發須要跑不少 UT 測試任務，這類計算任務對計算資源的質量要求並不高，時間延時的容忍度也比較高，也不大好評估額度預算，針對這類場景去購買大量的 Product 或者 Batch 資源，將很是不划算；但若是使用最廉價的 BE 資源，收益將至關可觀。此時，BE 資源就是 Product/Batch 運行中沒有用到的資源。

很容易理解到，正是經過這種分等級的資源調度能力，從技術層面，Unified-Scheduler 調度器能夠將一臺物理節點的資源使用，發揮到極致。

調度器能力總覽

下圖是 ASI 圍繞着廣義調度需覆蓋的職責，並對應不一樣資源等級訴求、以及服務的豐富業務場景，構建的調度能力總覽。經過這張圖，你們能夠理解到 ASI 調度器的技術全貌。

典型在線調度能力

1. 在線調度的業務訴求

在 ASI 雲原生容器平臺上，在線部分服務着交易、導購、直播、視頻、本地生活、菜鳥、高德、合1、友盟、海外等數十個 BU 的各種調度場景。其中最高等級的「Product 資源」的調度佔比最爲龐大。

在線業務的調度與離線調度、衆多 JOB 型調度相比較，有着典型的差別（描述在線場景時，你們能夠想象到，離線調度的世界一樣精彩）。

1）生命週期

• Long Running：在線應用的容器生命週期廣泛都比較長。少則數天，大部分以月計，部分長尾應用甚至存活數年。
• 啓動時間長：應用的鏡像體積大，下載鏡像時間較長，服務啓動內存預熱等等，這致使應用啓動時間在幾秒、數十分鐘都有。

長生命週期的特性，與一些典型的短生命週期任務調度（如 FaaS 函數計算），在任務特徵上有着本質的不一樣，背後的技術挑戰也大相徑庭。例如：相對短生命週期的函數計算場景的挑戰是：最極致的調度效率、百毫秒的執行效率、快速的調度吞吐、POD 運行時性能等。而長生命週期 POD 帶來的差別化挑戰是：全局最優的調度必須依賴重調度來持續迭代優化；運行時的最佳調度必須依賴單機重調度持續優化保障。能夠想象，在過去非雲原生時代，衆多業務不可遷移，對調度而言簡直是噩夢；這意味着調度器不只僅面對調度能力的技術問題，還需面對難度巨大的存量業務治理推進；在線應用的啓動時間長，又更加重下降了重調度的靈活度，帶來更多的複雜度。

2）容器運行時

• 容器運行時須要支持業務的實時交互、快速響應、低業務 RT 等訴求。在線容器運行時，大部分系統需承擔實時交互職責，並對延遲異常敏感，稍大的延遲將帶來明顯糟糕的業務體感。

• 資源特徵明顯：如網絡消耗型、IO 消耗型、計算消耗型等等。相同特徵的實例共存時，極易發生彼此間的明顯資源爭搶。

在線容器的運行時因爲對業務和算力都很是敏感，所以對調度質量提出了很是苛刻的挑戰。

3）應對阿里在線應用特有的複雜業務模型

• 流量高低峯特徵：在線業務的服務通常都會有比較明顯的高低峯，例如餓了麼的高峯是在中午和晚上、淘寶的高峯也有明顯的波谷和峯值。

• 突發流量：業務的複雜度，致使這些突發流量並不必定能呈現必定規律；例如直播業務可能由於某個突發的事件致使流量激增。突發流量背後的技術訴求每每是彈性，最經典的案例是 2020 年疫情期間的釘釘彈性訴求。

• 資源冗餘：在線業務從出生的那一刻開始，就定義了冗餘資源；這主要是出於容災的考慮。但站在阿里巴巴全局視角，至關多的長尾應用因規模小而對成本和利用率不敏感，聚沙成塔，背後是巨大的算力浪費。

4）特有的規模化運維訴求

• 複雜的部署模型：例如：須要支持應用單元化部署，多機房容災，小流量、灰度、正式多環境部署的複雜調度需求。

• 大促 & 秒殺的規模化峯值特徵：阿里巴巴的各類大促貫穿整年，好比你們熟悉的 雙十一、雙十二、春節紅包等等。整個鏈路上的應用壓力、資源消耗都會隨着大促峯值流量的增加成倍增長，這須要調度器強大的規模化調度能力。

• 大促建站：大促的時間是計劃性的，爲了節約雲資源的採購成本，必須儘量下降雲資源的保有時間。調度器需最快速度完成大促前的建站，並在大促後快速歸還資源到阿里雲。這意味着極其嚴苛的規模化調度效率訴求，並把更多的時間留給業務。

2. 一次調度：調度基本能力

下表詳細描述了在線調度最多見的調度能力：

• 應用基本訴求對應的是：應用擴容對應的基本訴求，例如 POD 規格、OS 等。在 ASI 調度器內，它被抽象爲普通的 label 匹配調度。

• 容災與打散：locality 調度，ASI 已經經過各類手段獲取到諸多詳細信息，例如上圖中的 網絡核心、ASW 等。

• 高級策略：ASI 會盡量標準化、通用化業務訴求，但仍然不可避免地存在一些業務，對資源、運行時有衆多特定要求，例如特定的基礎設施環境如硬件等、容器能力的特定訴求如 HostConfig 參數、內核參數訴求等。

• 關於調度規則中心：業務對策略的特定要求，決定了調度背後還將對應一個強大的調度策略中心，它指導着調度器使用正確的調度規則；調度規則中心的數據來自於學習，或專家運維經驗。調度器採納這些規則，並應用於每個 POD 的擴容分配中。

3. 應用間編排策略

因集羣節點數量有限，彼此潛在干擾的衆多應用，不得已需在同一節點並存時，這時就須要應用間編排策略，來確保每個宿主節點和每個 POD 運行時最優。

實際的調度生產實踐中，「業務穩定性」永遠是排在第一位，但資源卻老是有限的；咱們很難平衡「資源成本最優」和「業務穩定性」。大部分狀況下，應用間編排策略都能完美地解決這一平衡；經過定義應用之間（如 CPU 消耗密集型、網絡消耗型、IO 密集型、峯值模型特徵等）的並存策略，集羣內充分打散，或同一節點並存時又有充分的策略約束保護，進而作到不一樣 POD 間的干擾機率最小。

更進一步，調度器在運行時輔以更多技術手段優化，例如：經過網絡優先級控制、CPU 精細編排控制等策略，來儘量規避應用間運行時的潛在影響。

應用間編排策略帶來的其它挑戰是：調度器在建設好本職的應用間編排能力外，還需充分理解其上運行的每個業務運行特徵。

4. CPU 精細化編排

CPU 精細編排在「在線調度領域」內是很是有意思的話題，它包括 CpuSet 調度、CpuShare 調度。其它場景的調度領域，例如離線調度領域，它並無這麼重要，甚至不可被理解；但在線交易場景下，不管是理論推斷、實驗室場景、仍是無數次大促壓測數據，都證實了精準的 CPU 調度就是這麼重要。

CPU 精細編排的一句話解讀是：調核，確保 CPU 核最大化、最穩定地被使用。

CPU 精細編排如此重要，以致於 ASI 在過去的數年，已經將這一規則吃透並使用到了極致。相信您在看到下表後（僅含 CpuSet 精細編排調度），您也會感嘆 ASI 甚至已經將它玩出了花樣。

科普：以一臺 96 核（實際上咱們說的都是 96 個邏輯核）的 X86 架構物理機或神龍爲例，它有 2 個 Socket，每一個 Socket 有 48 個物理核，每一個物理核下有 2 個邏輯核。【固然，ARM 的架構又與X86不一樣】。

因爲 CPU 架構的 L1 L2 L3 Cache 設計，最理想的分配是：同一個物理核下的 2 個邏輯核，其中一個核 分配給最核心的在線交易應用如 Carts2（購物車業務），另外一個核分配給另外一個不繁忙的非核心應用；這樣在平常、或 雙11 零點峯值時，Carts2 能夠佔盡便宜。這種用法，在實際的生產環境、壓測演練環境中均屢試不爽。

假如咱們將同一個物理核上的兩個邏輯核，都同時分配給 Carts2 時，因爲業務峯值的相同（尤爲是同一個 POD 實例），資源的最大化使用就會大打折扣。

理論上咱們也應該儘可能規避兩個一樣都是交易核心的應用，例如 Carts2（購物車業務）、tradePlatform2（訂單），使其不要去共用這兩個邏輯核。但實際上在微觀層面，Carts2 和 tradePlatform2 的峯值會有差別，因此實際上影響還小。儘管這樣的 CPU 分配看起來有些「將就」；但物理資源總歸是有限的，也只能保持這份「將就」了。

而在 numa-aware 開啓時，爲了最大化使用 L3 Cache 來提高計算性能，同一個 POD 的更多核，又應確保儘可能規避跨 Socket。

而當使用 CPUShare 時，Request 和 Limit 如何分配，也很是有學問；CPUSet 和 CPUShare 並存時，調度將更加複雜（例如：CpuSet 容器的新擴容、或下線，潛在的訴求是整機全部 POD 的 CPU 重調度）；而在新興的 GPU 異構調度場景下，CPU 與 GPU 的並存分配也具有必定的技巧。

5. 規模化編排調度

規模化編排主要應用於建站、搬站或規模化遷移場景，例如阿里巴巴頻繁的大促建站、機房遷移訴求下的超大規模搬站等。基於成本考量，咱們須要在儘量短的時間，以極少的人力成本快速建立數十萬級別 POD。

多個任務依次請求的隨機性和不可預見性，決定了中心調度在規模化領域存在諸多弊端。在沒有規模化編排能力以前，阿里巴巴大規模站點的建設，每每需經歷複雜的 「業務自擴容 -> 反覆重調度」 的過程，這將耗費大量人力數週的精力。好在咱們有了規模化編排調度，在小時級規模化交付效率的同時，又能確保 99% 以上的資源分配率。

通用調度能力

1. 重調度

中心調度器作到了一次性最優調度；但與最終想要的集羣維度全局調度最優，是兩個徹底不同的概念。重調度也包括全局中心重調度和單機重調度。

爲何必定須要中心重調度做爲一次性調度的補償呢？咱們舉幾個例子：

• ASI 調度集羣內存在衆多長生命週期的 POD 實例；隨着時間的積累，集羣維度必將產生衆多資源碎片、CPU 利用率不均等問題。

• 大核 POD 的分配須要動態的騰挪式調度能力（實時驅逐某些小核 POD 並空閒出資源）、或基於提早規劃的全局重調度，在衆多節點上預空閒一些大核。

• 資源供給老是緊張的。對某個 POD 作一次性調度時，可能存在必定「將就」，這意味着某種瑕疵和不完美；但集羣資源又是動態變化的，咱們能夠在其後的某個時刻，對該 POD 發起動態遷移，即重調度，這將帶來業務更佳的運行時體驗。

中心重調度的算法、實現上每每很是複雜。咱們須要深刻理解各種重調度場景並充分覆蓋，定義清晰的重調度 DAG 圖，動態執行並確保執行的成功率。

衆多場景也須要單機重調度。例如：CPU 精細編排的 SLO 優化、基於 OQS 數據驅動的單機重調度優化等。

須要強調的是，單機重調度的執行，必須先解決安全風控的問題，規避不可控的爆炸半徑。在單機側風控能力不足前，咱們建議您暫不要採用節點自治方式，而是改成嚴格保護控制下的中心統一觸發。實際上在 K8s 域內，會出現很是多不可避免的節點自治場景（例如 pod yaml 變化時，Kubelet 將執行相應變動），過去 ASI 花費數年持續梳理每個潛在的風控點，並迭代建設了分等級風控管理（核按鈕、高危、中危等）的 Defender 系統；針對潛在風險項，執行單機側動做前，與中心的 Defender 交互，經過安全防控規避災難事件的發生。咱們建議調度器必須一樣作到嚴密的安全防護等級，才容許節點自治操做。

2. 內核調度

內核調度存在的背景是：一臺並行運行着衆多任務的繁忙宿主機，即便中心調度 & 單機調度，已共同確保其最佳資源分配（如 CPU 分配、IO 打散等），但實際運行時，多任務間不可避免地進行內核態的資源爭搶，在你們熟知的在離線混部場景中競爭尤其激烈。這就須要中心調度、單機調度、內核調度 經過衆多協同，例如統籌任務的各種資源優先級，並交由內核調度控制執行。

這也對應衆多內核隔離技術。包括 CPU：調度優先級 BVT、Noise Clean 機制等；內存：內存回收、OOM 優先級等；網絡：網絡金銀銅優先級、IO 等等。

在今天咱們還有了安全容器。基於安全容器的 Guest Kernel 和 Host Kernel 隔離機制，咱們能夠更優雅地規避內核運行態的部分爭搶問題。

3. 彈性調度、分時調度

彈性和分時的邏輯都是更好的資源複用，只是維度不同。

ASI 調度器與阿里雲基礎設施層充分協同，利用 ECS 提供的強大彈性能力，在餓了麼場景，低峯期向雲歸還資源，高峯期從新申請相應資源。

咱們可使用 ASI 大資源池（注：ASI 資源池的宿主資源均來自於阿里云云資源）的內置彈性 Buffer，也能夠直接使用阿里雲 IaaS 層的彈性技術。兩者的平衡是一個頗有爭議的話題，也是一個比較藝術的過程。

ASI 的分時調度更是將資源複用作到了極致，並帶來了巨大的成本優化。經過天天晚上大規模停用在線交易 POD 實例，釋放的資源用於 ODPS 離線任務使用，天天早上離線任務退水並從新拉起在線應用。這個經典場景更是將在離線混部技術的價值發揮到最大。

分時的精髓是資源複用，以及依賴的大資源池建設管理，這是資源運營 & 調度技術 的綜合。這須要調度器積累多多益善的豐富形態做業、以及多多益善的海量做業任務。

4. 垂直伸縮調度/X+1/VPA/HPA

垂直伸縮調度是一種秒級交付技術，很是完美地部分解決了突發流量問題。垂直伸縮調度也是大促零點峯值壓力風險的殺手鐗，經過對存量 POD 的資源垂直調整、準確可靠的 CPU 調度和洗牌算法來作到計算資源的秒級交付。垂直伸縮調度、VPA 技術一脈相承，垂直伸縮調度也是 VPA 的場景之一。

「X+1」 水平擴容調度在某種意義上也能夠理解爲 HPA 場景之一，只不過 「X+1」 水平擴容調度由手動觸發。「X+1」 側重於強調極致的資源交付效率，這背後是研發效率的極大提高：在線 POD「X（若干）」分鐘可啓動完畢提供業務服務；除應用啓動外的全部其它操做，務必在 「1」 分鐘內所有完成。

垂直伸縮調度與 「X+1」 水平擴容調度互爲補充，共同爲各種峯值保駕護航。

ASI 也正在實施更多的 VPA 和 HPA 場景。例如，咱們能夠經過 VPA 技術，額外提供螞蟻春節紅包更多數量的免費算力，這將是很是大的成本節約。

VPA/HPA 等調度技術更多場景的極致實施，也是阿里巴巴將來將繼續追求完善的地方。

5. 分等級[差別化 SLO]的資源調度

差別化 SLO 調度是調度器的精髓之一；這節內容與上文中的【調度資源類型】章節存在必定的重複。鑑於差別化 SLO 的複雜度，因此有意將它放在本章的最後一節來說述。

ASI 調度器內，也很是精確地定義了 SLO(服務質量目標)、QoS 和 Priority。

1）SLO

SLO 描述的是服務質量目標。ASI 經過不一樣的 QoS 和 Priority 來提供差別化 SLO，不一樣的 SLO 有不一樣的訂價。用戶能夠根據不一樣的業務特性來決定"認購"哪類 SLO 保障的資源。如：離線的數據分析任務，則可使用低等級的 SLO 以享受更低的價格。而對於重要業務場景則可使用高等級的 SLO，固然價格也會更高。

2）QoS

QoS 描述了資源保障質量。K8s 社區定義的 QOS 包括 Guaranteed、Burstable、BestEffort。ASI 中定義的 QOS，與社區並無進行徹底映射（社區徹底用 Request / Limit 來映射）。爲了能將集團的場景（如 CPUShare，混部等）描述清晰，ASI 從另一個維度定義了 QOS，它包括 LSE / LSR / LS / BE，清晰地劃分出不一樣的資源保障，不一樣的業務根據自身的延遲敏感度能夠選擇不一樣的 QOS。

3）PriorityClass

PriorityClass 和 QoS 是兩個維度的概念。PriorityClass 描述的則是任務的重要性。

資源分配策略和任務的重要性（即 PriorityClass 和 QoS）會有不一樣的組合，固然也須要存在必定的對應關係。例如，咱們能夠定義一個名爲 Preemptible 的 PriorityClass，其大部分任務對應到 BestEffort 的 QoS。

各個調度系統對 PriorityClass 有不一樣的定義。例如：

• 在 ASI 中，ASI 的 priority 定義，目前定義了 System、Production、Preemptible、Production、Preemptible。這裏不詳細解讀每一個等級的細節。
• 搜索 Hippo 中定義的種類和粒度更細，包括：System、ServiceHigh、ServiceMedium、ServiceLow、JobHigh、JobMedium、JobLow 等。這裏不詳細解讀每一個等級的細節。

全局最優的調度

1. 調度模擬器

調度模擬器有點相似於阿里巴巴的全鏈路壓測系統，經過線上真實的流量回放、或模擬流量回放，在模擬環境驗證調度新的能力，進而不斷地錘鍊各類調度算法，優化各種指標。

調度模擬器的另外一個常見的用途是，是對線上疑難雜症問題作線下模擬，作到無害、高效地定位各種問題。

必定程度上，調度模擬器是全局調度最優的基礎。有了調度模擬器，咱們得以在模擬環境，反覆錘鍊各類算法、技術框架、技術鏈路，進而作到全局指標的優化，例如：全局分配率、不一樣場景下的調度性能、調度穩定性等等。

2. Elastic Scheduling Platform（ESP 平臺）

爲了作到全局最優的調度，圍繞着調度器，ASI 構建了一套全新的 Elastic Scheduling Platform（ESP 平臺），旨在圍繞調度器，打造基於調度數據指導 & 核心調度能力 & 產品化調度運營 的一站式自閉環調度效能系統。

在過去，咱們已經建設了諸多相似模塊，例如調度 SLO 巡檢、衆多調度工具、不一樣場景的二層調度平臺等；而基於 ESP 平臺，集合更多的二層調度能力，帶給 ASI 全局最優的調度質量，並圍繞 業務穩定性、資源成本、用戶效能提高，帶給客戶更貼心的服務。

更多調度能力

本文嘗試着系統地講解 ASI 調度器的基本概念、原理和各類場景，並帶領您走進調度器美麗精彩的世界。調度器博大精深，遺憾的是，受限於篇幅，也不得不控制篇幅，很是多的內容點到爲止並未深刻展開。在調度器內，還有更多更深層次的調度內幕，如異構機型調度、調度畫像、公平性調度、優先級調度、騰挪調度、搶佔調度、磁盤調度、Quota、CPU 歸一化、GANG Scheduling、調度 Tracing、調度診斷等衆多調度能力，本文均未予闡述。受限於篇幅，本文也未講述 ASI 強大的調度框架結構及優化、調度性能優化等更多更深層次的技術內幕。

早在 2019 年，ASI 已優化 K8s 單集羣至業界領先的萬級節點規模，並得益於阿里雲 ACK 強大的 K8s 運維體系，阿里集團內持續保有着數量衆多的大規模計算集羣，同時也積累了業界領先的 K8s 多集羣生產實踐。正是在這些大規模 K8s 集羣內，ASI 基於完善的容器調度技術，持續爲衆多複雜的任務資源提供着計算資源算力。

在過去的數年，藉助於集團全面上雲的契機，阿里集團在調度領域，已實現了從 ASI 管控到阿里雲容器服務 ACK的全面遷移和進化。而阿里集團內複雜、豐富、規模化的業務場景，將來也將持續輸出、加強並錘鍊雲的技術能力。