創業初期，小紅書與多數網際網路公司一樣，採用相對“單調”的上雲、用雲策略。

但當容器化率突破 80%、資源量突破數百萬核 CPU 時，粗放用雲模式的代價開始顯現：叢集利用率明顯低於其他網際網路企業，跨雲環境的應用部署複雜度飆升，可觀測性和運維能力面臨新挑戰。同時，還要充分滿足業務快速穩定迭代的訴求，靈活應對市場和業務變化。

技術團隊清醒意識到，需要在雲廠商基礎設施之上構建一系列小紅書獨有的雲原生技術中臺能力。

面對既要延續技術積累又要突破發展瓶頸的雙重課題，小紅書技術團隊選擇了一條獨特的技術路徑：沒有陷入 "推倒重來" 或 "簡單複用" 的二元對立，在多雲的資源結構下，以阿里雲容器服務 ACK + 雲伺服器 ECS 構建穩固雲基座，將小紅書特有的社群電商、內容分發等複雜業務場景需求，與阿里雲開源專案 OpenKruise（已捐贈給 CNCF）、Koordinator 的技術優勢深度融合。這種 "雲基座打底 – 透過開源共建滿足個性化需求" 的創新模式，既能在保留原有技術架構核心價值的基礎上，透過深度定製的方式滿足高效穩定的業務用雲需求；又能透過開源共建的方式，讓小紅書的技術具備足夠的先進性與可持續性。

InfoQ 與小紅書技術團隊、阿里雲技術團隊分別聊了聊，希望能儘可能完整地覆盤本次雲上創新，也為業界貢獻更多技術選型的思路和案例。

2018 年，小紅書邁出了容器化建設的第一步。

雲服務為小紅書帶來了顯著的便捷，能在幾分鐘內建立 Kubernetes（K8s）叢集並交付機器。但與此同時，對於小紅書團隊而言，新的管理挑戰也隨之浮現。

早期小紅書允許各業務線自行申請獨立叢集，雖然單個叢集規模不大，卻因數量龐大，且缺乏專業團隊維護，致使 K8s 版本高度碎片化。許多叢集長期停留在初始申請版本。不同版本的 K8s 在資源排程、管理策略上存在差異，無法統一最佳化資源分配，加上低版本缺少高效資源管理特性和效能最佳化，無法充分利用硬體資源。

更深層次的問題在於，資源效能與業務穩定性之間存在天然的矛盾。正如小紅書雲原生平臺負責人林格所說：“過去我們總是依靠資源冗餘來保障穩定性，資源和應用架構的雲原生化相對滯後。”

面對這些挑戰，小紅書開始反思：在增強業務穩定性、資源排程和架構最佳化方面，是否有更成熟的行業方案可借鑑？畢竟，雲原生髮展已有十年，但許多企業仍停留在“用容器但不做排程”的階段，即使這種做法在企業快速成長時期難以避免。

OpenKruise 和 Koordinator 這兩個開源專案，正是在這樣的背景下，開始進入小紅書團隊的視野。

先看看 OpenKruise 。OpenKruise 是 Kubernetes 擴充套件套件，專注於雲原生應用的自動化管理，包括部署、釋出、運維及高可用性防護。通常被用來解決有狀態服務雲原生化的一些問題，和 Kubernetes 官方工具 StatefulSet 定位接近。

但在選擇有狀態應用編排工具的技術選型中，小紅書團隊放棄了 StatefulSet，轉而選擇了 OpenKruise。

原因在於，在小紅書有狀態應用容器化場景中，核心業務主要包含以下兩類技術形態：

總的來說，這些有狀態編排的訴求可以分為 多角色 和 多分片 兩大類。

StatefulSet 作為 Kubernetes 官方的有狀態應用編排方案，在基礎場景中能滿足多分片 / 多角色應用的簡單編排需求，但在企業級生產環境中面臨顯著侷限性，主要體現在兩個核心場景：

綜上所述，社群 StatefulSet 並不能滿足生產級要求。

