作為更進(jìn)一步的云計(jì)算形態(tài)，云原生正在成為云時(shí)代的技術(shù)新標(biāo)準(zhǔn)，通過重塑整個(gè)軟件生命周期，成為釋放云價(jià)值的最短路徑。

在企業(yè)內(nèi)部，將云原生基礎(chǔ)架構(gòu)作為企業(yè)內(nèi)部的統(tǒng)一架構(gòu)已成為大勢所趨。與此同時(shí)，也必然帶來了由各種基礎(chǔ)平臺整合帶來的兼容性問題，特別是規(guī)模越大、歷史沉淀越多的企業(yè)，這種“技術(shù)債務(wù)”體現(xiàn)得越明顯。

本文分享的經(jīng)驗(yàn)來自于阿里巴巴過去數(shù)年來在混合調(diào)度方面積累的生產(chǎn)實(shí)踐積累，具有很強(qiáng)的生產(chǎn)實(shí)用價(jià)值。內(nèi)容由淺入門，逐漸深入到調(diào)度器內(nèi)幕，講述在大規(guī)模容器調(diào)度場景下，阿里巴巴針對云原生應(yīng)用設(shè)計(jì)的統(tǒng)一基礎(chǔ)設(shè)施 ASI（Alibaba Serverless infrastructure）調(diào)度器如何管理阿里巴巴如此復(fù)雜、繁忙的資源調(diào)度任務(wù)；并嘗試通過一些具體的案例讓您得以充分理解，相信會為有類似問題的讀者打開設(shè)計(jì)思路，并提供落地借鑒。通過本文，相信您將系統(tǒng)地理解阿里巴巴復(fù)雜任務(wù)場景下的資源混合調(diào)度。

調(diào)度器總覽

ASI 在阿里集團(tuán)內(nèi)部引領(lǐng)著容器全面上云的實(shí)施，承擔(dān)了包括阿里集團(tuán)內(nèi)部輕量級容器架構(gòu)演進(jìn)、運(yùn)維體系云原生化等職責(zé)，并進(jìn)一步加速促進(jìn)了新興的技術(shù)包括 Mesh、Serverless、Faas 等在阿里集團(tuán)內(nèi)的落地；支撐了包括淘寶、天貓、優(yōu)酷、高德、餓了么、UC、考拉等幾乎所有經(jīng)濟(jì)體內(nèi)部業(yè)務(wù)、阿里云云產(chǎn)品眾多場景及生態(tài)。

ASI 的核心基于 Kubernetes，并提供完整的云原生技術(shù)棧支持。如今的 ASI 也已成功實(shí)現(xiàn)與阿里云容器服務(wù) ACK（Alibaba Cloud Container Service for Kubernetes）的會師；而 ACK 既保留了云上的各種能力，也能成功應(yīng)對阿里集團(tuán)復(fù)雜的業(yè)務(wù)環(huán)境。

ASI 調(diào)度器是 ASI 云原生的核心組件之一。在 ASI 云原生的發(fā)展歷程中，調(diào)度器的作用至關(guān)重要。最直觀的認(rèn)知是：阿里巴巴規(guī)模龐大的在線電商交易容器，例如購物車、訂單、淘寶詳情等，每一臺容器的分布，包括容器編排、單機(jī)計(jì)算資源、內(nèi)存資源，均由調(diào)度器分配和調(diào)度；特別是在 雙11 零點(diǎn)峰值場景下，少數(shù)容器編排錯(cuò)誤都有可能給業(yè)務(wù)帶來致命影響，調(diào)度器需負(fù)責(zé)把控峰值時(shí)每一臺容器計(jì)算的質(zhì)量，其重要性可想而知。

ASI 調(diào)度器起源于 2015 年在線電商交易容器調(diào)度，這一年最早的調(diào)度器僅涵蓋在線交易 T4（阿里早期基于LXC和Linux Kernel定制的容器技術(shù)）和 Alidocker 場景，出生即責(zé)任重大，并在 2015 年扛住 雙11 流量峰值中發(fā)揮作用。

ASI 調(diào)度器的演進(jìn)之路也伴隨著云原生發(fā)展的全過程。它經(jīng)歷了最早期的在線交易容器調(diào)度器、Sigma 調(diào)度器、Cerebulum 調(diào)度器、ASI 調(diào)度器；到如今我們正在建設(shè)的下一代調(diào)度器 Unified-Scheduler，它將進(jìn)一步吸收并融合過去數(shù)年阿里巴巴 ODPS（伏羲）、Hippo 搜索、在線調(diào)度在各個(gè)領(lǐng)域的先進(jìn)經(jīng)驗(yàn)。各階段的調(diào)度解讀如下圖：

在 ASI 調(diào)度器的演進(jìn)過程中有非常多的挑戰(zhàn)需要解決，主要體現(xiàn)在：

• 調(diào)度器調(diào)度的任務(wù)種類豐富多樣，有海量的在線長生命周期容器和 POD 實(shí)例、Batch 任務(wù)、眾多形態(tài)的 BestEffort 任務(wù)等不同 SLO 等級的任務(wù)；有計(jì)算型、存儲型、網(wǎng)絡(luò)型、異構(gòu)型等眾多不同資源類型的任務(wù)，不同任務(wù)的訴求和場景又千差萬別。
• 調(diào)度之上的宿主資源各異。調(diào)度管理著阿里集團(tuán)內(nèi)部數(shù)量龐大的宿主資源，包括眾多機(jī)型的存量非云物理機(jī)、云上神龍、ECS、異構(gòu)機(jī)型如 GPU/FPGA 等。
• 調(diào)度器服務(wù)場景廣泛。例如：最典型的泛交易場景；最復(fù)雜的中間件場景；Faas/Serverless/Mesh/Job 等眾多新興計(jì)算場景；餓了么、考拉、神馬等新興生態(tài)場景；公共云上伴隨著多租安全隔離的調(diào)度訴求；還有全球范圍內(nèi)都非常具有挑戰(zhàn)性的 ODPS（伏羲）、Hippo、螞蟻、ASI 統(tǒng)一調(diào)度場景。
• 在基礎(chǔ)設(shè)施層的職責(zé)眾多。調(diào)度器部分承擔(dān)著基礎(chǔ)設(shè)施機(jī)型定義、計(jì)算存儲網(wǎng)絡(luò)資源整合、收斂硬件形態(tài)、透明化基礎(chǔ)設(shè)施等眾多職責(zé)。

