資料中心日均 CPU 利用率 45%？！阿里規模化混部技術揭祕

阿里妹導讀：混部技術在業界還尚屬於較少研究的領域，該技術只有在資源及成本的體量達到一定規模時，才會顯現出其可觀的技術紅利。今天，阿里系統軟體部技術專家蔣玲從阿里巴巴混部探索簡介、混部方案及架構以及混部核心技術等幾個方面帶大家全面瞭解混部技術，希望對你有所啟發。

作者簡介：蔣玲(玲昕)，阿里系統軟體部技術專家、大促自動化備戰產品負責人、電商規模化混部專案負責人。

一. 阿里巴巴混部探索簡介

混部技術的出發點，源自於對不斷增長的業務和日益攀升的資源成本如何平衡的思考，我們希望用最小的資源成本，支撐更大的業務需求。是否能夠複用已有的存量資源，來滿足新增的業務，這就是混部技術發展的思想源頭。

1.1 為什麼做混部？

上圖是阿里巴巴從2009 年開始做雙十一購物狂歡節以來的歷年交易額曲線，對業務同學而言，這張曲線增長圖比較漂亮，但是對於技術人員和運維人員而言，這張圖背後意味著重大的挑戰和資源壓力。

對於做電商平臺型業務的業界同行，大家應該知道我們在做促銷活動時，技術壓力往往來自於開賣的第一秒，是一個脈衝式的洪峰流量。

阿里巴巴線上業務的雙十一零點峰值流量（通常用秒級交易建立量來描述）跟這張圖的曲線走勢基本吻合。從2012年往後的年份開始，0點峰值壓力基本是上一年的兩倍。可以看到線上側業務發展如此快，主要跟我們促銷活動密不可分。

除了線上型業務，阿里巴巴還擁有較大規模的離線計算型業務。隨著AI技術的興起，計算型業務也呈不斷上升趨勢。截止當前，我司大資料儲存量達到KPB級、日均任務量在百萬級。

業務不斷增長，在基礎設施層儲備了大量的資源以滿足線上型和離線業務的需求。由於線上型業務和離線型業務有很多不一致的資源使用特性，最初設計時由兩個獨立的資料中心來支撐，當前，兩個資料中心均已達到萬臺伺服器以上的規模。

然而我們發現，資料中心的資源體量雖然龐大，但有些資源的利用率卻並不樂觀，尤其是線上業務資料中心，日均資源利用率僅在10%左右。

基於以上背景，同時考慮到不同業務對資源使用和要求的差異性：一方面，不同業務具備不同時段峰值的特性（分時複用資源）；另一方面，對資源被響應的容忍度不一（資源按優先順序競爭和搶佔），促使我們探索不同業務混合部署的技術方向。

1.2 何為混部 ( Co-location )？

簡而言之，混部技術就是：將不同型別的業務進行混合部署，用一份資源同時提供兩份不同業務的資源當量的技術。

混部技術首先，是資源整合，把原本物理分離的業務部署於統一的物理資源上；

其次，進行資源共享，同一份資源，既支撐A業務，又支撐B業務，在A和B業務的視角，同時看到各一份的資源；

最後，是資源合理競爭，既然由原來的一份資源，一生為二，變成2份，必然存在資源的競爭，需要提供合理競爭的手段，使得不同資源需求的業務符合各自的服務要求。

混部最大的價值在於通過資源共享的方式充分複用資源，實現無中生有。而混部技術的核心目標在於出現資源競爭時，優先保證高等級的業務。因此，我們希望通過排程管控和核心隔離的手段進行資源充分共享和競爭隔離。

1.3 線上離線混部

線上型業務，在混部技術裡主要描述的場景是交易型業務、支付型業務、瀏覽型請求。

線上型業務的特性是實時性，對實時性的要求非常高，以及不可降級。如果使用者在選購寶貝的過程中，出現長時間等待（比如秒級別），很有可能該使用者就會放棄購買；如果需要使用者重試，估計就很難留存該使用者了。