小紅書把這些應用的編排形態抽象成了一個二維矩陣，並稱為行列編排，其中一列代表一個分片，行數代表了一個分片的副本數量。當發現上游對服務的呼叫量增加，可以在行的維度進行擴容；另一方面，當資料量發生變化，可以在列的維度進行擴容。

在這個過程中，小紅書技術團隊發現 OpenKruise 的 UnitedDeployment 可以提供關鍵技術支撐。並根據業務場景構建統一工作負載模型，封裝到小紅書雲原生平臺中，解決小紅書內部有狀態服務的編排問題。

而選擇 Koordinator，則是為了重點解決資源排程問題。

2023 年初，隨著資源規模擴大，對資源效能的要求提高，公司開始構建自主的混部排程能力。不同於以往在資源壓力較小時，僅依靠簡單的資源騰挪、二次排程和碎片治理，此次調整是一次更深層次的架構升級。

然而，小紅書雲原生架構師熊峰也強調，必須構建自己的協調層，這樣才能真正掌控技術棧。

這源於小紅書本身業務需求的特殊性，在混部和相關能力增強方面，很難在業內找到開箱即用的方案。因此，需要進一步的定製化，構建更符合業務需求且易用的上層能力，形成一個可插拔、可擴充套件的排程體系。在保障核心業務穩定性的基礎上，進一步提升資源編排和排程的效率。

無論是快手、美團、滴滴還是小紅書，大家在進入原生化深水區時遇到的問題和需求，最終有相當一部分會歸結到排程及其相關領域上。對於小紅書而言，混部技術正是小紅書雲原生平臺能力的核心戰場。

2023 年初，團隊在多種社群開源方案中反覆權衡，最終，他們選擇了阿里雲開源的 Koordinator。

“選擇 Koordinator，既有歷史路徑依賴，也有技術理性。”林格解釋。早期小紅書基於 ACK 搭建技術底座，Koordinator 作為其開源延伸，天然適配現有架構；更重要的是，阿里內部多年混部實踐為方案提供了“規模化驗證”背書。

小紅書深度參與了 Koordinator 社群的建設。在 Koordinator 開源初期，小紅書就積極參與了方案討論，並發現其資源模型抽象和 QoS 策略與小紅書的思路一致，因此結合自身的具體場景進行了探索並參與社群程式碼提交。與其他開源架構相比，Koordinator 底層構建了一個可插拔、可擴充套件的體系。基於這一特點，小紅書並未完全照搬其架構，而是選擇性地使用了部分元件或借鑑了其部分能力，並結合自研成果和內部積累的開源能力進行了整合。

小紅書的案例在業內具有普遍性，特別是在大資料排程方面。許多客戶由於各種原因仍依賴現有排程方式，無法立即切換至 K8s 原生的 Operator 排程模式。為了解決 EMR 場景下的資源效能問題，小紅書自 2023 年 5 月起開始啟動 YARN & K8s 混部方案。

最初階段，小紅書主要進行技術探索。同業界其他 Yarn on K8s 方案不同的是，小紅書並未對 Yarn 進行侵入式改造，而是基於開源 Yarn 版本進行開發。在過去一年中，小紅書的 Yarn 與 K8s 混合排程方案逐漸成熟，規模也在持續擴大，覆蓋了數萬臺節點，提供了數十萬核資源，效果也很明顯：CPU 利用率平均增長 8%~10%，部分達到 45% 以上。在此基礎上，團隊進一步嘗試最佳化 Yarn on K8s 的方案。短期目標是提升資源複用率和效能，而長期規劃是借鑑 Koordinator 的統一排程理念，在 K8s 中支援 Spark 和 Flink 等業務的統一排程，從兩套排程體系並存演進為統一排程，逐步實現從 Yarn 向 K8s 的切換過渡。最終，Yarn 將逐步退出歷史舞臺，K8s 生態則需全面承接大資料負載。

值得注意的是，小紅書與阿里雲開源社群之間採用的，是一種帶有共創性質的社群協作正規化，打破了傳統“使用者提問題→雲廠商做方案”的單向路徑。

