前 言

剛剛過去的 2021 年，在全球經濟增長放緩、疫情時起時伏、中美關系摩擦不斷、國家平臺監管趨嚴等宏觀趨勢疊加影響下，很多互聯網廠商都遭遇了明顯的市值下滑以及虧損加大，裁員消息時有耳聞，所以在 2022 年，降本增效無疑將進一步成為業界大勢所趨。

在保持業務形態和投入不變的前提下，降本增效一個顯而易見的方法是提升現有資源利用率，而造成資源利用率不高的原因主要有如下幾個：

粗放的資源評估：研發更關注如何快速穩定的迭代產品需求，所以在服務部署時，一般按照最大流量來估計服務所需資源。但在線服務大都具有明顯的潮汐特征，導致大部分時間段資源利用率都很低（10% 以下）從而造成浪費。

集群資源整合度不高：服務器的資源占用常常呈現非均衡狀態，例如在線服務尤其是調用主鏈路上的扇出節點業務，高峰期往往呈現出 CPU 和帶寬吃緊，但內存綽綽有余的情況。這導致雖然內存有冗余，但依然無法聚合等比例的其它閑置資源去形成有意義的計算實體。

業務部署隔離： 因為東西部機房成本差異較大和以及容量規劃等問題，很多企業會將在線機房、離線機房完全隔離開，這樣不同 AZ 甚至不同地域間的在離線作業完全無法融合，資源池也無法互通流轉。

而在離線混部技術作為提升資源利用率、降低成本的有效方案，受到業界的一致認可和推薦。

什么是在離線混部

企業的 IT 環境通常運行兩大類進程，一類是在線服務，一類是離線作業。

在線服務：運行時間長，服務流量及資源利用率有潮汐特征，時延敏感，對服務 SLA 要求極高，如消息流 Feed 服務、電商交易服務等。

離線作業：運行時間分區間，運行期間資源利用率較高，時延不敏感，容錯率高，中斷一般允許重運行，如 Hadoop 生態下的 MapReduce、Spark 作業。

因為在線服務資源利用率有更明顯的的起伏特征，所以混部的主要場景是通過填充離線作業把在線服務各個時段的空閑資源利用起來，減少企業與日俱增的成本開支。(注：離在線混部計劃另文闡述)

圖 1 混部示意圖

在離線混部的成本價值

為了更形象的了解在離線混部的成本價值，我們來看一個中小型企業，4 核 8G 的機器一共有 1000 臺，主要計算資源就是 4000 核，8000G。假設平均每臺機器的資源使用率是 10%，那么實際使用的計算資源是 4000*10% = 400 核，8000*10% = 800G。如果我們能通過混部將資源利用率提升到 20%，那么我們只需要 500 臺機器即可。假設 CPU 的平均價格是 300 元 / 核 / 年，內存的平均價格是 180 元 /G/ 年，就可以節省2000*300 + 4000 * 180 = 132w 元 / 年。

由此可見，在離線混部的成本價值是清晰可計算且收益巨大的。

業界實踐來看，谷歌利用混部技術將資源利用率從 10% 提升到 60%，每年節省上億美金。阿里等大廠也成功借助混部將資源利用率提升了 3 倍以上，成本節省可觀。

在離線混部的技術門檻

在離線混部雖然有明顯的成本價值，但目前真正落地到生產環境的還是只有頭部的一些大廠。究其原因，主要是在離線混部涉及服務觀測、調度部署、容災治理等多方面底層技術難題，甚至還包括組織成本核算、跨部門協同等非技術問題，有較高的實施門檻?？偨Y起來，大致有以下幾大挑戰：

可觀測性體系

可觀測性簡單來說是通過檢查系統輸出來衡量系統內部狀態的能?。從具體輸出項來看，一般包括 metric、trace、log 三種方式，是系統健康運行的基石。在離線混部要追求更高的資源利用率，必然需要借助實時指標的反饋做出決策。但是可觀測性在分布式及云原生時代，遇到了以下障礙:

云原生的體系，決定了服務能力和服務規模隨時都在動態調整，所以端上數據收集 、傳輸的成本大大增加，極端情況下甚至對服務本身性能造成侵擾。

可觀測性輸出要形成決策意義，需要基于一些維度進行歸并、擬合、建模等操作，包括使用決策樹到 AI 學習等一系列分析動作。在大服務體量和實時變動的背景下，可觀測性輸出的分析時延、準確性都面臨很大挑戰。

可觀測性的可視化以及延展關聯分析 (BI 報表等)，需要根據業務形態和需求進行深度定制，復雜性較高，缺乏直接能用的工具和手段。

調度決策

