作者 | 舒超
編輯 | 蔡芳芳
前 言
剛剛過去的 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 倍以上，成本節省可觀。
在離線混部的技術門檻
在離線混部雖然有明顯的成本價值，但目前真正落地到生産環境的還是隻有頭部的一些大廠。究其原因，主要是在離線混部涉及服務觀測、排程部署、容災治理等多方面底層技術難題，甚至還包括組織成本核算、跨部門協同等非技術問題，有較高的實施門檻。總結起來，大緻有以下幾大挑戰：
可觀測性體系
可觀測性簡單來說是通過檢查系統輸出來衡量系統内部狀态的能 。從具體輸出項來看，一般包括 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 年在美團任基礎研發團隊負責人及存儲中心架構師、資深技術專家，負責美團公司級的雲原生服務治理體系研發與演進。
活動預告
為了進一步對在離線混部技術展開深入交流，星漢未來将在 1 月 23 号下午 1: 30 舉辦北京站第二次 Meetup，圍繞“自動擴縮容 & 在離線混部核心技術”為大家帶來以下分享：
百度基礎架構部雲原生團隊進階研發工程師星龍将為大家帶來主題分享《百度雲原生混部技術解密》
星漢未來 CTO 舒超将為大家帶來《如何借助自動擴縮容實作在離線混部的分享》
星漢未來 CPO 胡忠想将為大家帶來《支援通用 Web 自動擴縮容的智能運維引擎 CudgX 的詳細産品體驗》