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

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

本文分享的經驗來自于阿里巴巴過去數年來在混合調度方面積累的生產實踐積累，具有很強的生產實用價值。內容由淺入門，逐漸深入到調度器內幕，講述在大規模容器調度場景下，阿里巴巴針對云原生應用設計的統一基礎設施 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 資源。淘寶、天貓、聚劃算、高德、友盟、合一、菜鳥、國際化、閑魚....等等眾多業務研發同學申請的 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 云原生容器平臺上，在線部分服務著交易、導購、直播、視頻、本地生活、菜鳥、高德、合一、友盟、海外等數十個 BU 的各類調度場景。其中最高等級的“Product 資源”的調度占比最為龐大。

在線業務的調度與離線調度、眾多 JOB 型調度相比較，有著典型的差異（描述在線場景時，大家可以想象到，離線調度的世界同樣精彩）。

1）生命周期

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

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

2）容器運行時

• 容器運行時需要支持業務的實時交互、快速響應、低業務 RT 等訴求。在線容器運行時，大部分系統需承擔實時交互職責，并對延遲異常敏感，稍大的延遲將帶來明顯糟糕的業務體感。
• 資源特征明顯：如網絡消耗型、IO 消耗型、計算消耗型等等。相同特征的實例共存時，極易發生彼此間的明顯資源爭搶。

在線容器的運行時由于對業務和算力都非常敏感，因此對調度質量提出了非常苛刻的挑戰。

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

• 流量高低峰特征：在線業務的服務一般都會有比較明顯的高低峰，例如餓了么的高峰是在中午和晚上、淘寶的高峰也有明顯的波谷和峰值。
• 突發流量：業務的復雜度，導致這些突發流量并不一定能呈現一定規律；例如直播業務可能因為某個突發的事件導致流量激增。突發流量背后的技術訴求往往是彈性，最經典的案例是 2020 年疫情期間的釘釘彈性訴求。
• 資源冗余：在線業務從出生的那一刻開始，就定義了冗余資源；這主要是出于容災的考慮。但站在阿里巴巴全局視角，相當多的長尾應用因規模小而對成本和利用率不敏感，積少成多，背后是巨大的算力浪費。

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

• 復雜的部署模型：例如：需要支持應用單元化部署，多機房容災，小流量、灰度、正式多環境部署的復雜調度需求。
• 大促 & 秒殺的規模化峰值特征：阿里巴巴的各種大促貫穿全年，比如大家熟悉的 雙11、雙12、春節紅包等等。整個鏈路上的應用壓力、資源消耗都會隨著大促峰值流量的增長成倍增加，這需要調度器強大的規模化調度能力。
• 大促建站：大促的時間是計劃性的，為了節約云資源的采購成本，必須盡可能降低云資源的保有時間。調度器需最快速度完成大促前的建站，并在大促后快速歸還資源到阿里云。這意味著極其嚴苛的規模化調度效率訴求，并把更多的時間留給業務。

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的全面遷移和進化。而阿里集團內復雜、豐富、規模化的業務場景，未來也將持續輸出、增強并錘煉云的技術能力。

作者：黃濤、汪萌海

?

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的揭开阿里巴巴复杂任务资源混合调度技术面纱的全部內容，希望文章能夠幫你解決所遇到的問題。

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