2135 億!11 月 12 日零點，2018 天貓“雙11”全球狂歡節的成交額在數據大屏定格，較去年的記錄增長近 27%，物流訂單超 10 億!天貓雙 11 再次成為阿里巴巴創造紀錄并突破紀錄的商業奇跡。

[[249192]]

此刻，比雙 11 的數字更該被記錄的，是阿里巴巴在雙 11 背后做了哪些技術上的突破?

混部技術在業界還尚屬于較少研究的領域，該技術只有在資源及成本的體量達到一定規模時，才會顯現出其可觀的技術紅利。

今天，阿里系統軟件部技術專家蔣玲從阿里巴巴混部探索簡介、混部方案及架構以及混部核心技術等幾個方面帶大家全面了解混部技術，希望對你有所啟發。

阿里巴巴混部探索簡介

混部技術的出發點，源自于對不斷增長的業務和日益攀升的資源成本如何平衡的思考，我們希望用最小的資源成本，支撐更大的業務需求。

是否能夠復用已有的存量資源，來滿足新增的業務，這就是混部技術發展的思想源頭。

為什么做混部?

 

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

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

阿里巴巴在線業務的雙十一零點峰值流量(通常用秒級交易創建量來描述)跟這張圖的曲線走勢基本吻合。

從 2012 年往后的年份開始，0 點峰值壓力基本是上一年的兩倍。可以看到在線側業務發展如此快，主要跟我們促銷活動密不可分。

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

業務不斷增長，在基礎設施層儲備了大量的資源以滿足在線型和離線業務的需求。

由于在線型業務和離線型業務有很多不一致的資源使用特性，最初設計時由兩個獨立的數據中心來支撐，當前，兩個數據中心均已達到萬臺服務器以上的規模。

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

基于以上背景，同時考慮到不同業務對資源使用和要求的差異性：

• 一方面，不同業務具備不同時段峰值的特性(分時復用資源)。
• 另一方面，對資源被響應的容忍度不一(資源按優先級競爭和搶占)，促使我們探索不同業務混合部署的技術方向。

何為混部 ( Co-location )?

 

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

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

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

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

混部最大的價值在于通過資源共享的方式充分復用資源，實現無中生有。而混部技術的核心目標在于出現資源競爭時，優先保證高等級的業務。

因此，我們希望通過調度管控和內核隔離的手段進行資源充分共享和競爭隔離。

在線離線混部

 

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

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

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

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

離線型業務，比如：計算業務、算法運算、統計報告、數據處理等業務，業務類型相比于在線而言，可以稱之為時延不敏感。

用戶提交的作業和業務，本身的處理時長就在秒級、分鐘級以上，甚至有小時級、天級，因此它們可以運行一段時間后才完成。

同時它們可以接受重試，技術上我們應該更關心的是誰幫它重試。用戶重試不可接受，但若有系統幫忙重試，用戶是無感的。

此外，離線業務的時間場景性沒有在線那么強，隨時都可以跑，甚至表現出反在線業務時間特性，其有一定概率的白天比較低，凌晨比較高。

究其原因，也表現出和用戶行為有關，例如：用戶在提交一份統計型，等待凌晨 0 點后開始運行，第二天早上上班前收取報告。

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

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

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

 

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

• 2014 年提出混部技術。
• 2015 年做線下測試和原形模擬。
• 2016 年大概上 200 臺機器到生產環境，公司內用戶作為第一批吃螃蟹的人，運行了一年的時間;在內部用戶適用，線上落地后有效。
• 2017 年生產環境小規模混部，達到數千臺物理機級別，直接面向外部用戶，并且支撐了 2017 年的雙十一大促。
• 2018 年，我們希望是規模化鋪開的一年，我們希望混部能在規模化效應下帶來客觀的技術紅利，打造萬臺體量的混部集群。

阿里巴巴規模化混部成果

阿里巴巴規模化混部成果如下：

• 混部規模達數千臺，經歷雙 11 交易核心場景驗證;在線集群上引入離線計算任務(在離線)：日常 CPU 利用率從 10% 提升到 40%。
• 離線集群上部署在線業務(離在線)，支撐雙 11 大促數 W 筆/s 交易創建能力。
• 混部環境下對在線業務服務干擾影響小于 5%。

當前初做混部，存在兩種場景：

• 由在線集群提供資源做混部，用在線的資源提供額外的離線計算力，供離線業務運行。
• 由離線集群提供資源做混部，用離線的資源創造在線業務交易能力(主要應對大促等在線流量洪峰)。

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

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