在離線混部的調度決策是決定混部效果的核心，目前主要有幾種決策方式：

整機分時復用： 在固定的時間點 (比如凌晨以后) 跑離線作業，白天讓出資源給在線服務。這種以時間維度切分的混部方式比較簡單易理解，但整體資源利用率提升有限。

資源部分共享： 將單機的資源整體劃分為在線資源、離線資源以及在離線共享資源，各資源之間隔離，提前劃分預留。這種從單機資源維度切分的混部方式比分時復用相對更精細一些，但是需要資源規格較大的機器切分才有意義。

資源完全共享： 通過及時準確的資源預測手段、快速響應資源變化的能力，以及一套可以在資源水位發生變化時的服務保障措施，更高效自動化地實現機器資源復用。資源歸屬不預設，完全依據實時指標決策。

前一種屬于靜態決策，相對來說對底層可觀測性體系的要求、對調度系統的高可用高性能的要求較低。后兩種屬于動態決策，在資源利用率的提升上比靜態決策更優，但對前述支撐系統要求也更高。

調度執行

由于在線服務和離線作業工作模式的差異，往往需要采用不同的調度器進行調度（比如 K8s 和 Yarn）?；觳繄鼍跋?，在線調度器和離線調度器同時部署在集群中，當資源比較緊張的時候，調度器會發生資源沖突，只能重試，此時調度器的吞吐量和調度性能會受到較大影響，最終影響調度的 SLA。同時，對于大規模批量調度場景，原生的 K8s 只支持在線服務的調度，從而帶來改造成本。

資源隔離

容器的本質是一個受限制的進程，進程之間通過 namespace 做隔離，cgroups 做資源限制。在云原生時代，大部分業務資源都是基于容器來隔離和限制，但是在資源超售疊加混部場景下，CPU、內存等方面依然可能存在爭搶。

例如在 CPU 方面，為了保證在線服務穩定性，普遍做法是進行綁核，將在線服務綁定在某個邏輯核心上避免其他業務占用。但是綁核對于有并行計算要求的服務并不友好，核數直接決定并行效率。

在內存方面，離線作業往往會讀取大量文件數據，導致操作系統會做 page cache，而原生操作系統對 page cache 的管理是全局的，不是容器維度的。

任務沖突時的資源保障

在線服務和離線作業屬于不同的工作類型，將這兩種負載部署在同一個節點上，會出現資源干擾，當資源緊張或者流量突發的時候，在線服務在資源使用上會受到離線作業的干擾。在離線混部最重要的目標，就是在保障在線服務和離線作業的 SLA 的同時，最大限度提高單機資源利用率。

針對在線服務，需要盡量保證其服務在流量高峰時期與混部之前的指標波動控制在 5% 之內；

針對離線作業，不能因為優先級不如在線服務，就一直處于饑餓或者頻繁驅逐狀態，影響離線作業總的運行時間和 SLA。

服務平行擴縮容能力

將多個業務混部到一臺機器或容器，則宕機可能影響十幾個甚至幾十個服務，這時候就要求服務有平滑且快速的擴縮容能力，實現分鐘級的業務遷移。尤其是存儲類的有狀態服務，甚至涉及到存算分離架構的改造，從而帶來一系列包括數據一致性、響應延時的問題。

部門墻

在企業內部，機器的產品線一般是固定的，成本和利用率也是按照產品線計算，所以通常情況下機器是不會在不同部門之間自由流轉的。引入在離線混部之后，勢必需要打破部門墻，對成本和利用率計算有一個能融合能分解的調整，才能準確反映出混部的巨大成本價值并持續精細化運營。以下是美團某部門精細化成本運營后的分解圖：

圖 2 成本指標分解圖

業界在離線混部方案解析

方案拆分

通過對目前業界在離線方案方案的分析，我們可以抽象出在離線混部方案的三個劃分維度：

從在離線混部的隔離類型上，可以分為獨占內核和共享內核，主要取決于混部的服務內核是否獨立。如果服務是混部于同一臺物理機上，屬于共享內核；如分屬于不同物理機，則屬于獨占內核。

從在離線混部的部署底座上，可以分為物理機部署和容器部署。

從在離線混部的調度決策上，可以分為靜態決策和動態決策。判斷標準是調度決策所依賴的元素是否依賴運行過程中的實時指標。如是則屬于動態決策，反之則屬于靜態決策。動態決策資源利用率更高，但是要做好突發狀況時的資源保障。

這三個維度的組合，目前實際應用中主要是獨占內核 + 物理機 + 靜態決策、獨占內核 + 容器 + 動態決策、共享內核 + 容器 + 動態決策這三種模式。

