隨著公司的發展，技術架構逐步演進為線上、近線、離線三位一體架構。近線服務介於線上和離線之間，一般採用非同步計算的方式，並不要求立即返回結果，但是計算的執行卻和線上服務類似。容器架構團隊設計了一套基於容器的近線服務統一排程平臺，支援數十萬核近線服務接近0計算成本執行。

本期分享嘉賓

高會軍

小紅書基礎架構部容器架構負責人

【嘉賓介紹】 9年網際網路後端開發和架構設計經驗，在Kubernetes、閘道器、可觀察性、服務網格、DevOps等方向有一定的實踐經驗。目前在小紅書負責雲原生技術的推廣和落地。

以下內容，整理自 SACC 2022中國系統架構師大會上的演講：

本期分享嘉賓是小紅書基礎架構部容器架構負責人高會軍，他本次的分享側重於近線服務統一排程平臺從0到1的建設實踐之路的思考，其要點是關於整體解決方案，以及服務資源保障模型和落地的典型案例。

分享概要：

一、為什麼要建設一個近線服務統一排程平臺

二、整體解決方案和架構剖析

三、收益

四、未來規劃

為何要建設一個近線服務統一排程平臺

1、瞭解何為近線服務

在2013年 Netflix 公佈了自己推薦系統的架構，首次將計算分為線上、近線和離線三種型別。

對於推薦系統來說，線上計算需要快速響應事件並且使用最新的資料。線上計算在可用性和響應時間上都有較高的SLA要求，通常來說線上計算依賴的資料來源也是需要線上提供的。

離線計算允許在演算法方法中有更多選擇，例如複雜的演算法，並且對使用的資料量的限制更少。比如定期彙總數百萬電影播放事件的統計資料，以計算 baseli ne 的流行度指標。

近線計算可以看做前兩種模式的折中。近線計算的執行與線上情況完全相同。但是，取消了在計算結果後立即提供結果的要求，而是可以儲存它們，從而使其成為非同步的。

其實延展到所有的計算場景中，根據不同的服務特徵（主要是對響應延遲的敏感程式），都可以將計算服務分為線上、近線和離線。從資源側來看，不同型別的服務對於計算資源的保障能力要求是不同的。

2、近線服務現狀和存在的問題

在建設近線服務統一排程平臺之前，我們梳理了所有近線服務的實際情況，發現主要存在的問題，有以下幾點：

成本不是最優：沒有將計算服務按照服務特徵進行服務分級，導致近線服務和線上服務一樣使用保障能力最高的算力資源，進而成本上不是最優的。
缺乏統一的排程入口：不同的團隊各自為戰，出於穩定性和彈性的考慮，導致每個叢集都冗餘一定量的閒置資源。缺乏一個近線服務統一排程入口，無法站在整個公司的視角管理資源。

3、為何要建設一個近線服務統一排程平臺？

在整個網際網路行業的整體形式不樂觀的背景下，降本增效成為所有公司的必須要做的事情。此外小紅書自身業務的快速蓬勃發展，對計算資源的需求成倍的增長。如何以最少的資源支撐更多的業務，是小紅書雲原生團隊不得不思考的一個問題，也是義無反顧需要承擔的責任。

結合近線服務存在的問題，建設一個近線服務統一排程平臺是降本增效行之有效的路徑。

近線服務統一排程平臺，站在整個公司計算資源的視角，統一管理和排程所有的近線服務。並且提供差異化的雲原生能力，在降低成本的同時，增強近線服務的容錯能力。

整體解決方案和架構剖析

1、算力來源和服務QoS資源保障模型

對於算力，小紅書按照算力生命週期、資源成本、普適性三個維度，對不同算力（獨佔資源池機器、buffer池閒置資源、潮汐分時算力、混部算力、公有云容器例項）進行打分。

對於服務，我們目前將服務劃分為強隔離要求線上服務、普通線上服務、近線服務、離線服務4個QoS級別。

服務 QoS 資源保障模型，本質上就是按照服務的 QoS 級別，給予不同的算力保障。

對於近線服務，排程優先順序為：獨佔資源池機器 > 線上叢集閒置算力 > 混部算力 > 公有云容器例項服務。目前公有云容器例項服務，只是作為一種特殊場景的資源兜底算力。

2、整體架構

近線服務統一排程平臺架構如下圖所示，整體包括三部分，自上而下分別為運維面、控制面、負載面。接下來，我逐一展開說下。

運維面，即近線服務統一部署平臺（內部代號：RedCloud），使用者無需感知 k8s 相關知識和底層資源，一鍵部署業務。
控制面，包含後設資料管理叢集，核心元件包括排程器（包含統一資源檢視）、彈性控制器、Virtual Kubelet （簡稱VK）等。
負載面，由多個線上工作負載叢集組成。核心元件包括二次排程器。