同時，在離線混部集群上線后，將在線原生集群的日均資源利用率從 10% 提升到了 40%，給離線提供了額外的日常計算力。

如下圖所示：

 

這是真實監控系統的數據：

• 右圖這個代表非混部場景，時間點大概是 7 點到 11 點左右，在線中心利用率是 10%。
• 左圖這個代表混部場景的數據，平均利用率在 40% 左右，抖動性比較大，因為離線業務本身具有比較大的波動性。

節約了這么多資源，業務(尤其在線業務)的服務質量是不是變得很差呢?

以下是負責交易處理的在線核心服務的 RT 曲線圖，其中綠色曲線代表混部集群中的 RT 表現，黃色曲線為非混部集群的 RT 表現。

可以看出，兩條曲線基本重合，混部場景中的平均 RT 較普通集群差 5% 以內，符合服務質量要求：

 

混部方案及架構

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

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

混部整體架構

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

• 合并資源，整合資源池。既可以給 A 業務用，也可以給 B 業務用。
• 我們要做到很好的資源調度與分配。在做混部技術之前，阿里巴巴集團已有多個資源調度平臺，其中在線側資源調度系統稱之為 Sigma，離線側資源調度系統稱為 Fuxi。
• 混部技術的挑戰在于做好資源不同業務資源分配，統一多個資源調度系統，并進行決策仲裁。

運行時做好資源競爭時的隔離與優先搶占。

 

上圖的架構表現為一定的層次性：最底層，是基礎設施層，整個集團的數據中心是統一的，不管上層怎么用，機器、網絡、等等的硬件設施及配套都是同一套。

往上一層，是資源層，我們要做混部，必須打通池子，把資源放在一起管控。

再往上一層，是調度層，分為服務端和客戶端。在線是 Sigma，離線是 Fuxi，我們把各業務自己的資源調度平臺稱為一層調度器。

在混部架構中，引入“0 層”調度器，主要負責協調兩個一層調度器的資源管控和資源分配決策，它也有自己的 Agent。

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

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

以上是資源分配的體系架構，由此可以將機器和資源分配給不同的業務，然而在分配完后，運行時的業優先級和 SLA 如何保障?在線業務和離線業務同時跑在一個物理機上，如果業務間發生資源爭搶怎么辦?

我們通過內核隔離來做到運行時資源保障，我們開發了很多內核特性，支持不同類型資源隔離、切換和降級。內核相關機制將在第三章中介紹。

混部場景在線業務部署策略

 

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

首先，混部技術由于其新穎性及包含較多的技術改造點，為了規避風險，我們希望能夠在有限的、可控的范圍內進行小規模試驗。

因此我們基于我司電商(在線)單元化部署架構進行了業務部署策略，將混部集群構建出獨立的交易單元，一方面確保混部技術在局部范圍內收斂不影響全局，另一方面可以到單元的業務閉環和獨立的資源調配管控。

在電商在線型體系中，我們把買家購買行為相關的全鏈條服務，閉環到一個服務集合中，將這個服務集合定義為交易單元。

交易單元可以做到：買家交易行為相關的所有請求與指令，都在這個單元內閉環完成，這就是異地多活-單元化部署架構。

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

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

為了屏蔽磁盤 IOPS 性能問題，我們引入了計算存儲分離技術。計算存儲分離技術是我們集團內在演進的另一項技術。

它提供中心式的計算與存儲服務，計算節點通過網絡連接存儲中心，可以屏蔽計算節點對本地磁盤的依賴。

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

混部集群資源分配

 

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

首先是單機角度的資源，主要是 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 層面，由于當前容量較為富余，當前不是瓶頸點，不做過多介紹。

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

以上談了單機層面的資源如何做到共享與競爭隔離，再讓我們一起看看從整個資源集群層面，如果通過整體的運維管控，實現資源的遷移和最大化利用。

混部技術中，我們追求資源利用的極致，讓不該用的業務場景不要浪費每一份資源。

于是我們提出了站點快上快下的概念，其面向在線業務而言，如前文所述，每個混部集群即為一個在線交易單元，其獨立支撐一小部分用戶的交易行為。

因此我們也將其稱為“站點”，我們把在線站點的整體容量做伸縮變換，就是快上快下的過程。

如下圖所示：

 

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