獨占內核 + 物理機 + 靜態決策

這種組合屬于入門級的在離線混部選擇，比如物理機運行服務且分時整機騰挪。

好處是能夠快速實現在離線混部，收獲成本降低的紅利。技術門檻上，這種方式規避了前面說的復雜的資源隔離問題，并且調度決策足夠清晰，服務部署節奏有明確的預期，整個系統可以設計得比較簡單。

缺點是沒有充分發揮出在離線混部的資源利用率潛力，目前主要是一些初創企業在應用。阿里早期在大促期間，將所有離線作業節點下線換上在線服務，也可以看做這種形態的近似版本。

獨占內核 + 容器 + 動態決策

在這種模型下，業務開發人員將服務部署在云原生部署平臺，選擇某些指標（大部分伴隨著流量潮汐特性）來衡量服務負載，平臺會按照業務指定規則對服務節點數量擴縮容。當流量低峰期來臨時，隨著業務節點數量的減少，在線服務會有大量碎片資源釋放，部署平臺會整理碎片資源，將碎片資源化零為整后，以整機的方式將資源租借給離線作業使用。

比較典型的是字節跳動的方案，架構圖如下所示:

圖 4 字節跳動在離線混部架構圖

字節跳動依托于 K8s 與業務 quota 做整機騰挪的在離線混部，以集群轉讓節點的方式提高整體資源利用率，主要實現思路為：

當在線服務的波谷來臨后，幾乎所有服務都會因為彈性縮容而導致副本數降低。從整體上看，集群里節點上的 Pod 會變得非常稀疏，集群整體資源部署水位也隨之降低。當集群的部署水位低于設置的閾值后，控制面會通過一定規則選取部分在線節點，將該節點上的 Pod 驅逐到別的節點上，并標記該節點不可調度，最后通過某種機制將該節點加到離線的集群中實現資源的轉讓。同理，當在線服務的波峰來臨后，會發生一個逆向的控制過程，控制面在通知并確保離線任務撤離后，重新將節點加回到在線集群中設置為可調度狀態，實現資源的回收。

字節跳動的方案基于公司自身的業務復雜度， 使用自定義 quota 而沒有使用 K8s 通用的 hpa；部署方式兩階段混部：白天離線作業機器給在線服務使用， 晚上在線服務器轉讓給離線作業使用；僅支持容器部署，方案并未開源。

由此可見，在獨占內核 + 容器 + 動態決策方案中，業務在部署服務的同時制定擴縮容規則，當流量低谷時，平臺按照規則減少服務節點數量，此時在線資源會釋放碎片資源。當碎片資源達到閾值，會觸發在線到離線的轉讓邏輯，轉讓邏輯中首先整合碎片資源，然后將碎片資源整合為物理機，最后將物理機整體租借給離線使用。當流量逐漸恢復后，會觸發在線回收轉讓資源邏輯，在該邏輯下，會逐漸驅逐離線任務，將資源回收。由于在線服務有很強的潮汐特性，可以通過定時定量的方式，比如晚高峰 19 點 -23 點，將指定數量的離線資源轉讓給在線服務使用，當 0 點時將轉讓的資源返還給離線使用。

共享內核 + 容器 + 動態決策

與上述幾種方案最大的不同在于，轉讓的資源規則是動態決策的。在一個大企業中，服務數量數以萬計，要求所有在線服務制定擴縮容決策是很難做到的。同時，業務在部署服務時更關注服務穩定性，常常按照最大流量評估資源，這樣就導致流量低峰期有大量的資源浪費。

比較典型的是百度、騰訊、快手的方案，這里以騰訊方案為例：

圖 4 騰訊 Caelus 系統架構圖

騰訊在離線混部系統 Caelus 以 K8s 為依托，在 K8s 節點以容器的方式部署離線任務，實現在線服務節點轉讓資源給離線作業，支持特性包括：任務定級 / 調度增強 / 資源復用 / 資源畫像 / 存算分離 / 任務避讓 / 干擾檢測等。騰訊的方案兼容 Hadoop 生態，但不支持離線作業轉讓資源給在線服務。該方案在騰訊內部已經被大規模應用到廣告、存儲、大數據、機器學習等多個 業務，平均提升 30% 資源利用率，節省了上億成本。通過混部 Hadoop 類離線作業，大約提高了 60% 的 CPU 使用率。

共享內核 + 容器 + 動態決策的方案有兩種資源視角:

在線服務資源視角，看到的是節點資源總體容量，比如當前物理機上總共有 126 核 CPU；

離線作業資源視角，看到的是節點的空閑負載，比如當前物理機還有 64 核 CPU 是空閑的；

服務部署時：