關(guān)于阿里云原生詳細(xì)的發(fā)展歷程，有興趣的同學(xué)可以通過《一個(gè)改變世界的“箱子”》這篇文章來了解。下面，我們重點(diǎn)來分享 ASI 調(diào)度器是如何管理著阿里如此龐大規(guī)模、如此復(fù)雜繁忙的計(jì)算資源調(diào)度任務(wù)。

調(diào)度器初探

1. 調(diào)度器是什么

調(diào)度器在 ASI 眾多組件中的作用非常核心。調(diào)度器是云原生容器平臺調(diào)度系統(tǒng)內(nèi)眾多核心組件之一；調(diào)度器是資源交付的基石。調(diào)度器是 ASI 云原生的大腦。調(diào)度器的價(jià)值主要體現(xiàn)在：

• 能力強(qiáng)大 & 場景豐富的資源交付(計(jì)算、存儲)
• 成本最優(yōu)的資源交付
• 業(yè)務(wù)運(yùn)行時(shí)穩(wěn)定最優(yōu)的資源交付

更通俗地講，調(diào)度器要做的是：

• 一次作業(yè)調(diào)度的最優(yōu)：在集群內(nèi)選擇一臺最合適的宿主機(jī)，并在這臺宿主機(jī)上，以最佳的資源使用姿勢，做到最少的相互干擾（如 CPU 分布、IO 爭搶）來運(yùn)行用戶提交的計(jì)算作業(yè)。
• 集群全局調(diào)度的最優(yōu)：確保全局資源編排最優(yōu)（如碎片等）、資源運(yùn)行最穩(wěn)定、全局成本最優(yōu)。

在 ASI 云原生體系中，中心調(diào)度器所在的位置如下圖（其中標(biāo)紅的框框所示）：

2. 廣義的調(diào)度器

在大部分時(shí)候，業(yè)界講到調(diào)度器指的是“中心調(diào)度器”，例如社區(qū)的 K8s kube-scheduler。但真實(shí)的調(diào)度場景復(fù)雜，每一次調(diào)度都是一個(gè)復(fù)雜又靈活的綜合體協(xié)同。作業(yè)提交后，它需要中心調(diào)度器、單機(jī)調(diào)度、內(nèi)核調(diào)度多層次調(diào)度共同協(xié)調(diào)，并進(jìn)一步在 K8s 組件 kubelet、controller 等配合下完成執(zhí)行；在線調(diào)度場景，又有著批量編排調(diào)度器；而重調(diào)度下的多次調(diào)度則確保集群總是保持最優(yōu)。

ASI 廣義的調(diào)度器理解為：中心調(diào)度器、單機(jī)調(diào)度、內(nèi)核調(diào)度、重調(diào)度、規(guī)模化編排調(diào)度、多層調(diào)度 一體的綜合體。

1）中心調(diào)度器

中心調(diào)度器負(fù)責(zé)計(jì)算每一個(gè)（或一批）作業(yè)的資源編排計(jì)算，它確保一次調(diào)度最優(yōu)。中心調(diào)度器為這個(gè)具體的任務(wù)計(jì)算確定諸如集群、地域、執(zhí)行節(jié)點(diǎn)（宿主機(jī)）等信息，更進(jìn)一步細(xì)化節(jié)點(diǎn)上的 CPU 分配、存儲、網(wǎng)絡(luò)資源分配。

中心調(diào)度器在 K8s 生態(tài)組件協(xié)同下，管理著大部分任務(wù)的生命周期。

ASI 云原生的演進(jìn)之路中，中心調(diào)度器即上文描述的 Sigma 調(diào)度器、Cerebulum 調(diào)度器、ASI 調(diào)度器等等。

2）單機(jī)調(diào)度

主要負(fù)責(zé)兩類職責(zé)：

第一類職責(zé)：統(tǒng)籌協(xié)同單機(jī)內(nèi)多 POD 的最佳運(yùn)行。ASI 在接受到中心調(diào)度器的節(jié)點(diǎn)選擇指令后，將任務(wù)調(diào)度到具體的節(jié)點(diǎn)上執(zhí)行，單機(jī)調(diào)度即開始工作：

• 單機(jī)調(diào)度將立刻、或周期性、或運(yùn)維式 動態(tài)確保單機(jī)內(nèi)多 POD 的工作最優(yōu)，這意味著它將在單機(jī)內(nèi)統(tǒng)籌協(xié)同資源，例如：每一個(gè) POD 的 CPU 核分配的最佳調(diào)整。
• 實(shí)時(shí)根據(jù) POD 的運(yùn)行指標(biāo)如負(fù)載、QPS 等，針對部分運(yùn)行時(shí)資源執(zhí)行單機(jī)內(nèi)的 VPA 擴(kuò)縮容、或?qū)Φ蛢?yōu)先級的任務(wù)執(zhí)行驅(qū)逐等操作。例如：動態(tài)擴(kuò)展 POD 的 CPU 容量。