如上圖所示，把兩個大的方塊圖，比作是在線站點整個容量，每一個小方塊代表某個在線服務的容器數量，每一行代表一個在線服務的容量儲備(容器總數)。

我們通過對整個站點的容量規劃，實現日常狀態和大促狀態的容量模型切換，從而使得精細化地使用資源。

我們電商業務通常以一個業務目標，比如秒級交易創建筆數，作為站點容量評估的基準。

通常而言，在日常態，單個站點保留 K 筆/s 的容量已經足夠，而等到大促臨近，我們會將站點切換至大促態，通常是 W 筆/s 容量級別。

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

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

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

通過這個機制，我們確保絕大部分地時間，在線僅占用極少的資源，而 90% 以上的資源均被離線充分使用。

下圖展示了快上快下各階段的資源分配細節：

 

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

其中，紅色代表離線，綠色代表在線。而每個矩形框中，又分為上、中、下三層，上層表示業務運行及量級;中層代表資源(宿主機)分布，其中藍色小方塊代表混部資源;下層代表集群層面資源的分配比例及運行模式。

在日常態(左矩形框)，離線占用絕大部分資源，一部分通過分配獲得，小部分通過運行時爭搶獲得(在線不使用即會被離線使用)。

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

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

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

上文呈述的快上快下機制是在線站點容量在大促態和日常態的切換過程，除此之外，在線業務在白天和凌晨也表現出一種規律性極強地流量高峰和低谷現象。

為了更進一步提升資源利用率，我們還提出了日常情況下的資源退讓機制：分時復用。

 

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

混部核心技術

混部核心技術主要分為兩方面：

• 內核隔離技術
• 資源調度技術

由于涉及內容均涉及專業領域，考慮到當前文章篇幅，下文僅羅列了一系列技術點，并不做細節展開。

內核隔離技術簡介

我們在內核各資源類型層面均做了較強地隔離特性開發，包括：CPU 維度、IO 維度、內存維度、網絡維度。

整體上基于 CGroup 進行在線、離線業務組別劃分，以區分兩類業務的內核優先級。

在 CPU 維度，我們實現了超線程對、調度器、三級緩存等的隔離特性。在內存維度，實現了內存帶寬隔離和 OOM kill 優先級。

磁盤維度實現了 IO 帶寬限速。網絡維度，單機層面流量控制，還做了網絡全鏈條層的分等級 QoS 保障。

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

Memory 動態超賣機制：

 

如上圖中實線括弧所示，紅色、藍色分別代表離線、在線 CGroup 的內存分配額，其和值代表整機可分配的內存(已去除系統開銷內存)。

其下還有一個紫色實線括弧，代表離線的超賣內存配額，其大小值因運行時變化，是通過監聽運行時發現在線未使用的空閑內存大小來決定的。

如圖中上側虛線括弧，代表離線、在線實際使用內存，其中，在線業務通常而言不會將內存用滿，其剩余的內存，離線作為其超賣配額進行使用。

為了防止在線突發性內存需求，在機制中預留了一定的內存作為 buffer。通過以上機制，實現了離線超賣使用內存。

資源調度技術

混部技術的第二大核心技術為資源調度技術，混部場景中的資源調度，又可分為原生的一層資源調度(在線資源調度技術 Sigma 和離線資源調度技術Fuxi)和混部 0 層調度。

在線資源調度：Sigma

在線資源調度器主要基于應用資源畫像，進行合理地資源調度與分配，包括一系列裝箱問題、親和/互斥規則、全局最優解等，并從全局維度進行應用容量自動伸縮、分時復用以及戰斗維度快上快下。

 

上圖是在線一級調度 Sigma 的架構圖，其兼容 Kubernetes API，基于阿里 Pouch 容器技術進行調度，并且進過多年阿里大規模流量及雙 11 大促驗證。

離線資源調度：Fuxi

離線集群調度器主要實現分等級任務調度、動態內存超賣、無損/有損離線降級方案等。

 

這是離線資源調度 Fuxi 的運行機制圖，其基于 Job 進行調度，面向海量數據處理和大規模計算類型的復雜應用，提供了一個數據驅動的多級流水線并行計算框架。

其在表述能力上兼容 MapReduce，Map-Reduce-Merge，Cascading，FlumeJava 等多種編程模式，高可擴展性，支持十萬以上級的并行任務調度，并能根據數據分布優化網絡開銷。

統一資源調度：0 層

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

以下為混部資源調度的整體架構圖：

 

未來展望

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

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

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

 

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