線上型業務，尤其像我們做電商的，業務量趨勢非常明顯。伴隨使用者作息時間，白天高、晚上低，白天買買買。

電商型平臺另一個比較大的特性是，日常的流量相對於大促而言非常低，大促當天的秒級建立量可能是平常峰值量的十倍甚至百倍以上，它具有很強的時間場景性。

離線型業務，比如：計算業務、演算法運算、統計報告、資料處理等業務，業務型別相比於線上而言，可以稱之為時延不敏感，使用者提交的作業和業務，本身的處理時長就在秒級、分鐘級以上，甚至有小時級、天級，因此它們可以執行一段時間後才完成。同時它們可以接受重試，技術上我們應該更關心的是誰幫它重試。使用者重試不可接受，但若有系統幫忙重試，使用者是無感的。

此外，離線業務的時間場景性沒有線上那麼強，隨時都可以跑，甚至表現出反線上業務時間特性，其有一定概率的白天比較低，凌晨比較高。究其原因，也表現出和使用者行為有關，例如：使用者在提交一份統計型，等待凌晨0點後開始執行，第二天早上上班前收取報告。

從不同業務的執行時特性分析，我們可以發現，線上型業務和離線型業務，具備業務壓力錯峰和資源錯峰的條件；

另一方面，線上業務明顯具備更高的優先順序和資源搶佔能力，與此同時，離線業務表現出一定的資源不足時的容忍度。這些因素，成為線上、離線業務混部技術的可行性要素。

1.4 阿里巴巴在做混部探索的歷程

在展開技術介紹前，簡述下阿里巴巴混部技術探索的歷程：

• 2014年提出混部技術；

• 2015年做線下測試和原形模擬；

• 2016年大概上200臺機器到生產環境，公司內使用者作為第一批吃螃蟹的人，執行了一年的時間；在內部使用者適用，線上落地有效後，

• 2017年生產環境小規模混部，達到數千臺物理機級別，直接面向外部使用者，並且支撐了2017年的雙十一大促；

• 2018年，我們希望是規模化鋪開的一年，我們希望混部能在規模化效應下帶來客觀的技術紅利，打造萬臺體量的混部叢集。

1.5 阿里巴巴規模化混部成果

1. 混部規模達數千臺，經歷雙11交易核心場景驗證；線上叢集上引入離線計算任務(在離線)：日常CPU利用率從10%提升到40%；

2. 離線叢集上部署線上業務(離線上)，支撐雙11大促數W筆/s交易建立能力；

3. 混部環境下對線上業務服務干擾影響小於5%；

當前初做混部，存在兩種場景：由線上叢集提供資源做混部，用線上的資源提供額外的離線計算力，供離線業務執行；由離線叢集提供資源做混部，用離線的資源創造線上業務交易能力（主要應對大促等線上流量洪峰）。

在我們內部有個簡單的約定，線上和離線，誰提供機器，誰就排在前面，因此有在離線混部和離線上混部的叫法。

2017年雙11，我司官方釋出的秒級建立量是37.5萬筆每秒，離線上混部叢集做到萬筆每秒的交易體量，使用離線的資源支撐線上高峰，節約了一定量的大促資源開銷。

同時，在離線混部叢集上線後，將線上原生叢集的日均資源利用率從10%提升到了40%，給離線提供了額外的日常計算力。如下圖所示：

這是真實監控系統的資料。（右圖）這個代表非混部場景，時間點大概是7點到11點左右，線上中心利用率是10%。（左圖）這個代表混部場景的資料，平均在40%左右，抖動性比較大，因為離線業務本身具有比較大的波動性。

節約了這麼多資源，業務（尤其線上業務）的服務質量是不是變得很差呢？