小紅書早期就一直持續數月定期參與社群會議，並結合自身落地場景參與了技術方案設計。特別是離線混部、大資料生態融合等領域，資源畫像和資料預測能力的早期 proposal，均由小紅書提供了場景和 idea，並與阿里雲社群開發者共同討論實現路徑。這種合作也催生了意料之外的“共鳴”：Koordinator 開源團隊也從小紅書提出的 Proxy 元件方案中發現雙方對架構設計理念和資源模型的理解竟高度一致，隨即開放核心模組的程式碼共建。

透過 issue 跟進、程式碼提交等方式，持續推動核心功能的完善，小紅書的場景需求成為了開源元件設計的原生基因，讓技術方案在一開始就烙上了生產級場景的印記。

眾所周知，排程領域很難做出一種完全通用的方案，尤其當業務規模達到一定體量後，往往會出現許多定製化需求。而這種開源協作形式以及最終形成的方案，對很多類似企業都具有重要的參考價值。而且面對中國開源生態中“曇花一現”的挑戰，這種以真實場景驅動、多方持續投入的深度共建模式，或許正是維持社群生命力的關鍵。

以上只是解決了小紅書在開源層面的選型問題，在混部方案啟動後，如何進一步提升收益、避免資源浪費，保障傳統核心業務的高效執行，又能從排程層面解決不同業務間的資源供給問題，成為了下一階段的核心命題。

這是一個涉及業務和基礎設施層面的整體工程，要求對排程系統、核心等多個維度進行最佳化，同時還要在業務指標中引入響應時間（RT）劣化率、CPU 分層利用率等指標，以降低低效資源比例，倒逼架構最佳化。

在這一系統性工程中，“大 Node 小 Pod”成為小紅書混部落地的核心方法論。

在混部的情況下，首先需要確認的是資源供給方式。早期，小紅書的許多業務在一定程度上將 Pod 和虛擬機器繫結在一起。一臺機器上通常只部署一到兩個應用，導致遷移成本高、彈性差，並且由於負載特性相似，對資源的訴求同質化嚴重，比如流量到來後在某個時間這些業務同時將 CPU 打高，容易出現資源共振問題，影響系統穩定性。因此，要在同一節點上對不同業務進行混部，併為業務提供彈性和效能緩衝的空間非常有限。

於是技術團隊突破性提出“大 Node 小 Pod”策略：將物理節點規格做大，將應用拆小，例項增多並打散分佈，既規避了虛擬化層潛在的資源干擾，又為跨業務混部創造了靈活的資源排程空間：在單機故障或出現熱點問題時，可以更快速地進行應用遷移，從而減少停機時間和對業務的影響。

小紅書進一步提升混部收益的一個非常關鍵的手段是將核心的一些業務線，約 50 萬核的計算資源，替換為了“大 Node”的基於阿里雲 CIPU 架構的大規格 ECS 例項。

“基於阿里雲自研的 CIPU 架構的雲伺服器，確實幫了我們大忙。”林格強調。

小紅書主力使用的是 64 核的 VM 與 192 核的整機規格伺服器，其中整機規格的伺服器作為大 Node 使用時，小紅書能夠直接掌控從 CPU、記憶體到快取的全量硬體資源，避免跨租戶資源爭搶導致的效能抖動。在推進“大 Node、小 Pod”策略時，這相當於提供了一種極限規格的大型計算節點能力。

在構建大規模計算節點時，阿里云云伺服器 ECS AMD 例項（以下簡稱 ECS AMD 例項）是小紅書在大 Node 方案中的另一個重要選擇。ECS AMD 例項構建在多層技術架構之上，最底層是 AMD CPU 晶片，併疊加阿里雲自研的 CIPU 架構，其上一層為容器相關產品如容器服務 Kubernetes 版 ACK（以下簡稱 ACK），最上層則是使用者的應用層。

自 2022 年起，小紅書便開始採用 ECS AMD 例項。近年來，特別是第八代推出後，CPU 能力方面得到了更大提升。例如，主頻提升到 2.7GHz，最高睿頻到 3.7GHz，核心密度不斷最佳化，同時相比上一代單核的二級快取提升一倍，IPC 提升了 14%，使其在相同功耗水平下算力提升約 25%。