第二類職責(zé)：單機(jī)資源信息的采集、上報(bào)、匯聚計(jì)算，為中心調(diào)度提供決策依據(jù)。在 ASI 內(nèi)，單機(jī)調(diào)度組件主要指 SLO-Agent、Kubelet 的部分增強(qiáng)能力；在正在建設(shè)的 Unified-Scheduler 調(diào)度內(nèi)，單機(jī)調(diào)度主要指 SLO-Agent、Task-Agent、以及 Kubelet 的部分增強(qiáng)能力。

3）內(nèi)核調(diào)度

單機(jī)調(diào)度從資源視角統(tǒng)籌單機(jī)內(nèi)多 POD 的最佳運(yùn)行，但任務(wù)的運(yùn)行態(tài)實(shí)際由內(nèi)核控制。這就需要內(nèi)核調(diào)度。

4）重調(diào)度

中心調(diào)度器確保了每次任務(wù)的最佳調(diào)度，即一次性調(diào)度問題；但中心調(diào)度器并不能實(shí)現(xiàn)集群維度的全局最優(yōu)，這就需要重調(diào)度。

5）規(guī)模化編排調(diào)度

規(guī)模化編排調(diào)度是阿里巴巴大規(guī)模在線調(diào)度的特有場景，自 17 年開始建設(shè)，現(xiàn)在已經(jīng)非常成熟，并仍在持續(xù)增強(qiáng)中。

利用規(guī)模化編排能力，我們可以一次性調(diào)度數(shù)萬、數(shù)十萬容器，一次性確保集群維度所有容器的全局最佳編排。它非常巧妙地彌補(bǔ)了一次性中心調(diào)度的弊端，規(guī)避了大規(guī)模建站場景下需反復(fù)重調(diào)度的復(fù)雜度。

關(guān)于內(nèi)核調(diào)度、重調(diào)度、規(guī)模化編排調(diào)度，我們將在下面的章節(jié)中詳細(xì)展開。

6）調(diào)度分層

另一個(gè)維度，我們也會定義調(diào)度分層，包括 一層調(diào)度、二層調(diào)度、三層調(diào)度...等；Sigma 在離線混部場景甚至引入了零層調(diào)度的概念。每個(gè)調(diào)度系統(tǒng)對調(diào)度分層的理解和定義會不一樣，并都有各自的概念。例如，在過去的 Sigma 體系內(nèi)，調(diào)度分為 0 層、1 層 和 2 層調(diào)度：

• 0 層調(diào)度器負(fù)責(zé)的職責(zé)是負(fù)責(zé)全局資源視圖和管理，并承接各個(gè) 1 層調(diào)度間的調(diào)度仲裁，以及具體執(zhí)行；1 層調(diào)度主要是對應(yīng) Sigma 調(diào)度器、伏羲調(diào)度器 [也可以包含其它調(diào)度器]。
• 在 Sigma 體系中，Sigma 調(diào)度器作為 1 層調(diào)度，負(fù)責(zé)資源層的分配。
• 2 層調(diào)度交由不同的接入業(yè)務(wù)各自實(shí)現(xiàn)（例如電商交易、廣告 Captain、數(shù)據(jù)庫 AliDB 等）。2 層調(diào)度充分貼近和理解各自業(yè)務(wù)，并站在業(yè)務(wù)全局視角做眾多優(yōu)化，建設(shè)調(diào)度能力，如業(yè)務(wù)驅(qū)逐、有狀態(tài)應(yīng)用故障自動運(yùn)維等，做到貼心服務(wù)。

Sigma 的調(diào)度分層體系的致命弊端是，各個(gè)二層調(diào)度的技術(shù)能力和投入?yún)⒉畈积R；例如廣告的二層調(diào)度系統(tǒng)非常優(yōu)秀，但并不是所有的二層調(diào)度對業(yè)務(wù)貼心到極致。ASI 吸取教訓(xùn)，將眾多能力下沉至 ASI 內(nèi)，并進(jìn)一步標(biāo)準(zhǔn)化上層 PAAS，簡化上層的同時(shí)增強(qiáng)上層能力。

而今天正在建設(shè)的下一代調(diào)度器概念內(nèi)，也分為多層，例如：計(jì)算負(fù)載層（主要指 Workload 的調(diào)度管理）、計(jì)算調(diào)度層（如 DAG 調(diào)度、MR 調(diào)度等）、業(yè)務(wù)層（同 Sigma 2 層的概念）。

3. 調(diào)度資源類型

我嘗試用正在建設(shè)的 Unified-Scheduler 調(diào)度器來讓大家更好地理解。在 Unified-Scheduler 調(diào)度器內(nèi)，調(diào)度著 Product 資源、Batch 資源、BE 計(jì)算資源三種分等級的資源形態(tài)。

不同調(diào)度器對分等級的資源形態(tài)有不同的定義，但本質(zhì)上大同小異。為了讓大家更好地理解這一精髓，我在后續(xù)的章節(jié)對 ASI 調(diào)度器也做了詳細(xì)講解。

1）Product（在線）資源

有 Quota 預(yù)算的資源，且調(diào)度器需保障其最高級別的資源可用性。典型代表是在線電商核心交易的長生命周期 POD 實(shí)例。最經(jīng)典的例子就是 雙11 核心鏈路上的購物車（Cart2）、訂單（tradeplatform2）等交易核心的業(yè)務(wù) POD。這些資源要求算力的嚴(yán)格保障、高優(yōu)先級、實(shí)時(shí)性、響應(yīng)低延時(shí)、不可被干擾等等。