通常場景，控制面叢集，不會執行真正的工作負載。控制面和負載面叢集透過 VK 連線。

在介紹整體架構後，接下來著重介紹一下核心元件和核心能力。

1）近線服務統一部署平臺

近線服務統一部署平臺，作為所有近線服務的統一入口。抽象了近線服務的應用模型和視覺化雲原生支援能力，將可用、可伸縮等需求交由基礎設施實現，使使用者僅需關注業務邏輯而無需關注具體部署和執行，極大地提高了應用開發效率。

同時提供了釋出管控能力，支援多種服務升級灰度策略，比如分批次釋出和多機房灰度等，並且對接了內部的風險變更平臺，最大程度上保證了近線服務的穩定性。

2）VK

VK 是一個開源的 k8s kubelet 實現，它將自己偽裝成一個 kubelet，將 pod 資源轉換為其他形式的資源，供 k8s 叢集使用。

在小紅書內部已對開源的 VK，做了大量的特性增強和 bug 修復，相關最佳化均已貢獻給社群。另外，使用 VK 作為聯通多個叢集的管道，實現了多個叢集之間資源互聯互通。

近線服務下發到控制面後設資料叢集的 Pod，需要 VK 在中間做一層轉換才能對映到線上叢集，因為線上叢集在資源、標籤、namespace 等方面的差異，需要屬性轉換才能執行到線上叢集。

同時負責可用資源的計算，透過資源檢視模組計算可以實際分配的套餐資源。

3）排程

排程是整個平臺的核心部分，相當於大腦。排程需要考慮成本、穩定性、部署速度等因素。

在上面講到的近線服務對於不同算力的排程優先順序，主要依靠 RedScheduler 優先順序和搶佔兩個策略實現。

同時部署在負載面線上叢集的二次排程器，主要負責近線服務例項的退場工作。比如當線上業務例項存在 pending 的時候，二次排程器需要在2分鐘內將近線例項驅逐，最終將資源歸還給線上服務。

4）彈性

彈性作為雲原生的核心能力，主要體現在增強服務的按需使用能力和故障容錯能力。按需使用，意味著對成本最佳化。故障容錯能力，意味著可以提升服務面對流量高峰的處理能力。

目前支援多種彈性策略，包括 1）cpu 和 mem 等資源指標；2）cron 定時；3）基於業務自定義指標，比如 qps 或事件堆積數；4）智慧 HPA。透過演算法預測未來的流量洪峰提前擴容，避免擴容不及時導致的雪崩和服務穩定性故障。

由於同一個近線服務例項會被分發到多個叢集，所以自研了聯邦HPA控制器，支援多叢集場景。

對於近線服務，彈性也是實現近線計算例項在不同算力資源流轉的前提。

收益

截止目前，小紅書近線服務統一排程平臺已經覆蓋了全部的近線服務和部分離線服務。目前實現了近 10wc+ 的近線服務 0 計算成本執行的目標。同時，也提升了近線服務的處理能力。

此外，沉澱了上述的服務QoS資源保障模型，並基於該排程模型建設了小紅書三級排程體系。該體系在未來整個提升計算資源效能中發揮重要的作用。

（一）一級排程體系，主要是策略排程。策略排程實現了服務QoS資源保障模型，按照服務的QoS級別，給予不同的算力保障。

（二）二級排程體系，叢集排程。叢集排程也是小紅書建設的多叢集 k8s 管理系統的核心模組。透過使用者輸入的排程需求、統一的全域性資源檢視，根據不同的排程策略產生對應的叢集排程結果，滿足不同應用對於跨叢集排程的需求。目前我們的二級排程器支援的排程策略包括：

強指定型別，使用者直接指定目標叢集以及副本分佈；
資源優先（單叢集模式），優先將應用分發至資源最充足的單個叢集；
資源優先（多叢集模式），按資源餘量，將應用分發至多個符合條件的候選叢集；
節點優先，將應用優先分發至符合條件節點最多的候選叢集；
均分模式，將應用同步分發至符合條件的所有集群。

（三）節點排程。主要用於叢集內節點排程。主要包含了red-scheduler 和 descheduler。其中red-scheduler，基於原生 k8s 排程器，增加了基於真實負載感知排程，搶佔等策略。

未來規劃

未來小紅書需要統一在離線排程器，在排程層融合現在的線上服務以及支援剩餘的離線服務，最終支援線上、近線、離線三位一體超融合場景，從而建設一個具備全域性最優資源效率，能夠統一管理底層資源的排程平臺。

小紅書近線服務統一排程平臺建設實踐

相關文章