在線服務按照資源容量調度服務；

離線作業按照節點負載調度服務；

這類模型實施的難度在于資源隔離，如何避免或降低離線對在線的影響是混部方案是否成功的關鍵。各大廠在資源隔離方面都做了很多努力，比如更全面的指標收集、更智能的負載預判、更合理的在線資源冗余度、更精細的 eBPF 等。即使在資源隔離方面做了非常多的努力，還是難以避免共享內核模型中離線對在線的影響，方案中一般都搭配著干擾探測，當探測到在線服務受到影響時，及時止損。

一種開源在離線混部的快速實現方案

從上述在離線混部方案的分析中可以看出，如果有比較強的研發實力，能夠較好解決第三部分中講到的幾乎所有技術門檻，就可以挑戰共享內核 + 容器 + 動態決策組合的方案，以追求極致的資源利用率和成本優化效果。如果公司研發團隊在底層技術積累比較少，想快速、安全、低成本地用上在離線混部，先享受部分混部的成本優化紅利，則獨占內核 + 容器 + 動態決策組合的方案是首選。

結合業界絕大多數企業的實際場景，我們推出了一套一站式在離線混部方案，由算力調度引擎 BridgX 和智能運維引擎 CudgX 兩個核心組件構成，如下圖所示：

圖 5 一種開源高可用在離線混部方案架構圖

BridgX：算力調度引擎，在算力層面為在離線混部提供基礎的算力調度能力，包括跨云調度能力、K8s 容器及大規格裸金屬服務器切割能力以及快速彈性伸縮能力。

CudgX：智能運維引擎，為在離線混部提供自動化壓測、服務指標度量、容量評估等能力，精準刻畫在離線作業的資源使用畫像。

整體的工作流程如下：

CudgX 負責收集服務指標，通過配置冗余度規則保持服務和節點的冗余度。當流量低峰時，CudgX 對服務節點縮容，觸發在離線整合模塊轉讓邏輯。當流量高峰時，CudgX 對服務節點擴容，觸發在離線整合模塊回收邏輯。

同時 CudgX 還會評估在線資源的冗余度，當在線資源冗余度過低時，CudgX 會觸發 K8s 擴容邏輯，借助 BridgX 申請資源，完成在線資源擴容。當資源冗余度回歸正常時則將資源退還，保證資源充足的情況下成本可控。

離線整合模塊負責完成轉讓和回收邏輯，當在離線整合模塊發現在線資源有足夠多的碎片資源可以回收時，會進行一次碎片資源整理統計，將碎片資源整合為完整物理機轉讓給離線作業使用。當在離線整合模塊發現在線資源冗余度不足時，會觸發資源回收邏輯，將轉讓給離線作業的資源回收，完成回收邏輯。

本方案通過內核進行資源隔離，優點是在離線服務徹底分離，不存在離線作業影響在線服務的可能。

GitHub 鏈接：

Bridgx： https://github.com/galaxy-future/bridgx

Cudgx： https://github.com/galaxy-future/cudgx

總 結

在離線混部對資源利用率提升、降低成本都有公認的明顯作用，但在離線混部又是一個龐大而復雜的工程，涉及多個組件以及多個團隊的協同合作。在離線混部也是一個持續優化的過程。各家大廠都投入了相當長的時間研究才開始放量鋪開。我們期望通過借鑒業界成熟的混部方案，以云原生低門檻一站式的方式讓在離線混部在更多企業落地，幫助業務擺脫成本煩惱，助力企業成功！

作者介紹：

舒超，目前在星漢未來擔任 CTO，負責公司整體研發工作。2010-2015 年在騰訊擔任技術專家，負責微博微群、消息流廣告等項目；2015-2021 年在美團任基礎研發團隊負責人及存儲中心架構師、資深技術專家，負責美團公司級的云原生服務治理體系研發與演進。

關于星漢未來：

星漢未來（Galaxy-Future）是一家云原生基礎引擎提供商，提供三大算力引擎：算力調度引擎BridgX、數據物流引擎DTExpress、智能運維引擎CudgX，基于三大引擎也提供了標準化智能運維產品SchedulX和運維可觀測產品ComandX，同時，也為企業提供解決方案和咨詢服務，希望能幫助企業在上云過程中實現：云使用成本降低50%-80%，同時，開發效率能提升10倍。

相關產品GitHub地址：

算力調度引擎BridgX：

GitHub地址：

https://github.com/galaxy-future/bridgx

智能運維引擎CudgX：

GitHub地址：

https://github.com/galaxy-future/cudgx

標準化智能運維產品SchedulX：

GitHub地址：

https://github.com/galaxy-future/schedulx