舉例來說，在線交易的長生命周期 POD 的存在時(shí)間很長，數(shù)天、數(shù)月、甚至數(shù)年。大部分應(yīng)用研發(fā)同學(xué)申請的應(yīng)用，在構(gòu)建完畢后需要申請數(shù)臺長生命周期實(shí)例，這些都是 Product 資源。淘寶、天貓、聚劃算、高德、友盟、合一、菜鳥、國際化、閑魚....等等眾多業(yè)務(wù)研發(fā)同學(xué)申請的 POD（或容器）實(shí)例，相當(dāng)大部分都是 product 資源。

Product 資源不僅僅指在線長生命周期的 POD；凡是符合上述定義的資源請求，都是 Product 資源。但并不是所有的長生命周期 POD 都是 Product 資源。例如阿里內(nèi)部“Aone 實(shí)驗(yàn)室”用于執(zhí)行 CI 構(gòu)建任務(wù)的 POD，可以長生命周期存在，但它可以被低成本驅(qū)逐搶占。

2）Batch 資源

在線業(yè)務(wù)使用的 Product 資源的 Allocate 和 Usage 之間的 Gap 在一段時(shí)間內(nèi)是比較穩(wěn)定的，這個(gè) Gap 和 Prod 未分配的資源就作為BE資源，售賣給針對 latency 不那么敏感和但是對資源穩(wěn)定性有一定需求的業(yè)務(wù)。Batch 有 quota 預(yù)算，但是保證一段時(shí)間內(nèi)（例如 10 分鐘）的一定概率（例如 90%）的資源可用性。

也就是說，Product（在線）資源申請走了賬面上的資源，但實(shí)際上從負(fù)載利用率指標(biāo)來看可能有眾多算力未被使用；此時(shí)將發(fā)揮調(diào)度器的差異化 SLO 分等級調(diào)度能力，將那些未跑滿的部分，作為超發(fā)資源充分使用，售賣給 Batch 資源。

3）Best Effort(BE)資源

指沒有 Quota 預(yù)算，不保障資源可用性，隨時(shí)可以被壓制和搶占；節(jié)點(diǎn)上已分配在節(jié)點(diǎn)的 Usage 低于一個(gè)水位的時(shí)候，調(diào)度器認(rèn)為這部分 Gap 是一個(gè)“比較不穩(wěn)定/不記賬”的資源，那么這個(gè) Gap 就稱為 BE 資源。

我們可以這樣來比方：Product、Batch 資源負(fù)責(zé)大塊吃肉，BE 資源則負(fù)責(zé)消費(fèi) Product 和 Batch 不要的殘?jiān)＠?#xff1a;日常開發(fā)工作中，研發(fā)需要跑很多 UT 測試任務(wù)，這類計(jì)算任務(wù)對計(jì)算資源的質(zhì)量要求并不高，時(shí)間延時(shí)的容忍度也比較高，也不大好評估額度預(yù)算，針對這類場景去購買大量的 Product 或者 Batch 資源，將非常不劃算；但如果使用最廉價(jià)的 BE 資源，收益將相當(dāng)可觀。此時(shí)，BE 資源就是 Product/Batch 運(yùn)行中沒有用到的資源。

很容易理解到，正是通過這種分等級的資源調(diào)度能力，從技術(shù)層面，Unified-Scheduler 調(diào)度器可以將一臺物理節(jié)點(diǎn)的資源使用，發(fā)揮到極致。

調(diào)度器能力總覽

下圖是 ASI 圍繞著廣義調(diào)度需覆蓋的職責(zé)，并對應(yīng)不同資源等級訴求、以及服務(wù)的豐富業(yè)務(wù)場景，構(gòu)建的調(diào)度能力總覽。通過這張圖，大家可以理解到 ASI 調(diào)度器的技術(shù)全貌。

典型在線調(diào)度能力

1. 在線調(diào)度的業(yè)務(wù)訴求

在 ASI 云原生容器平臺上，在線部分服務(wù)著交易、導(dǎo)購、直播、視頻、本地生活、菜鳥、高德、合一、友盟、海外等數(shù)十個(gè) BU 的各類調(diào)度場景。其中最高等級的“Product 資源”的調(diào)度占比最為龐大。

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

1）生命周期

• Long Running：在線應(yīng)用的容器生命周期普遍都比較長。少則數(shù)天，大部分以月計(jì)，部分長尾應(yīng)用甚至存活數(shù)年。
• 啟動時(shí)間長：應(yīng)用的鏡像體積大，下載鏡像時(shí)間較長，服務(wù)啟動內(nèi)存預(yù)熱等等，這導(dǎo)致應(yīng)用啟動時(shí)間在幾秒、數(shù)十分鐘都有。

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

2）容器運(yùn)行時(shí)

• 容器運(yùn)行時(shí)需要支持業(yè)務(wù)的實(shí)時(shí)交互、快速響應(yīng)、低業(yè)務(wù) RT 等訴求。在線容器運(yùn)行時(shí)，大部分系統(tǒng)需承擔(dān)實(shí)時(shí)交互職責(zé)，并對延遲異常敏感，稍大的延遲將帶來明顯糟糕的業(yè)務(wù)體感。
• 資源特征明顯：如網(wǎng)絡(luò)消耗型、IO 消耗型、計(jì)算消耗型等等。相同特征的實(shí)例共存時(shí)，極易發(fā)生彼此間的明顯資源爭搶。

在線容器的運(yùn)行時(shí)由于對業(yè)務(wù)和算力都非常敏感，因此對調(diào)度質(zhì)量提出了非常苛刻的挑戰(zhàn)。

3）應(yīng)對阿里在線應(yīng)用特有的復(fù)雜業(yè)務(wù)模型

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

4）特有的規(guī)模化運(yùn)維訴求

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

2. 一次調(diào)度：調(diào)度基本能力

下表詳細(xì)描述了在線調(diào)度最常見的調(diào)度能力：