除了高密度核心帶來的價效比收益，還有一個是在大資料和搜推場景下的效能優勢。

在深度學習驅動的搜推業務中，小紅書採用 PS-Worker 分散式訓練架構作為技術底座。該架構下，引數伺服器需要在記憶體中儲存並快速讀取大量引數，那麼記憶體頻寬以及網路吞吐率都是重要的效能瓶頸點。

為了突破這些瓶頸，小紅書選擇基於阿里雲自研的 CIPU 架構的 ECS AMD 例項，將記憶體頻寬提升 125%，達到 350GB。

一是傳統的 VM 由於虛擬化開銷，會丟失部分記憶體頻寬和 Cache 資源的隔離能力。而 CIPU 架構保留了這些能力，也能夠接入 VPC 網路、雲盤及訪問大資料 EMR 系統的能力。這種特性使得伺服器在保持雲計算靈活性的同時，也能提供精細化的資源控制能力，包括記憶體頻寬和 L3 Cache 的調優，從而更好地適配大規模混部場景。

二是 ECS AMD 例項處理器在第八代升級中，將記憶體通道數從 8 個擴充套件到 12 個，並提升了記憶體速率，使得資料吞吐能力顯著增強。同時，這代處理器還採用了先進工藝實現了硬體微架構上比如 CPU 核心密度、io 等多方面的提升。除硬體外，在指令方面，不僅相容了 AVX512 同時還支援了 bf16，使得在高併發、大規模計算任務下，系統能夠保持更高的穩定性和效率。

在超大規模計算（大 Node）場景下，網路效能往往是影響整體計算效率的關鍵因素。PS-Worker 節點裡，網路的開銷通常會在整個效能權重中佔據很大一部分。

CIPU 架構引入的 eRDMA（Elastic RDMA）網路，以其低時延、高吞吐效能使大 Node 之間的資料傳輸時延最低可達 8-10 微秒，相比傳統 VPC 網路，通訊開銷降低達 45%。結合任務並行度最佳化演算法，使 AI 訓練和線上推理的長尾延遲顯著改善。

早期小紅書叢集資源管理粗放，存在大量業務獨佔資源池，導致資源池割裂、碎片化嚴重。業務為保障穩定性過度囤積資源，進一步加劇浪費。為此，小紅書調整叢集架構，建成包含 7000 至 8000 個節點的超大規模叢集，成為雲上單叢集節點數最多的案例之一。

在業內，突破 K8s 社群的節點規模上限，一直被視為衡量技術能力的重要指標。隨著阿里雲產品能力的不斷提升，ACK 目前對外承諾的單叢集節點上限已達到 1.5 萬個節點。這意味著，從 K8s 社群推薦的 5000 節點，到 ACK 支援的 1.5 萬節點，規模足足提升了三倍。

阿里雲在應對單叢集 1.5 萬節點的挑戰過程中，針對控制面和資料面進行了多項最佳化。

在 AI 和大規模彈性場景下，單叢集規模擴大會導致資源膨脹，對控制面和資料面提出更高要求。節點數增至 5000 時，控制面壓力顯著增加，表現為記憶體與 CPU 消耗成倍增長，以及 API Server 穩定性問題 —— 控制面需快取全部資料面資源資訊，導致資源佔用遠高於常規叢集。ACK 針對控制面元件實施多項最佳化：

資料面的最佳化主要針對大規模彈性場景（如小紅書離線任務）：

事實上，在應對單叢集 1.5 萬節點挑戰過程中，ACK 的最佳化不僅滿足了自身業務的高標準需求，還貢獻至 K8s 社群，有些最佳化已在 1.30 版本中得到應用。

當然，面對超大規模的叢集管理，不同企業也會採用不同的策略。有些企業選擇將業務拆分到多個小叢集中，而有些則傾向於將大部分業務集中在少量的大叢集中，以簡化運維管理和降低釋出複雜度。

