頭圖.png

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

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

本文分享的經驗來自於阿里巴巴過去數年來在混合調度方面積累的生產實踐積累，具有很強的生產實用價值。內容由淺入門，逐漸深入到調度器內幕，講述在大規模容器調度場景下，阿里巴巴針對雲原生應用設計的統一基礎設施 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 全局最優的調度質量，並圍繞業務穩定性、資源成本、用戶效能提升，帶給客戶更貼心的服務。

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