• 應(yīng)用基本訴求對應(yīng)的是：應(yīng)用擴(kuò)容對應(yīng)的基本訴求，例如 POD 規(guī)格、OS 等。在 ASI 調(diào)度器內(nèi)，它被抽象為普通的 label 匹配調(diào)度。
• 容災(zāi)與打散：locality 調(diào)度，ASI 已經(jīng)通過各種手段獲取到諸多詳細(xì)信息，例如上圖中的 網(wǎng)絡(luò)核心、ASW 等。
• 高級策略：ASI 會盡可能標(biāo)準(zhǔn)化、通用化業(yè)務(wù)訴求，但仍然不可避免地存在一些業(yè)務(wù)，對資源、運(yùn)行時(shí)有眾多特定要求，例如特定的基礎(chǔ)設(shè)施環(huán)境如硬件等、容器能力的特定訴求如 HostConfig 參數(shù)、內(nèi)核參數(shù)訴求等。
• 關(guān)于調(diào)度規(guī)則中心：業(yè)務(wù)對策略的特定要求，決定了調(diào)度背后還將對應(yīng)一個(gè)強(qiáng)大的調(diào)度策略中心，它指導(dǎo)著調(diào)度器使用正確的調(diào)度規(guī)則；調(diào)度規(guī)則中心的數(shù)據(jù)來自于學(xué)習(xí)，或?qū)＜疫\(yùn)維經(jīng)驗(yàn)。調(diào)度器采納這些規(guī)則，并應(yīng)用于每一個(gè) POD 的擴(kuò)容分配中。

3. 應(yīng)用間編排策略

因集群節(jié)點(diǎn)數(shù)量有限，彼此潛在干擾的眾多應(yīng)用，不得已需在同一節(jié)點(diǎn)并存時(shí)，這時(shí)就需要應(yīng)用間編排策略，來確保每一個(gè)宿主節(jié)點(diǎn)和每一個(gè) POD 運(yùn)行時(shí)最優(yōu)。

實(shí)際的調(diào)度生產(chǎn)實(shí)踐中，“業(yè)務(wù)穩(wěn)定性”永遠(yuǎn)是排在第一位，但資源卻總是有限的；我們很難平衡“資源成本最優(yōu)”和“業(yè)務(wù)穩(wěn)定性”。大部分情況下，應(yīng)用間編排策略都能完美地解決這一平衡；通過定義應(yīng)用之間（如 CPU 消耗密集型、網(wǎng)絡(luò)消耗型、IO 密集型、峰值模型特征等）的并存策略，集群內(nèi)充分打散，或同一節(jié)點(diǎn)并存時(shí)又有充分的策略約束保護(hù)，進(jìn)而做到不同 POD 間的干擾概率最小。

更進(jìn)一步，調(diào)度器在運(yùn)行時(shí)輔以更多技術(shù)手段優(yōu)化，例如：通過網(wǎng)絡(luò)優(yōu)先級控制、CPU 精細(xì)編排控制等策略，來盡可能規(guī)避應(yīng)用間運(yùn)行時(shí)的潛在影響。

應(yīng)用間編排策略帶來的其它挑戰(zhàn)是：調(diào)度器在建設(shè)好本職的應(yīng)用間編排能力外，還需充分理解其上運(yùn)行的每一個(gè)業(yè)務(wù)運(yùn)行特征。

4. CPU 精細(xì)化編排

CPU 精細(xì)編排在“在線調(diào)度領(lǐng)域”內(nèi)是非常有意思的話題，它包括 CpuSet 調(diào)度、CpuShare 調(diào)度。其它場景的調(diào)度領(lǐng)域，例如離線調(diào)度領(lǐng)域，它并沒有這么重要，甚至不可被理解；但在線交易場景下，無論是理論推斷、實(shí)驗(yàn)室場景、還是無數(shù)次大促壓測數(shù)據(jù)，都證明了精準(zhǔn)的 CPU 調(diào)度就是這么重要。

CPU 精細(xì)編排的一句話解讀是：調(diào)核，確保 CPU 核最大化、最穩(wěn)定地被使用。

CPU 精細(xì)編排如此重要，以至于 ASI 在過去的數(shù)年，已經(jīng)將這一規(guī)則吃透并使用到了極致。相信您在看到下表后（僅含 CpuSet 精細(xì)編排調(diào)度），您也會感嘆 ASI 甚至已經(jīng)將它玩出了花樣。

科普：以一臺 96 核（實(shí)際上我們說的都是 96 個(gè)邏輯核）的 X86 架構(gòu)物理機(jī)或神龍為例，它有 2 個(gè) Socket，每個(gè) Socket 有 48 個(gè)物理核，每個(gè)物理核下有 2 個(gè)邏輯核。【當(dāng)然，ARM 的架構(gòu)又與X86不同】。
由于 CPU 架構(gòu)的 L1 L2 L3 Cache 設(shè)計(jì)，最理想的分配是：同一個(gè)物理核下的 2 個(gè)邏輯核，其中一個(gè)核 分配給最核心的在線交易應(yīng)用如 Carts2（購物車業(yè)務(wù)），另一個(gè)核分配給另一個(gè)不繁忙的非核心應(yīng)用；這樣在日常、或 雙11 零點(diǎn)峰值時(shí)，Carts2 可以占盡便宜。這種用法，在實(shí)際的生產(chǎn)環(huán)境、壓測演練環(huán)境中均屢試不爽。
假如我們將同一個(gè)物理核上的兩個(gè)邏輯核，都同時(shí)分配給 Carts2 時(shí)，由于業(yè)務(wù)峰值的相同（尤其是同一個(gè) POD 實(shí)例），資源的最大化使用就會大打折扣。
理論上我們也應(yīng)該盡量規(guī)避兩個(gè)同樣都是交易核心的應(yīng)用，例如 Carts2（購物車業(yè)務(wù)）、tradePlatform2（訂單），使其不要去共用這兩個(gè)邏輯核。但實(shí)際上在微觀層面，Carts2 和 tradePlatform2 的峰值會有差異，所以實(shí)際上影響還小。盡管這樣的 CPU 分配看起來有些“將就”；但物理資源總歸是有限的，也只能保持這份“將就”了。
而在 numa-aware 開啟時(shí)，為了最大化使用 L3 Cache 來提升計(jì)算性能，同一個(gè) POD 的更多核，又應(yīng)確保盡量規(guī)避跨 Socket。