以下是負責交易處理的線上核心服務的RT曲線圖，其中綠色曲線代表混部叢集中的RT表現，黃色曲線為非混部叢集的RT表現，可以看出，兩條曲線基本重合，混部場景中的平均RT較普通叢集差5%以內，符合服務質量要求：

二. 混部方案及架構

由於混部技術跟公司的業務體系、運維體系存在一定的關聯性，因此文中可能會提及不同的技術背景，由於篇幅關係只做了簡單引述，可能未做詳細介紹。

下面將簡單介紹混部方案，包括：整體架構、混部場景業務部署策略、混部叢集資源管理及分配機制、混部場景下的業務執行策略等。

2.1 混部整體架構

混部技術抽象來說，分為三個層面：

第一，合併資源，整合資源池，既可以給A業務用，也可以給B業務用。

第二，我們要做到很好的資源排程與分配。在做混部技術之前，阿里巴巴集團已有多個資源排程平臺，其中線上側資源排程系統稱之為Sigma，離線側資源排程系統稱為Fuxi。混部技術的挑戰在於做好資源不同業務資源分配，統一多個資源排程系統，並進行決策仲裁。

第三，執行時做好資源競爭時的隔離與優先搶佔。

上圖的架構表現為一定的層次性：

最底層，是基礎設施層，整個集團的資料中心是統一的，不管上層怎麼用，機器、網路、等等的硬體設施及配套都是同一套；往上一層，是資源層，我們要做混部，必須打通池子，把資源放在一起管控；

再往上一層，是排程層，分為服務端和客戶端。線上是Sigma，離線是Fuxi，我們把各業務自己的資源排程平臺稱為一層排程器。在混部架構中，引入“0層”排程器，主要負責協調兩個一層排程器的資源管控和資源分配決策，它也有自己的Agent；

最上面一層，是面向業務的資源排程與管控層，有些經一層排程器直接交付資源給業務，有些還會涉及二層，例如：Hippo等。

而在混部架構中還有一個特殊混部管控層，其主要負責混部模式下業務執行的機制的編排與執行，以及對物理資源的配置管控、業務監控和決策判斷。

以上是資源分配的體系架構，由此可以將機器和資源分配給不同的業務，然而在分配完後，執行時的業優先順序和SLA如何保障？線上業務和離線業務同時跑在一個物理機上，如果業務間發生資源爭搶怎麼辦？我們通過核心隔離來做到執行時資源保障，我們開發了很多核心特性，支援不同型別資源隔離、切換和降級。核心相關機制將在第三章中介紹。

2.2 混部場景線上業務部署策略

本小節將介紹如何將混部技術運用於線上業務場景，為電商平臺提供交易建立能力。

首先，混部技術由於其新穎性及包含較多的技術改造點，為了規避風險，我們希望能夠在有限的、可控的範圍內進行小規模試驗。因此我們基於我司電商（線上）單元化部署架構進行了業務部署策略，將混部叢集構建出獨立的交易單元，一方面確保混部技術在區域性範圍內收斂不影響全域性，另一方面可以到單元的業務閉環和獨立的資源調配管控。

在電商線上型體系中，我們把買家購買行為相關的全鏈條服務，閉環到一個服務集合中，將這個服務集合定義為交易單元。交易單元可以做到：買家交易行為相關的所有請求與指令，都在這個單元內閉環完成，這就是異地多活-單元化部署架構。

混部技術實施中的另外一項約束，來自於硬體資源限制。由於離線線上業務對硬體資源的訴求不一，而各自的存量資源都不一定適配另一方的業務，在實施中我們遇到了存量資源的適配問題，最為強烈的體現在磁碟。

離線業務的原生資源中，有大批低成本的HDD盤資源，並且離線在執行中幾乎會將HDD盤用滿。這樣對線上業務來說基本就不可用了。

為了遮蔽磁碟IOPS效能問題，我們引入了計算儲存分離技術。計算儲存分離技術是我們集團內在演進的另一項技術，其提供中心式的計算與儲存服務，計算節點通過網路連線儲存中心，可以遮蔽計算節點對本地磁碟的依賴。

