背景概述
每年雙十一創造奇迹的背後，是巨大的成本投入。為了完成對流量峰值的支撐，我們需要大量的計算資源，而在平時，這些資源往往又是空閑的。另一方面，為了在極端情況下，如機房整體斷電等還能保障阿裡巴巴的業務不受損失，也需要在全國各地建立備援資源。而且就算是一天當中，線上服務的負載也是不一樣的，白天一般情況下要比淩晨高得多。根據蓋特納和麥肯錫前幾年的調研資料，全球的伺服器的CPU 使用率隻有 6% 到 12%。即使通過虛拟化技術優化，使用率還是隻有 7% －17%，而阿裡巴巴的線上服務整體日均使用率也在 10% 左右。
另一方面，全球從 IT 時代全面走向了 DT 時代，現在又在向更深入的 AI 時代邁進。各各樣的大資料處理架構不斷湧現，從 Hadoop 到 Spark，從 Jstorm 到Flink，甚至包括深度學習架構 Tensorflow 的出現，成千上萬的資料分析背後是大量的計算任務，占用了大量的計算資源。由于計算任務占用的計算量很高，CPU 水位通常在50%-60% 以上，不同于線上服務，計算任務的峰值通常出現在淩晨，水位甚至能達到 70% 以上。是以我們往往就會建立獨立的計算任務叢集。
很多人都被車堵過，而堵車的時候，并不是所有的車道都在堵車。有一個比較有趣的情況，我們稱之為潮汐現象，而它造成的問題是在早高峰的時候是進城方向堵車，而晚高峰是出城方向堵。而為了緩解這個問題，我們使用了潮汐車道的方式。
那麼同樣的原理，是否如果能讓這兩個叢集混合起來部署，讓計算任務的一部分任務跑到線上服務的資源之上，把線上服務空閑的資源利用起來呢？答案是肯定的。
混部技術簡介
混部技術示意圖
把叢集混合起來，将不同類型的任務排程到相同的實體資源上，通過排程，資源隔離等控制手段 , 在保障 SLO 的基礎上，充分使用資源能力，極大降低成本，我們稱這樣的技術為混部（Co-loaction）。
打個比方，跑在容器裡的線上服務就像石塊；而計算任務我們把它比喻成沙子和水。當線上壓力小的時候，計算任務就占住那些空隙，把空閑的資源都使用起來，而當線上忙的時候，計算任務就立即退出那些空隙，把資源還給線上業務。這樣的技術一方面在平時，我們可以極大地提升資源的使用率；另一方面，在大促活動需要突增線上伺服器的時候，又可以通過線上業務占用計算任務資源的方式，來頂住那短暫的峰值壓力。
從原理中我們可以看到可以混部在一起的任務有兩個比較重要的特征：
1.可以劃分優先級：一定需要優先級比較低的任務，它們能像水和沙子一樣，随時能被趕走，而不會受到不可承受的影響，讓優先級高的任務不受幹擾。線上的特點是：峰值壓力時間不長，對延時比較敏感，業務的壓力抖動比較厲害，典型的如早上 10 點的聚劃算活動，就會在非常短的時間内，造成交易叢集的壓力瞬間上升 10 幾倍，對于穩定的要求非常高，在混部的時候，必須要保證線上的通暢，需要有極強的抗幹擾能力。而計算任務的特點是：平時的壓力比較高，相對來說計算量可控，并且延遲不敏感，失敗後也可以重跑。至少需要幾分鐘跑完的計算任務，相對于幾秒甚至幾十秒的延遲，并不會産生嚴重的問題，正好可以承提起水和沙子的角色。
2.資源占用互補性：兩種任務在不同的時間點對水位的占用不一樣。如線上服務是，平時比較低，大促時比較高；淩晨比較低，白天比較高。而計算任務則反過來，平時比較高，大促時可以降級；淩晨非常高，白天卻要低一些。
這種方式帶來的成本節省是非常巨大的：假設資料中心有 N 台伺服器，使用率從R1 提高到 R2，不考慮其他實際制約因素的情況下，節約 X 台，那麼理想的公式是：
N*R1 = (N-X)*R2
=> X*R2 = N*R2 – N*R1
=> X = N*(R2-R1)/R2
也就是說如果企業有 10 萬台伺服器，使用率從 28% 提升到 40%，代入上述公式，就能節省出 3 萬台機器。假設一台機器的成本為 2 萬元，那麼節約成本就有6 個億。
2015 年，Google 發表了 Borg 論文，其中就提到了線上服務與計算任務之間的混合運作，也就是我們說的混部技術。Borg 論文中描述了 Google 由于采用了這項技術，為 Google 節省了 20%-30% 的機器規模。
混部技術的曆程
阿裡巴巴早期混合雲架構
大家都知道這今年阿裡巴巴雙十一的交易峰值是每秒 32.5 萬比，相比去年幾乎增加了 1 倍，但是這樣的高峰卻隻有 1 小時左右。為了讓交易的成本降低，從 2014年開始，我們一方面通過阿裡雲的公有彈性雲資源降低成本，另一方面也開始研究混部相關的技術。
混部能産生這麼大的幫助，可是業界能使用在生産的沒有幾家公司，其原因也非常簡單，第一個是規模，第二個是技術門檻。當你機器規模不夠大的時候，顯然意義不大。而在技術上，計算型任務通常都可以把使用率跑到很高，如果計算型任務和線上型業務運作在同一台機器上，怎麼避免計算型任務的運作不會對線上型業務的響應時間等關鍵名額不産生太大的影響呢，這個需要在技術上有全方位的突破，而阿裡巴巴從無到有，花了 4 年多的時間才讓這項技術在電商域得以大規模落地。
2014 年，我們最主要的工作是進行技術論證，方案設計，以及相關的一些實驗性研究
2015 年，我們開始了日常測試環境的測試工作。這一期間讓我們總結了相當多的問題：如排程融合問題、資源争搶隔離問題、存儲依賴問題、記憶體不足問題等等
2016 年，當我們把大部分問題都解決掉時，我們開啟了線上 200 台左右的小規模驗證。由于電商的金融屬性，對于抗幹擾要求特别高，在不斷的業務考驗下，我們不停地修正着技術方案
2017 年，經過一年的磨合，混部的整體技術終于走向了成熟和大規模生産。阿巴巴雙十一當中，約有 1/5 的流量是跑在混部叢集之上
混部非混部叢集資源使用對比圖
在日常情況下，我們可以把線上服務的叢集的 CPU 使用率從非混部的 10%提升到混部的 40% 以上，整體的成本節省在 30% 以上。而線上受到的幹擾在 5%以内。
混部非混部叢集平均服務響應時間對比圖
混部排程的架構
混部排程的架構示意圖
在混部叢集中，我們的兩個排程平台同時自主運作，sigma 管理線上服務容器的排程，而 Fuxi 管理 ODPS 上的的計算任務。為了讓這兩個排程器能一起進行工作，在中間我們使用了零層與零層管控來協調兩者之間的資源配置設定。
1. 線上服務容器排程器 Sigma 的特點是：
相容 Kubernetes 的 API，和開源社群共建
采用阿裡相容 OCI 标準的 Pouch 容器
經曆過阿裡多年的大規模使用和雙十一的驗證
2. 計算任務排程器 Fuxi 的特點是：
面向海量資料處理和大規模計算類型的複雜應用
提供了一個資料驅動的多級流水線并行計算架構，在表述能力上相容 MapReduce，Map-Reduce-Merge，Cascading，FlumeJava 等多種程式設計模式
高可擴充性，支援十萬以上級的并行任務排程，能根據資料分布優化網絡開銷。自動檢測故障和系統熱點，重試失敗任務，保證作業穩定可靠運作完成
3. 通過零層的資源協調機制，讓整個叢集平穩地管理并運作進來：
混部叢集管理
各排程租戶之間的資源配比
日常與壓測大促等時段的政策
異常檢測與處理
混部的資源隔離
在混部中，放在首位的就是資源隔離問題，如果隔離問題沒做好，競争問題沒解決，那就很容易引發線上的問題。輕一點，讓使用者的感官體驗變差；重一點，引發線上故障，造成無法服務的惡劣影響。
而解決資源競争的問題，主要從兩個方面出發：
1.排程：通過資源畫像的技術，在資源真正發生競争之前，就預測規劃好，盡量減少這種情況發生的可能性。它是主動觸發，可以不斷優化，但延時較高。
2.核心：在資源真正發生競争的極端情況下，根據任務的優先級，如何做到既能保障高優先級任務不受影響，又能控制影響到的低優先級任務傷害最低。它是被動觸發，保底的必須手段，生效快。
在排程上，我們主要從以下方面進行優化：
1.日常的分時複用：由于波峰波谷的存在，線上服務與計算任務在一天中的峰值正好可以産生互補的情況，是以我們可以通過白天夜晚的分時複用提高資源的使用效率。
對叢集進行資源使用的畫像
線上服務淩晨 1-6 點為低峰，離線是高峰，針對這一特性進行水位調整
通過線上服務資源畫像智能挑選空閑容器進行 offline 處理
2.大促的分時複用：電商類業務由于大促的存在，在大促或壓測的時候會産生比平時高幾倍十幾倍的壓力差，如果這個時候對計算任務的資源進行降級讓給線上服務全使用，就可以輕松地支撐起那短暫的脈沖壓力。
日常态，計算任務占用線上服務的資源
大促态，線上服務占用計算任務的資源
1 小時快速完成切換，提高資源的利用
3.無損有損降級：線上服務會有一些特定的業務高峰時間，比如壓測，比如大促等。那麼如何在降級計算任務的時候，帶來的影響盡可能小呢？這裡我們就需要對降級的方案做特殊的處理。
無損降級：由于線上服務的 NC 平均使用率不高，再加上 70% 的計算任務小于 3 分鐘，那麼隻要壓測或大促在降級之後的 5 分鐘，計算任務對于線上服務的幹擾就不會那麼大了。另一個問題是做到分鐘級的恢複，這樣隻有當線上服務的真正高峰才會受到影響，而這個時間段又是比較短的，那麼影響就會降低。
有損降級：當線上服務受到嚴重影響的時候，我們也可以做到秒級的 Kill，迅速恢複，讓線上服務的影響降到最低。
4.計算任務選取：計算任務我們比喻成沙子，但是沙子也有大有小，也需要對沙子進行篩選，才能把空隙填充滿但又不溢出。
對作業進行資源使用的畫像，分析出作業需要消耗的資源。
通過 0 層來獲得主控端剩餘的确切計算資源能力
挑選符合條件的最佳作業，盡可能最大利用，也盡可能降低競争。
5.動态彈性記憶體：由于我們的存量資源并沒有考慮到混部，記憶體與 CPU 都是按照線上服務原來的使用配比，并沒有富餘的記憶體存在，但是由于計算增加了，記憶體就成了瓶頸，原來線上服務以靜态配置設定記憶體的方式就不再适合。
線上服務的記憶體加入共享分組
基于線上服務的實際記憶體使用，動态調整計算任務占用的記憶體水位
當線上服務壓力突增時，通過遷移或 Kill 任務的方式，自動降級計算任務的記憶體水位。計算任務釋放記憶體後，核心馬上進行資源回收
當整機發生 OOM 時，優先殺計算任務中優先級低的任務
6.存儲計算分離：線上服務是重 IOPS，但是存儲量不大，是以使用的都是SSD 的小盤；而計算任務都是重存儲量，但 IOPS 不大，是以使用的都是HDD 的大盤。而在混部的時候，如果還是以本地盤的方式來處理資料，計算混雜在一起，對于排程複雜度是幾何級的提升。是以我們需要把本地盤虛拟化成統一的存儲池，通過遠端的方式，根據不同的需求通路不一樣的儲存設備。另外阿裡也開始大規模建設 25G 的網絡設施，整個網絡能力提升，也讓遠端通路變得像本地一樣快。
核心隔離，我們主要從以下方面進行處理 :
1. CPU 排程優化：這是隔離當中最重要的一項，當線上業務使用 CPU 壓力上升，計算任務必須要毫秒級的自适性退出。
● CPU 搶占
○ 按照 CGroup 配置設定優先級 (cpu.shares)
○ 高優先級任務可以搶占低優先級任務的時間片
● 規避 HT（noise clean）
○ 避免離線任務排程到線上任務相鄰的 HT 上
○ 保證已經運作的離線任務在線上任務于相鄰 HT 上喚醒後遷走
● L3 Cache 隔離
○ 通過 BDW CPU 的特性 CAT 來進行對 Cache 通路的流量控制，進而達到
限制低優先級計算任務對 CPU 的占用。
● 記憶體帶寬隔離
○ Memory Bandwidth Monitoring ，通過時實監控來進行政策調整
○ Cfs bandwidth control 調節計算任務運作時間片長度。通過縮短時間片，
讓高優先級任務更容易獲得占用 CPU 的機會。
2. 記憶體保護
● 記憶體回收隔離
○ 按照不同的 CGroup 配置設定優先級
○ 增加組内回收機制，避免全局記憶體回收幹擾線上任務
○ 按優先級确定記憶體回收的權重，線上任務的記憶體被回收的更少
● OOM 優先級
○ 整機 OOM 時，優先殺低優先級任務
3. IO 分級限制
● 檔案級别的 IO 帶寬隔離 ( 上限 )
○ 新增 blkio 的控制接口
○ 限制 IOPS，BPS
● 檔案級别的保低帶寬 ( 下限 )
○ 允許應用超出保底帶寬後使用富餘的空閑帶寬；
● Metadata throttle
○ 限制特定操作的 metadata 操作，例如一次性删除大量小檔案。
4. 網絡流量控制
● 帶寬隔離
○ 隔離本機帶寬（TC）
○ Pouch 容器間的帶寬隔離
● 帶寬共享（金、銀、銅）
○ 在離線間可以存在共享帶寬
○ 程序間按照優先級可以搶占帶寬
混部的未來規劃
混部技術經過四年的磨煉，終于在 2017 支撐起了阿裡巴巴雙十一核心交易流量的 20%，并且也作為阿裡巴巴未來資料中心建設的标準技術。而在未來的一年中，混部技術會向更精細化的排程能力演進。
在場景上，會更多元化，無論是實時計算，還是 GPU，甚至是 FPGA，都能夠混部在一起。在規模上，也會從十萬核級别的叢集往百萬核級别的叢集擴充。在資源畫像能力上，會引入更多的深度學習，提高預測的準确性，為使用率再次大幅度提升打基礎。在排程能力上，會建立更加完善的優先級體系，在資源配置設定與協調上不會以線上服務和計算任務來差別，而是以通用的優先級來排程，解決更多資源類型部混問題。總結一句話，讓混部真正成為排程的一種通用能力。
原文釋出時間為：2018-02-12
本文作者：潇謙