而當(dāng)使用 CPUShare 時(shí)，Request 和 Limit 如何分配，也非常有學(xué)問；CPUSet 和 CPUShare 并存時(shí)，調(diào)度將更加復(fù)雜（例如：CpuSet 容器的新擴(kuò)容、或下線，潛在的訴求是整機(jī)所有 POD 的 CPU 重調(diào)度）；而在新興的 GPU 異構(gòu)調(diào)度場景下，CPU 與 GPU 的并存分配也具備一定的技巧。

5. 規(guī)模化編排調(diào)度

規(guī)模化編排主要應(yīng)用于建站、搬站或規(guī)模化遷移場景，例如阿里巴巴頻繁的大促建站、機(jī)房遷移訴求下的超大規(guī)模搬站等。基于成本考量，我們需要在盡可能短的時(shí)間，以極少的人力成本快速創(chuàng)建數(shù)十萬級別 POD。

多個(gè)任務(wù)依次請求的隨機(jī)性和不可預(yù)見性，決定了中心調(diào)度在規(guī)模化領(lǐng)域存在諸多弊端。在沒有規(guī)模化編排能力之前，阿里巴巴大規(guī)模站點(diǎn)的建設(shè)，往往需經(jīng)歷復(fù)雜的 “業(yè)務(wù)自擴(kuò)容 -> 反復(fù)重調(diào)度” 的過程，這將耗費(fèi)大量人力數(shù)周的精力。好在我們有了規(guī)模化編排調(diào)度，在小時(shí)級規(guī)模化交付效率的同時(shí)，又能確保 99% 以上的資源分配率。

通用調(diào)度能力

1. 重調(diào)度

中心調(diào)度器做到了一次性最優(yōu)調(diào)度；但與最終想要的集群維度全局調(diào)度最優(yōu)，是兩個(gè)完全不一樣的概念。重調(diào)度也包括全局中心重調(diào)度和單機(jī)重調(diào)度。

為什么一定需要中心重調(diào)度作為一次性調(diào)度的補(bǔ)償呢？我們舉幾個(gè)例子：

• ASI 調(diào)度集群內(nèi)存在眾多長生命周期的 POD 實(shí)例；隨著時(shí)間的積累，集群維度必將產(chǎn)生眾多資源碎片、CPU 利用率不均等問題。
• 大核 POD 的分配需要?jiǎng)討B(tài)的騰挪式調(diào)度能力（實(shí)時(shí)驅(qū)逐某些小核 POD 并空閑出資源）、或基于提前規(guī)劃的全局重調(diào)度，在眾多節(jié)點(diǎn)上預(yù)空閑一些大核。
• 資源供給總是緊張的。對某個(gè) POD 做一次性調(diào)度時(shí)，可能存在一定“將就”，這意味著某種瑕疵和不完美；但集群資源又是動態(tài)變化的，我們可以在其后的某個(gè)時(shí)刻，對該 POD 發(fā)起動態(tài)遷移，即重調(diào)度，這將帶來業(yè)務(wù)更佳的運(yùn)行時(shí)體驗(yàn)。

中心重調(diào)度的算法、實(shí)現(xiàn)上往往非常復(fù)雜。我們需要深入理解各類重調(diào)度場景并充分覆蓋，定義清晰的重調(diào)度 DAG 圖，動態(tài)執(zhí)行并確保執(zhí)行的成功率。

眾多場景也需要單機(jī)重調(diào)度。例如：CPU 精細(xì)編排的 SLO 優(yōu)化、基于 OQS 數(shù)據(jù)驅(qū)動的單機(jī)重調(diào)度優(yōu)化等。

需要強(qiáng)調(diào)的是，單機(jī)重調(diào)度的執(zhí)行，必須先解決安全風(fēng)控的問題，規(guī)避不可控的爆炸半徑。在單機(jī)側(cè)風(fēng)控能力不足前，我們建議您暫不要采用節(jié)點(diǎn)自治方式，而是改為嚴(yán)格保護(hù)控制下的中心統(tǒng)一觸發(fā)。實(shí)際上在 K8s 域內(nèi)，會出現(xiàn)非常多不可避免的節(jié)點(diǎn)自治場景（例如 pod yaml 變化時(shí)，Kubelet 將執(zhí)行相應(yīng)變更），過去 ASI 花費(fèi)數(shù)年持續(xù)梳理每一個(gè)潛在的風(fēng)控點(diǎn)，并迭代建設(shè)了分等級風(fēng)控管理（核按鈕、高危、中危等）的 Defender 系統(tǒng)；針對潛在風(fēng)險(xiǎn)項(xiàng)，執(zhí)行單機(jī)側(cè)動作前，與中心的 Defender 交互，通過安全防控規(guī)避災(zāi)難事件的發(fā)生。我們建議調(diào)度器必須同樣做到嚴(yán)密的安全防御等級，才允許節(jié)點(diǎn)自治操作。

2. 內(nèi)核調(diào)度