儲存叢集可以提供不同的儲存能力。線上業務對儲存效能要求高，吞吐量卻不大，因此我們通過計算儲存分離技術，獲得了有IOPS保障的遠端儲存服務。

2.3 混部叢集資源分配

說完整體架構，我們再從資源的角度來看看混部叢集的資源分配，是如何做到無中生有的。

首先是單機角度的資源，主要是CPU、MEM、Disk、Net，下文將陳述如何實現額外資源的獲得。

先來看看CPU，純線上叢集的日常資源利用差不多在10%左右，可以說線上業務無法在日常狀況下將CPU充分地利用起來，而當大促等促銷場景時，線上將會在瞬間達到一個CPU使用高峰。

離線任務則更像是吸水的海綿，其業務體量巨大，對於CPU計算能力，有多少就能用多少。有了以上業務對資源使用的背景，促成了混部技術中讓CPU一生為二。

CPU資源在核心執行機制中，以時間片輪訓分配給不同的程式，我們將1個CPU核，同時分配給線上業務和離線任務，並確保線上有高的優先順序，當線上閒時，離線可以使用該CPU，而當線上需要使用時，將離線任務搶佔並掛起。

上文有提到兩個資源排程器（線上排程器Sigma和離線排程器Fuxi），線上業務以Pouch容器做為資源單元，Pouch容器會繫結一定的CPU核，供某個線上業務使用。Sigma 會認為整臺物理機都屬於線上。

同時，候離線Fuxi排程器認為這臺機器屬於離線，它會把整體機器的CPU資源作為可分配資源分配給離線任務。通過這種方式，就做到Double CPU資源的效果。

將同一份CPU分配給兩個業務執行，一定會存在競爭的風險，這就依賴核心核心技術來進行CPU隔離和排程，這些會在下文中提到。

CPU可以被多程式分享時間片，但MEM和Disk資源就比較棘手，其作為消耗型資源，分給一方使用，就不能被另外的程式使用了，否則就會被新程式給覆蓋。如何進行記憶體層面的複用就成為另一個研究重點。

如圖（右上）所示，介紹了混部技術中記憶體超賣使用的機制，圖上側的括弧表示線上記憶體分配額（藍色）和離線記憶體分配額（紅色），而圖下側的括弧表示線上記憶體使用額（藍色）和離線記憶體使用額（紅色）。

圖中可見，離線在使用記憶體時，多用了分配給線上的記憶體額度，通過這種機制，實現記憶體超賣使用。

為何線上記憶體允許被超賣使用，由於我們公司線上業務以Java語言為主，分配到容器的記憶體一方面用於java堆記憶體開銷，剩餘的記憶體作為cache使用。

這就造成線上容器記憶體在一定量的空閒記憶體，我們通過精細地記憶體使用量監聽，並結合一定的防護機制，把線上容器分配的空閒記憶體分配給離線使用。但由於這部分記憶體屬於線上，對離線而言無法強保障，因此離線會把相對低等級可降級的業務排程到這些資源上。

Disk方面，磁碟容量對於雙方業務還是比較充分的，故未做過多約束。而磁碟IO方面，做了一系列頻寬限速，以約束離線任務使用的最大IO小於一定數量，避免完全擠佔線上及系統的IO。

另外，單機Net層面，由於當前容量較為富餘，當前不是瓶頸點，不做過多介紹。

2.4 大促資源退讓機制:站點快上快下

以上的單機層面的資源如何做到共享與競爭隔離，再讓我們一起看看從整個資源叢集層面，如果通過整體的運維管控，實現資源的遷移和最大化利用。混部技術中，我們追求資源利用的極致，讓不該用的業務場景不要浪費每一份資源。

