近日，科技媒體 InfoQ 專訪了阿里雲統一排程團隊，詳細解讀了阿里雲排程系統演進歷程。2021年雙11統一排程系統打通並統一了阿里巴巴電商、搜推廣、MaxCompute 大資料和螞蟻業務，全面支撐了全球數十個資料中心、數百萬容器、數千萬核的大規模資源排程。本文轉載自InfoQ。
在阿里雲十三年的發展歷史上，重新設計排程系統算得上是一個重要的技術抉擇。
雲計算是一個龐大的技術工程。2009 年，阿里雲從 0 到 1 自建國產雲計算系統“飛天”，為了確保對每一行程式碼都有控制力，阿里雲選擇了一條艱難的道路：自主研發。伏羲排程系統是“飛天”三大服務之一。排程系統作為雲計算的核心技術，無論是對亞馬遜、谷歌還是其他雲計算企業來說，都是他們最保守的秘密，而伏羲憑藉自研與優異的效能，與 YARN、Mesos 等技術一起成為了排程系統的典型代表之一。
這麼多年發展下來，很多人認為阿里雲戰略上最與眾不同之處，就是堅持自研核心技術。作為全球叢集規模最大的雲計算平臺之一，阿里雲在技術已然成熟、穩定執行著數量龐大的業務的情況下，選擇了用雲原生的標準重新設計和構建雲計算的排程系統，並在 2021 年“雙十一”大促之前將全球幾十個資料中心、數百萬容器、數千萬核的資源統統搬到了新的排程系統之上。
阿里云為什麼在十三年之後重構排程系統？在不影響業務執行的情況下，阿里雲是如何更換“引擎”的？這種技術思路給我們帶來什麼啟示？新排程系統有開源計劃嗎？InfoQ 採訪了幾位排程系統負責人，為大家一一解惑。
發展十三年，成績斐然的老排程系統
資源排程系統可謂是雲計算的大腦，負責在眾多叢集內的機器裡，選擇一臺最合適的，以最佳的資源使用姿勢，做到最少的相互干擾來執行使用者提交的計算作業。雲計算最終目的之一是降低 IT 成本，最大限度地利用單臺 PC 的 CPU 處理能力，而排程系統恰恰就決定著基礎設施的利用率和整體運作成本。
無論是亞馬遜、谷歌、微軟還是阿里，某種程度上，“大腦”代表的是企業技術競爭力。核心技術的重要性不言而喻，像谷歌的排程系統 Borg，在很長一段時間內，一直是谷歌最保守的秘密之一。
艱難起步，從 0 到 1 自研伏羲排程系統
2008 年，阿里巴巴確定了“雲計算”戰略，決定自主研發大規模分散式計算作業系統“飛天”，目標是將幾千臺乃至上萬臺普通 PC 伺服器連線到一起，使其像一臺多功能的超級計算機，實現超強計算效能。
2009 年 2 月，飛天團隊在北京寫下了第一行程式碼，“飛天”系統也從此成為阿里雲的奠基技術平臺。伏羲排程系統是十年前飛天成立時建立的三大服務之一，另兩個是飛天分散式儲存盤古和分散式計算 MaxCompute。
2011 年 7 月，阿里雲作為中國第一個公有云正式對外開放。這之後的十多年裡，伏羲能排程的單叢集規模，也從最初的幾百臺物理機，發展到了 10 萬臺機器。我們知道，規模每放大十倍，就意味著很多架構設計點都需要重新調整，當橫向擴充套件遭遇不可逾越的瓶頸，就代表著系統重構的開始，伏羲就因此經歷了兩次重構。
2013 年，伏羲在飛天“5K”專案中對系統架構進行了第一次大重構。“5K”顧名思義，就是能讓排程系統支援單叢集 5000 節點，並解決大規模單叢集下的效能、利用率、容錯等問題。
不斷擴大單叢集的規模，到現在依然是業界不同調度系統在做的事情。
如果依靠早期的 Hadoop 開源排程器技術，以當時的實踐經驗來看，並不是容易的事情，因此伏羲團隊選擇了架構和程式碼都是自己構建的自研方式。這個專案，在阿里雲歷史上也是一次非常有里程碑意義的“攻堅戰”。
（阿里飛天 5K 專案紀念碑）
隨後歷經一年半時間，阿里巴巴和螞蟻金服完成“登月計劃”，將所有資料儲存、計算任務全部遷移至飛天平臺。在 2015 年 Sort Benchmark 排序競賽中，飛天用 377 秒完成 100TB 的資料排序，打破四項世界紀錄。
隨著阿里雲的業務需求變化，伏羲的內涵也在不斷擴大。最開始是作為一款對標開源 YARN 的單一資源排程器，而後擴充套件成了覆蓋資料排程、資源排程、計算排程、單機排程等的核心排程系統，伏羲也於 2019 年經歷了第二次重構，並將單叢集規模擴充套件到了十萬臺。
雙排程系統混部實踐
伏羲是負責阿里離線業務的排程系統，而於 2015 年正式立項的 ASI 排程器則支撐著阿里搜尋、電商等龐大的線上業務。
線上排程歷史也比較悠久，最早起源於 2011 年上線的 T4 系統，即阿里早期基於 LXC 和 Linux Kernel 定製的容器排程器。T4 的技術理念與如今雲原生領域的核心技術——容器，如出一轍。線上排程最開始是一個簡單的資源分配系統，而後逐漸演進為 Sigma 排程器、ASI 排程器，在發展過程中又進一步吸收並融合了伏羲離線排程系統、搜尋團隊基於 YARN 的 Hippo 系統的先進經驗。
0 層排程器負責全域性資源檢視和管理並對 1 層排程器 Sigma、伏羲進行仲裁
據稱全球伺服器平均利用率不到 20%，因此提升伺服器的資源利用率是很多大廠不斷追逐的目標。
2014 年左右，阿里巴巴開始大力探索混部技術，透過將線上業務和離線大資料計算的負載混部執行在共享的叢集中，以期可以顯著提高資料中心資源利用率。與離線排程不一樣的是，類似雙十一活動中的零點峰值場景，它對線上排程 CPU 的叢集化編排要求非常高，對延遲和抖動敏感；離線業務正好相反，平時資源使用壓力較高，業務資源使用較為固定，對時延不敏感。所以，只要兩類負載能跑在共享的叢集中使用“分時複用”的策略，就可以達到提升利用率的目的。
正是因為線上離線混部對於提高叢集利用率非常有意義，所以無論是在學術界，還是在各大廠商實際落地中，都對混部做了深入的研究，各大企業中最早做混部實踐的是谷歌 Borg。雖然有 Borg、Omega 先例存在，但谷歌很少對外分享自己的混部實踐，僅在 2015 年、2019 年對外發布過兩篇論文。這也意味著，如果想做好“混部”排程，企業都得靠自己去摸索。
阿里的混部實踐也於 2015 年正式立項，
並於當年的雙十一經歷了一次資源排程能力的“考驗”。據公開資料顯示，混部能將阿里雲的 CPU 資源利用率從 10% 提升到 40%。
作為自研的排程系統，伏羲和 Sigma 執行在一起，這種混部系統形式曾存在很多幹擾和影響，一方面是兩個系統之間節點狀態不一致造成的干擾，另一方面是兩個系統所分配的容器互相之間的干擾。然而“混部”帶來的收益又不可忽視，因此阿里於 2016 年開始重點研發了 Sigma 1。0，基於 Docker Swarm 通道建立容器，並將演進中的各種語言技術棧統一為 Golang，同時在實踐層面做了很多隔離、協同的最佳化工作，也將不同等級的任務排程做得更精細化。
整個演進過程中，排程團隊也曾將實踐成果分享為數篇頂會論文，得到了學術界和工業界的認可。有意思的是，谷歌曾在 2019 年 11 月分享了 Borg 叢集執行資料，在對應的論文中谷歌特地指出其系統很少在叢集中使用超過 50% 的記憶體，但據報道競爭對手阿里巴巴達到了 80% 的利用率。
大船難調頭，阿里的排程系統發展了十多年，成果斐然，效能優異，執行的業務規模也是數千萬級別了。但 2021 年，阿里雲還是決定將伏羲、Sigma 雙排程協同系統重構為基於 ACK 的“統一排程系統”。
基於阿里雲容器服務 ACK 的排程系統
我們在技術上到達了一個新的臨界點。
2020 年 6 月，阿里雲集結了 100 多位排程團隊核心技術人員，開始了重構的程序。
經過一年多的研發，趕在雙十一之前，將數千萬量級的業務切換到了新一代的“統一排程系統”上。新框架基於阿里雲容器服務 Kubernetes 版（簡稱容器服務 ACK），透過一套排程協議、一套系統架構，統一管理底層的計算、儲存、網路資源。ACK 本身提供了一個全託管的 Kubernetes 叢集的排程能力，對於 IaaS 層不同型別的計算、儲存、網路等能力都可以統一排程，是統一排程大資源池化生產執行的基座。
2021 年雙十一，新系統打通並統一了阿里巴巴電商、搜推廣、MaxCompute 大資料和螞蟻業務，全面支撐了全球數十個資料中心、數百萬容器、數千萬核的大規模資源排程。
為什麼要重建？
Kubernetes 專案始於 2014 年，源自谷歌內部的 Borg，吸收了 Borg 專案多年的實踐經驗，它超前引入了 Pod 概念將容器分組，大量使用了 Sidecar 設計模式，為容器化應用提供了自動化的資源排程，並具備動態擴容、滾動升級、負載均衡、服務發現等功能，受到大廠的大力推崇。
在接下來的兩年裡，與其對應的 Mesos、Docker Swarm 等相比，Kubernetes 作為容器編排引擎的採用緩慢卻很穩定，領先的科技巨頭如亞馬遜、阿里巴巴、微軟 Azure、紅帽都開始啟動了基於 Kubernetes 的新解決方案。
2019 年，Sigma 全面遷移到了基於 ACK 的排程系統。同時，在這幾年裡，阿里的技術體系也逐漸全面切向雲原生技術，去年 9 月，阿里雲容器服務全面升級為 ACK Anywhere。
據
線上排程系統負責人智清
回憶，線上排程系統最初是完全自研的，雲原生興起之後，線上排程團隊於 2017 年決定將這套技術框架遷移到 Kubernetes，消除兩者之間的差異並跑在阿里雲容器服務 ACK 上。“剛開始是比較艱難的，嘗試過好多版本，包括 Sigma on Kubernetes、Kubernetes on Sigma 等方式，最後還是決定用最標準、最原生的、完全基於 Kubernetes 的方式。”
後面啟動的 ASI 專案，它做的事情就是將整個排程框架以非常原生的標準方式搬到 Kubernetes 上，在 Kubernetes 基礎上做到線上、離線排程的真正融合。而且在業務側，阿里也專門組織了一支雲原生團隊來推進容器化，最終形成一個整體的雲原生資源池。
雲原生統一排程架構師懿川
將這些年排程系統的發展過程總結為三個階段：
第一個階段是非容器階段，
僅有排程的需求，並且基礎設施還沒有完善，屬於排程的最初期階段。在這個階段，無論是伏羲還是 T4，基本都是藉助一些比較簡單的隔離概念，以及一些核心的能力，靠自身的演進來實現對排程的最樸素的需求。
第二個階段是開始進入容器階段。
容器技術使用場景變多，規模變大，Sigma 以容器為主進行了改造。在這個階段，需要排程系統既能承接業務的需求，又能同時深耕容器技術。
第三個階段是雲原生化，
排程系統完全基於新一代的容器技術，包含阿里自己的安全容器、RunC 以及其他的虛擬化技術，同時排程器的實現框架上也需適應整個 Kubernetes 生態。也就是將電商、搜尋和大促這種創造洪峰型的業務，以及十多年排程系統技術積累，再結合 Kubernetes 開源架構的優勢，整合到一起進行大規模應用。
總而言之，阿里重建排程系統的決策，是基於業務演進的需要，也是希望能有一個全域性資源池，統一支撐所有業務形態。
雲計算的本質，是將小的計算碎片變成更大的資源池，充分削峰填谷，提供極致的能效比。混部技術打破了多資源池的割裂，不同計算領域的多排程大腦協同共用資源，讓業務間峰谷互補的優勢發揮到最大，但兩個排程器，由於彼此間無法高效地互動細粒度資訊，阻礙了混部效果的進一步提升。
另外排程成本、資源的排程效率和業務獨佔資源池有很大的關係。從過去的排程系統演進經驗來推斷，建設統一資源池是最好的提升效率的方法：業務上有很多共同性的排程需求是可以互相配合和最佳化借鑑的，各自演進並不利於發展。無論是搜尋還是電商，線上還是離線，如果作業型別越來越相近的話，就可以透過合作和共建，作為同一種排程型別去建設和演進，集中力量將雲原生終態方案一起做到極致，並希望最後能做到自研、商用、開源三位一體。
雙排程系統協同的方式跟谷歌的 Borg 或微軟的系統相比，在叢集管理模式上有一定的區別，那是否是因為雙排程系統協同模式存在缺陷才會導致重構？懿川認為排程系統的發展和業務形態密切相關。國內很多企業確實會存在擁有多種排程系統的情況，原因是線上業務和離線業務特點有很大的不同，效能、吞吐量、任務長短型別等，以及對排程業務的需求決定了排程器的架構設計。
“反倒是做成一個統一的排程系統是比較難的，做成多種排程系統相對來講更容易。而且類似谷歌的Borg或微軟的Apollo系統一開始也不是所有的排程策略、邏輯以及場景都能支援，也有一個在演進過程中逐步增加功能的過程。”
新排程系統對 Kubernetes 的改進和增強
新排程系統需要支援線上離線、低頻高頻各種排程型別和眾多業務種類，且要完全相容 Kubernetes 生態，還需要是模組化、元件化，形成一個可插拔式的機制。
統一排程團隊針對 Kubernetes 社群版在 Pod 和資源安全上做了很多最佳化，圍繞 API Server、ETCD、Kubelet 做了不少功能最佳化和程式碼修改。統一排程在 Pod 和介面呼叫上也做了很多安全防禦方面的事情，例如 ETCD 錯配或出現其它問題時如何進行防護，從而保證底座平臺的安全。但最重要的兩方面改造在單叢集規模、排程頻次效能上。
Kubernetes 早期版本僅支援幾百節點的單叢集規模，與 Mesos 支援的節點數量相去甚遠，各大廠集合力量一起大幅提升了 Kubernetes 的叢集管理規模，到 1。9 版本就已可以穩定支援 5000 個節點，但遠達不到阿里原來排程系統單叢集上萬節點的效能要求。並且 Kubernetes 以 API Server 為中心的訊息同步機制，更適用於排程頻度較低的線上服務場景，對於阿里系統中的大資料計算場景，可達每秒 10 萬次的排程頻度。所以“儘管 Kubernetes 已經演進很久了，但是在我們的排程器上仍然需要投入大量的工作來改造，才能夠滿足我們的要求。”
如果要問哪些歷史經驗有助於新系統重構的話，
叢集管理規模的突破
必定是其中之一。
2013 年的飛天 5K 專案，已經早早突破了單叢集 5000 節點的規模。在後面的演進中，伏羲再次經歷了第二次重構，據
伏羲分散式排程負責人李超
回憶說，當時主要考慮到“現在叢集的規模可能動不動就過萬臺，不光是物理節點在增加，CPU 的處理能力也在不斷增強。5 年前一臺物理機上一般二三十個 CPU core，現在一臺物理機節點裡已經變成了一百多個 CPU core 了。相當於即便物理機節點不增加，可排程的總資源擴大了五六倍，甚至擴大了一個數量級，這對排程的挑戰是很大的。”
“如果規模無限擴充套件下去，在架構和設計上也要有一個應對的方案。隨著規模繼續變大，我們也要 Hold 得住。”
在伏羲 2。0 資源排程的重構裡，伏羲團隊提出了一些比較新穎的觀點，在混部中引入去中心化的多排程器架構，基於悲觀鎖這種 Partition 策略，解決排程之間的衝突，保證排程 latency 效能達到與小規模下的系統相同的水平。
但 Kubernetes 單叢集規模有限，遠不能滿足今天的訴求。統一排程團隊透過對 API Server 和 ETCD 的演算法最佳化、在服務端進行資料壓縮以及鏈路治理的方式，將叢集規模從8千臺（2020年）擴充套件到1。2 萬臺（2021年）節點，而業界一般達到8千臺就已經是超大規模。
此外，由於 Kubernetes 容器拉起的時間在幾秒甚至幾十秒，如果需要做到一秒鐘有十萬次的排程，也必須對其進行大量改造。
統一排程團隊參考了 Kubernetes 社群 scheduler framework 外掛化和多排程機制，透過靈活的排程框架讓不同的排程團隊可以定製各自的排程需求，從而讓 Kubernetes 能夠很好的去支援一些場景下的
大規模高併發的排程需求
。比如在阿里大資料場景下，對排程系統的要求是每秒鐘能發生十萬次排程。
飛行中更換引擎
2021 年雙十一之前，伏羲和 ASI 排程系統中的機器和計算資源已遷移到了統一排程系統，僅伏羲就包含幾萬臺機器、數百萬核計算資源，遷移過程需全程對業務和使用者透明無感。
同時這個系統本身是一個涉及非常多人的協同專案，中間涉及到一次完整的系統重新設計和實現，還要將原有積累的伏羲、Sigma、ASI 以及 Hippo 的設計經驗融合進來，且保持對業務的相容性和對開源框架的相容性。
可以說，整體設計非常複雜，程式碼開發涉及的耦合也很高，各個系統之間還存在各種對接。
以伏羲為例，在阿里 MaxCompute 技術體系中，伏羲一方面是分散式系統的資源管理和排程元件，需要與上層作業執行引擎進行資源互動，另一方面也是各種運維管控的資料來源，複雜的模組依賴決定了系統升級是一件非常艱鉅的事情。如果將 MaxCompute 比作一架高速飛行的飛機，統一排程升級就是要給這架飛行中的飛機更換引擎，難度可想而知。
“留給我們上線的時間視窗很小，但整體的業務要求卻很高。雙十一的時間點是擺在那裡的一個硬性指標，我們不可能錯過。”懿川介紹專案背景時講到。
在這種情況下，要讓新系統在“雙十一”大促中表現得更有保障，李超表示主要有兩大技術舉措：
第一是灰度上線之前，有專門的風洞測試機制，
它能把歷史上真實生產的一些需求、請求在測試環境去做回放（Replay），從而驗證經過新一輪的修改或者新的功能後系統是否能穩定上線。
第二是在穩定性上，在狀態的可恢復上，
傳統的方式是基於 Kubernetes ETCD 的持久化機制，但是因為大資料的排程頻率達到每秒十萬次的排程，這種狀態要做持久化保障是比較困難的。新系統引入了軟硬狀態 fail over 機制，簡單來說是基於這個狀態的重新收集，而不是完全依賴於狀態的持久化。在不同的角色上去收集狀態，重建排程器當時的狀態。
另外在工程上也需要一套很嚴格的實施和上線機制：
保證程式碼高質量和低缺陷率，並做好全面的單元測試，
平時基本功紮實才能保證最終的工程質量。
上線之前，用接近真實生產的環境進行測試和驗證，確保能夠跑通，
如果出現問題及時解決和處理，符合整體的上線進度。“我們最後上伏羲叢集的過程中，出現的問題都是日清日結，讓問題快速收斂，保證整個叢集的交付可以符合要求。”
分階段灰度測試。
第一階段用小規模的遷移，“當時只是用幾十臺節點機器統一排程跑起來，再到後面就逐漸放大規模”，而且還需要先從重要程度相對低的業務開始切換，並保證足夠長的灰度時間，最後才在線全面鋪開，沒問題後再將更復雜的離線排程引入混部執行。
保證每天有一定的切換量，最終將系統按時切完。
“當然這也有一定運氣成分在：我們沒有出現特別嚴重的問題，這也非常考驗整個專案成員的設計和實現的功底。當然也需要我們有整體的機制和流程的保障。”
系統需要一個完善的監控機制。
“上線一個系統之前，我們先得想好怎麼去監測它。觀測方方面面的上百個維度的元資料是不是正常，透過完善的監測，系統一旦出現問題，我們能第一時間發現，做一些回滾動作，或者提前準備好一些處理機制，來保證使用者受到影響之前系統能夠恢復到一個正常的狀態。”
未來規劃
每個技術都有自己的生命週期，十多年前大家很難想到 Kubernetes 會成為當今技術界的扛把子，而技術演進過程中，開發者的使命就是用最合適的技術來構建我們的系統。使用新技術不代表過去的經驗和成果不再有價值，統一排程系統也汲取了伏羲和 Sigma 系統構建中的精華。
開源技術影響著排程系統的演進，而部署在大型企業生產環境中的系統，無論是谷歌的Borg、微軟的Apollo 還是臉書的Twine，反過來也在影響開源專案的系統演進。統一排程團隊表示，未來會進一步提升和完善整個排程器的功能和能力，繼續往2。0推進；另一方面，要完成自研、商用、開源三位一體的目標，作為戰略計劃推進專案的開源，包括開源核心程式碼和關鍵能力。建設這樣一個超級系統，投入和挑戰都非常大，而開源能夠將更多的人聚集起來，一起把這套系統做得更好。（正文完）
採訪嘉賓簡介
懿川，
阿里巴巴研究員，雲原生統一排程架構師。全面負責統一排程專案，在分散式領域和資源管理領域有多年的經驗積累。
李超，
阿里雲智慧計算平臺事業部資深技術專家，飛天平臺伏羲分散式排程負責人，擁有十多年分散式系統與大資料研發經驗。
智清，
阿里雲智慧容器服務資深技術專家，ASI 排程系統負責人，負責了阿里巴巴線上排程從 Sigma、ASI、到全面統一排程的迭代演進。
阿里云為什麼在十三年後重構排程系統？