內(nèi)核調(diào)度存在的背景是：一臺并行運(yùn)行著眾多任務(wù)的繁忙宿主機(jī)，即使中心調(diào)度 & 單機(jī)調(diào)度，已共同確保其最佳資源分配（如 CPU 分配、IO 打散等），但實(shí)際運(yùn)行時(shí)，多任務(wù)間不可避免地進(jìn)行內(nèi)核態(tài)的資源爭搶，在大家熟知的在離線混部場景中競爭尤為激烈。這就需要中心調(diào)度、單機(jī)調(diào)度、內(nèi)核調(diào)度 通過眾多協(xié)同，例如統(tǒng)籌任務(wù)的各類資源優(yōu)先級，并交由內(nèi)核調(diào)度控制執(zhí)行。

這也對應(yīng)眾多內(nèi)核隔離技術(shù)。包括 CPU：調(diào)度優(yōu)先級 BVT、Noise Clean 機(jī)制等；內(nèi)存：內(nèi)存回收、OOM 優(yōu)先級等；網(wǎng)絡(luò)：網(wǎng)絡(luò)金銀銅優(yōu)先級、IO 等等。

在今天我們還有了安全容器。基于安全容器的 Guest Kernel 和 Host Kernel 隔離機(jī)制，我們可以更優(yōu)雅地規(guī)避內(nèi)核運(yùn)行態(tài)的部分爭搶問題。

3. 彈性調(diào)度、分時(shí)調(diào)度

彈性和分時(shí)的邏輯都是更好的資源復(fù)用，只是維度不一樣。

ASI 調(diào)度器與阿里云基礎(chǔ)設(shè)施層充分協(xié)同，利用 ECS 提供的強(qiáng)大彈性能力，在餓了么場景，低峰期向云歸還資源，高峰期重新申請相應(yīng)資源。

我們可以使用 ASI 大資源池（注：ASI 資源池的宿主資源均來自于阿里云云資源）的內(nèi)置彈性 Buffer，也可以直接使用阿里云 IaaS 層的彈性技術(shù)。二者的平衡是一個(gè)很有爭議的話題，也是一個(gè)比較藝術(shù)的過程。

ASI 的分時(shí)調(diào)度更是將資源復(fù)用做到了極致，并帶來了巨大的成本優(yōu)化。通過每天晚上大規(guī)模停用在線交易 POD 實(shí)例，釋放的資源用于 ODPS 離線任務(wù)使用，每天早上離線任務(wù)退水并重新拉起在線應(yīng)用。這個(gè)經(jīng)典場景更是將在離線混部技術(shù)的價(jià)值發(fā)揮到最大。

分時(shí)的精髓是資源復(fù)用，以及依賴的大資源池建設(shè)管理，這是資源運(yùn)營 & 調(diào)度技術(shù) 的綜合。這需要調(diào)度器積累多多益善的豐富形態(tài)作業(yè)、以及多多益善的海量作業(yè)任務(wù)。

4. 垂直伸縮調(diào)度/X+1/VPA/HPA

垂直伸縮調(diào)度是一種秒級交付技術(shù)，非常完美地部分解決了突發(fā)流量問題。垂直伸縮調(diào)度也是大促零點(diǎn)峰值壓力風(fēng)險(xiǎn)的殺手锏，通過對存量 POD 的資源垂直調(diào)整、準(zhǔn)確可靠的 CPU 調(diào)度和洗牌算法來做到計(jì)算資源的秒級交付。垂直伸縮調(diào)度、VPA 技術(shù)一脈相承，垂直伸縮調(diào)度也是 VPA 的場景之一。

“X+1” 水平擴(kuò)容調(diào)度在某種意義上也可以理解為 HPA 場景之一，只不過 “X+1” 水平擴(kuò)容調(diào)度由手動觸發(fā)。“X+1” 側(cè)重于強(qiáng)調(diào)極致的資源交付效率，這背后是研發(fā)效率的極大提升：在線 POD“X（若干）”分鐘可啟動完畢提供業(yè)務(wù)服務(wù)；除應(yīng)用啟動外的所有其它操作，務(wù)必在 “1” 分鐘內(nèi)全部完成。

垂直伸縮調(diào)度與 “X+1” 水平擴(kuò)容調(diào)度互為補(bǔ)充，共同為各類峰值保駕護(hù)航。

ASI 也正在實(shí)施更多的 VPA 和 HPA 場景。例如，我們可以通過 VPA 技術(shù)，額外提供螞蟻春節(jié)紅包更多數(shù)量的免費(fèi)算力，這將是非常大的成本節(jié)約。

VPA/HPA 等調(diào)度技術(shù)更多場景的極致實(shí)施，也是阿里巴巴未來將繼續(xù)追求完善的地方。

5. 分等級[差異化 SLO]的資源調(diào)度

差異化 SLO 調(diào)度是調(diào)度器的精髓之一；這節(jié)內(nèi)容與上文中的【調(diào)度資源類型】章節(jié)存在一定的重復(fù)。鑒于差異化 SLO 的復(fù)雜度，所以有意將它放在本章的最后一節(jié)來講述。

ASI 調(diào)度器內(nèi)，也非常精確地定義了 SLO(服務(wù)質(zhì)量目標(biāo))、QoS 和 Priority。

1）SLO

SLO 描述的是服務(wù)質(zhì)量目標(biāo)。ASI 通過不同的 QoS 和 Priority 來提供差異化 SLO，不同的 SLO 有不同的定價(jià)。用戶可以根據(jù)不同的業(yè)務(wù)特性來決定"認(rèn)購"哪類 SLO 保障的資源。如：離線的數(shù)據(jù)分析任務(wù)，則可以使用低等級的 SLO 以享受更低的價(jià)格。而對于重要業(yè)務(wù)場景則可以使用高等級的 SLO，當(dāng)然價(jià)格也會更高。