於是我們提出了站點快上快下的概念，其面向線上業務而言，如前文所述，每個混部叢集即為一個線上交易單元，其獨立支撐一小部分使用者的交易行為，因此我們也將其成為“站點”，我們把線上站點的整體容量做伸縮變換，就是快上快下的過程。如下圖所示：

線上型業務在日常執行和特殊促銷活動時的業務壓力錶現出巨大的偏差，雙11期間有可能是日常流量的百倍以上，這個特性奠定了快上快下方案的可行性基礎。

如上圖所示，把兩個大的方塊圖，比作是線上站點整個容量，每一個小方塊代表某個線上服務的容器數量，每一行代表一個線上服務的容量儲備（容器總數），我們通過對整個站點的容量規劃，實現日常狀態和大促狀態的容量模型切換，從而使得精細化地使用資源。

我們電商業務通常以一個業務目標，比如秒級交易建立筆數，作為站點容量評估的基準，通常而言，在日常態，單個站點保留K筆/s的容量已經足夠，而等到大促臨近，我們會將站點切換至大促態，通常是W筆/s容量級別。

通過以上模式，從整個站點的維度，把不必要的線上容量進行整體縮容，以達到充分釋放資源，如此就可以讓離線業務拿到更多的物理資源，這就是快上快下機制。

站點快上過程（從低容量到高容量），執行效率在一小時內。站點快下過程（從高容量到低容量），執行效率在半小時內。

在日常狀態下，混部站點以最小容量模型支援日常線上流量，而當大型促銷或全鏈路壓測前夕，將把混部站點迅速拉起到比較高的容量狀態，並持續執行幾個小時後，進行站點快下。

通過這個機制，我們確保絕大部分地時間，線上僅佔用極少的資源，而90%以上的資源均被離線充分使用。下圖展示了快上快下各階段的資源分配細節：

上圖資源分佈的情況，左、中、右三個矩形框分別代表：日常態、壓測態、大促態混部叢集的資源分配狀況。

其中，紅色代表離線，綠色代表線上。而每個矩形框中，又分為上、中、下三層，上層表示業務執行及量級；中層代表資源（宿主機）分佈，其中藍色小方塊代表混部資源；下層代表叢集層面資源的分配比例及執行模式。

在日常態（左矩形框），離線佔用絕大部分資源，一部分通過分配獲得，小部分通過執行時爭搶獲得（線上不使用即會被離線使用）。

而等到壓測態（中）和大促態（右），離線會進行資源退讓，基本達到離線、線上各50%的分配比例，線上高壓力時，離線不進行超賣爭搶，而在準備期內（大促態但非高壓力時間），離線仍然可以爭搶線上空閒資源。

在雙11大促當天，我們為了更確定地保障線上業務穩定，離線會做一定程度的業務降級。

2.5 日常資源退讓機制：分時複用

上文呈述的快上快下機制是線上站點容量在大促態和日常態的切換過程，除此之外，線上業務在白天和凌晨也表現出一種規律性極強地流量高峰和低谷現象，為了更進一步提升資源利用率，我們還提出了日常情況下的資源退讓機制：分時複用。

上圖是線上業務日常表現出的一天的流量週期曲線，凌晨會比較低，白天比較高，我們針對每一個線上服務，做到以天為週期的容量精細化伸縮，以最小化線上業務的資源使用，從而出讓資源給離線使用。

三. 混部核心技術

混部核心技術主要分為兩方面：一是核心隔離技術，二是資源排程技術，由於涉及內容均涉及專業領域，考慮到當前文章篇幅，下文僅羅列了一系列技術點，並不做細節展開。

3.1 核心隔離技術簡介

我們在核心各資源型別層面均做了較強地隔離特性開發，包括：CPU維度、IO維度、記憶體維度、網路維度。整體上基於CGroup進行線上、離線業務組別劃分，以區分兩類業務的核心優先順序。