作為使用者，小紅書本身不需要太關注管控面的穩定性該怎麼去建設，但因為業務需要，落地了一個 8000 節點級別的規模，所以也一直對爆炸半徑問題保持高度警惕，並透過一系列策略加以控制。

首先，小紅書在內部對叢集規模進行了嚴格限制。為了防止叢集規模過大帶來的爆炸半徑風險，每個叢集設定了水位線，當規模達到上限後，將停止承接新業務，僅對存量業務進行擴容。

隨著 K8s 原生化的發展，越來越多的業務方開始自行開發 Operator，並透過 K8s 管控面與業務系統進行互動。對此，小紅書制定了嚴格的規範，禁止業務方將 K8s 管控面作為核心資料鏈路，要求儘可能使用快取，並對高頻訪問進行限流，以防止管控面被打掛。

同時，小紅書還透過定期巡檢和治理機制，及時發現並修復不規範的使用方式，確保叢集在高併發、高負載場景下的穩定性。

此外，在架構設計上，還將管控面不可用作為極端情況下的前提條件，並以此為基礎進行了容災設計。

當然，相較於阿里雲支援的 1.5 萬節點叢集，小紅書叢集由於計算節點多采用大規格配置，對單叢集規模的實際需求較低，因此整體規模相對較小；在管控面加固方面，小紅書充分借鑑行業成熟方案，從而有效提升了平臺的穩定性與安全性。

“雲計算的標準化交付恰恰為滿足企業個性化需求提供了前提。”林格強調。

技術路徑並非非此即彼, 在 ACK 等標準化能力基礎上，透過共建的方式滿足個性化需求，小紅書實現了業務場景精細化資源效率管理與業務穩定性的動態平衡。

在混部架構與資源排程最佳化的驅動下，小紅書成功將叢集資源利用率提升至 40%，這一數字背後是核心調優、精細化排程策略及資源池最佳化的協同作用。

值得注意的是，小紅書團隊對雲原生演進方向的判斷與社群趨勢高度契合：簡化複雜性與適配新興場景將成為下一階段的關鍵。小紅書技術團隊指出，大家都認為雲原生“好”，但是想把它真的用起來卻太難，所以我們需要破解雲原生技術的“複雜度悖論”。

正如團隊所強調的，雲原生的價值在於持續解決業務的實際問題。面對 AI 驅動的算力革命與混合架構的常態化，小紅書的技術實踐或將為行業提供一條可參考的路徑——在效率與靈活性之間尋找平衡，以持續演進的架構能力迎接未來的業務挑戰。

更進一步看，今天的雲計算，已經成為 IT 技術歷史中，最重要的一筆——它橫跨 Web 時代、移動網際網路時代、AI 時代，不斷進化，極大地降低了企業的 IT 成本，將基礎設施企業與技術企業、平臺企業、應用企業緊緊連線在一起。

當我們回望阿里雲彈性計算 15 年技術演進軌跡，這條路徑清晰勾勒出雲計算與時代需求的同頻共振——從早期助力傳統企業叩開網際網路大門，到深度陪伴網際網路企業完成從業務上雲到架構雲原生化的蛻變，直至今日成為 AI 時代算力革命的核心基礎設施。這場持續升級的底層邏輯，始終圍繞 "讓算力服務於業務價值" 展開：在基礎資源層構建兼具彈性擴充套件能力與極致效能的算力矩陣（如 ECS AMD 例項提供的高效能算力選項），在排程管理層打造覆蓋 "算力供給 – 資源排程 – 應用交付" 的全鏈路閉環（如容器服務 ACK 實現的高效應用管理），形成支撐企業數字化轉型的技術底座。

從虛擬化技術的突破到智慧混部排程，每一次技術跨越是都在踐行 "降低用雲門檻" 的普惠理念。在 AI 重塑產業的當下，阿里雲彈性計算將繼續與客戶並肩同行，不止是為 AI 企業提供支撐大模型訓練、智慧推理的澎湃算力，更是技術演進的同路人。在持續迭代的架構創新中為企業開啟業務增長的新空間，讓雲計算真正成為跨越時代的技術核心紐帶。