2）QoS

QoS 描述了資源保障質(zhì)量。K8s 社區(qū)定義的 QOS 包括 Guaranteed、Burstable、BestEffort。ASI 中定義的 QOS，與社區(qū)并沒有進(jìn)行完全映射（社區(qū)完全用 Request / Limit 來映射）。為了能將集團(tuán)的場景（如 CPUShare，混部等）描述清晰，ASI 從另外一個(gè)維度定義了 QOS，它包括 LSE / LSR / LS / BE，清晰地劃分出不同的資源保障，不同的業(yè)務(wù)根據(jù)自身的延遲敏感度可以選擇不同的 QOS。

3）PriorityClass

PriorityClass 和 QoS 是兩個(gè)維度的概念。PriorityClass 描述的則是任務(wù)的重要性。

資源分配策略和任務(wù)的重要性（即 PriorityClass 和 QoS）會有不同的組合，當(dāng)然也需要存在一定的對應(yīng)關(guān)系。例如，我們可以定義一個(gè)名為 Preemptible 的 PriorityClass，其大部分任務(wù)對應(yīng)到 BestEffort 的 QoS。

各個(gè)調(diào)度系統(tǒng)對 PriorityClass 有不同的定義。例如：

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

全局最優(yōu)的調(diào)度

1. 調(diào)度模擬器

調(diào)度模擬器有點(diǎn)類似于阿里巴巴的全鏈路壓測系統(tǒng)，通過線上真實(shí)的流量回放、或模擬流量回放，在模擬環(huán)境驗(yàn)證調(diào)度新的能力，進(jìn)而不斷地錘煉各種調(diào)度算法，優(yōu)化各類指標(biāo)。

調(diào)度模擬器的另一個(gè)常見的用途是，是對線上疑難雜癥問題做線下模擬，做到無害、高效地定位各類問題。

一定程度上，調(diào)度模擬器是全局調(diào)度最優(yōu)的基礎(chǔ)。有了調(diào)度模擬器，我們得以在模擬環(huán)境，反復(fù)錘煉各種算法、技術(shù)框架、技術(shù)鏈路，進(jìn)而做到全局指標(biāo)的優(yōu)化，例如：全局分配率、不同場景下的調(diào)度性能、調(diào)度穩(wěn)定性等等。

2. Elastic Scheduling Platform（ESP 平臺）

為了做到全局最優(yōu)的調(diào)度，圍繞著調(diào)度器，ASI 構(gòu)建了一套全新的 Elastic Scheduling Platform（ESP 平臺），旨在圍繞調(diào)度器，打造基于調(diào)度數(shù)據(jù)指導(dǎo) & 核心調(diào)度能力 & 產(chǎn)品化調(diào)度運(yùn)營 的一站式自閉環(huán)調(diào)度效能系統(tǒng)。

在過去，我們已經(jīng)建設(shè)了諸多類似模塊，例如調(diào)度 SLO 巡檢、眾多調(diào)度工具、不同場景的二層調(diào)度平臺等；而基于 ESP 平臺，集合更多的二層調(diào)度能力，帶給 ASI 全局最優(yōu)的調(diào)度質(zhì)量，并圍繞 業(yè)務(wù)穩(wěn)定性、資源成本、用戶效能提升，帶給客戶更貼心的服務(wù)。

更多調(diào)度能力

本文嘗試著系統(tǒng)地講解 ASI 調(diào)度器的基本概念、原理和各種場景，并帶領(lǐng)您走進(jìn)調(diào)度器美麗精彩的世界。調(diào)度器博大精深，遺憾的是，受限于篇幅，也不得不控制篇幅，非常多的內(nèi)容點(diǎn)到為止并未深入展開。在調(diào)度器內(nèi)，還有更多更深層次的調(diào)度內(nèi)幕，如異構(gòu)機(jī)型調(diào)度、調(diào)度畫像、公平性調(diào)度、優(yōu)先級調(diào)度、騰挪調(diào)度、搶占調(diào)度、磁盤調(diào)度、Quota、CPU 歸一化、GANG Scheduling、調(diào)度 Tracing、調(diào)度診斷等眾多調(diào)度能力，本文均未予闡述。受限于篇幅，本文也未講述 ASI 強(qiáng)大的調(diào)度框架結(jié)構(gòu)及優(yōu)化、調(diào)度性能優(yōu)化等更多更深層次的技術(shù)內(nèi)幕。

早在 2019 年，ASI 已優(yōu)化 K8s 單集群至業(yè)界領(lǐng)先的萬級節(jié)點(diǎn)規(guī)模，并得益于阿里云 ACK 強(qiáng)大的 K8s 運(yùn)維體系，阿里集團(tuán)內(nèi)持續(xù)保有著數(shù)量眾多的大規(guī)模計(jì)算集群，同時(shí)也積累了業(yè)界領(lǐng)先的 K8s 多集群生產(chǎn)實(shí)踐。正是在這些大規(guī)模 K8s 集群內(nèi)，ASI 基于完善的容器調(diào)度技術(shù)，持續(xù)為眾多復(fù)雜的任務(wù)資源提供著計(jì)算資源算力。

在過去的數(shù)年，借助于集團(tuán)全面上云的契機(jī)，阿里集團(tuán)在調(diào)度領(lǐng)域，已實(shí)現(xiàn)了從 ASI 管控到阿里云容器服務(wù) ACK的全面遷移和進(jìn)化。而阿里集團(tuán)內(nèi)復(fù)雜、豐富、規(guī)模化的業(yè)務(wù)場景，未來也將持續(xù)輸出、增強(qiáng)并錘煉云的技術(shù)能力。

作者：黃濤、汪萌海

?

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。