在CPU維度，我們實現了超執行緒對、排程器、三級快取等的隔離特性。在記憶體維度，實現了記憶體頻寬隔離和OOM kill優先順序。磁碟維度實現了IO頻寬限速。網路維度，單機層面流量控制，還做了網路全鏈條層的分等級QoS保障。

混部核心隔離技術的詳細介紹大家可以自行搜尋獲取，下文僅展開有關記憶體超賣機制的介紹。

Memory動態超賣機制：

如上圖中實線括弧所示，紅色、藍色分別代表離線、線上CGroup的記憶體分配額，其和值代表整機可分配的記憶體（已去除系統開銷記憶體），其下還有一個紫色實線括弧，代表離線的超賣記憶體配額，其大小值因執行時變化，是通過監聽執行時發現線上未使用的空閒記憶體大小來決定的。

如圖中上側虛線括弧，代表離線、線上實際使用記憶體，其中，線上業務通常而言不會將記憶體用滿，其剩餘的記憶體，離線作為其超賣配額進行使用。為了防止線上突發性記憶體需求，在機制中預留了一定的記憶體作為buffer。通過以上機制，實現了離線超賣使用記憶體。

3.2 資源排程技術

混部技術的第二大核心技術為資源排程技術，混部場景中的資源排程，又可分為原生的一層資源排程（線上資源排程技術sigm和離線資源排程技術Fuxi）和混部0層排程。

★ 3.2.1 線上資源排程：sigma

線上資源排程器主要基於應用資源畫像，進行合理地資源排程與分配，包括一系列裝箱問題、親和/互斥規則、全域性最優解等，並從全域性維度進行應用容量自動伸縮、分時複用以及戰鬥維度快上快下。

上圖是線上一級排程Sigma的架構圖，其相容Kubernetes API，基於阿里Pouch容器技術進行排程，並且進過多年阿里大規模流量及雙11大促驗證。

★ 3.2.2 離線資源排程：Fuxi

離線叢集排程器主要實現分等級任務排程、動態記憶體超賣、無損/有損離線降級方案等。

這是離線資源排程Fuxi的執行機制圖，其基於Job進行排程，其面向海量資料處理和大規模計算型別的複雜應用，提供了一個資料驅動的多級流水線平行計算框架。

其在表述能力上相容MapReduce,Map-Reduce-Merge,Cascading,FlumeJava 等多種程式設計模式，高可擴充套件性，支援十萬以上級的並行任務排程，並能根據資料分佈優化網路開銷。

★ 3.2.3 統一資源排程：0層

混部場景中，離線和線上業務通過各自的一層資源排程器進行資源排程和分配，但在一層排程器下面，還有一個統一資源排程層—0層，其職能為雙方資源的協調與仲裁，通過監聽與決策，合理分配資源。以下為混部資源排程的整體架構圖。

四. 未來展望

混部技術的未來發展，將往三個方向演進，分別是：規模化、多元化和精細化方向。

規模化：在2018年，將會做到萬臺級別的混部，這將是一次量級的飛躍，我們希望把混部作為集團內部資源交付的基礎能力，更大規模地節約資源成本。

多元化：未來希望能支援更多的業務型別、更多的硬體資源型別，以及更復雜的環境，甚至希望可以打通雲上資源，阿里雲和公司內部資源混部互通。

精細化：未來希望能將業務的資源畫像刻畫得更加細緻，排程層面時效更實時、排程精度更細緻，核心隔離更加精細，監控及運維管控更加實時精準。

阿里巴巴數學大賽賽題、官方參考答案現已公佈。

長按識別以下二維碼，關注“阿里巴巴機器智慧”公眾號，回覆“數學大賽”，即可下載。

 ↑ 翹首以盼等你關注

你可能還喜歡

點選下方圖片即可閱讀

阿里巴巴為什麼選擇Apache Flink？

領域驅動設計，盒馬技術團隊這麼做

看完這8本演算法好書，才算真正懂了 AI

關注「阿里技術」

把握前沿技術脈搏