創(chuàng)業(yè)初期，小紅書與多數互聯網公司一樣，采用相對“單調”的上云、用云策略。
但當容器化率突破 80%、資源量突破數百萬核 CPU 時，粗放用云模式的代價開始顯現：集群利用率明顯低于其他互聯網企業(yè)，跨云環(huán)境的應用部署復雜度飆升，可觀測性和運維能力面臨新挑戰(zhàn)。同時，還要充分滿足業(yè)務快速穩(wěn)定迭代的訴求，靈活應對市場和業(yè)務變化。
技術團隊清醒意識到，需要在云廠商基礎設施之上構建一系列小紅書獨有的云原生技術中臺能力。
面對既要延續(xù)技術積累又要突破發(fā)展瓶頸的雙重課題，小紅書技術團隊選擇了一條獨特的技術路徑：沒有陷入 “推倒重來” 或 “簡單復用” 的二元對立，在多云的資源結構下，以阿里云容器服務 ACK + 云服務器 ECS 構建穩(wěn)固云基座，將小紅書特有的社區(qū)電商、內容分發(fā)等復雜業(yè)務場景需求，與阿里云開源項目 OpenKruise（已捐贈給 CNCF）、Koordinator 的技術優(yōu)勢深度融合。這種 “云基座打底 – 通過開源共建滿足個性化需求” 的創(chuàng)新模式，既能在保留原有技術架構核心價值的基礎上，通過深度定制的方式滿足高效穩(wěn)定的業(yè)務用云需求；又能通過開源共建的方式，讓小紅書的技術具備足夠的先進性與可持續(xù)性。
InfoQ 與小紅書技術團隊、阿里云技術團隊分別聊了聊，希望能盡可能完整地復盤本次云上創(chuàng)新，也為業(yè)界貢獻更多技術選型的思路和案例。
小紅書云原生平臺
2018 年，小紅書邁出了容器化建設的第一步。
云服務為小紅書帶來了顯著的便捷，能在幾分鐘內創(chuàng)建 Kubernetes（K8s）集群并交付機器。但與此同時，對于小紅書團隊而言，新的管理挑戰(zhàn)也隨之浮現。
早期小紅書允許各業(yè)務線自行申請獨立集群，雖然單個集群規(guī)模不大，卻因數量龐大，且缺乏專業(yè)團隊維護，致使 K8s 版本高度碎片化。許多集群長期停留在初始申請版本。不同版本的 K8s 在資源調度、管理策略上存在差異，無法統(tǒng)一優(yōu)化資源分配，加上低版本缺少高效資源管理特性和性能優(yōu)化，無法充分利用硬件資源。
更深層次的問題在于，資源效能與業(yè)務穩(wěn)定性之間存在天然的矛盾。正如小紅書云原生平臺負責人林格所說：“過去我們總是依靠資源冗余來保障穩(wěn)定性，資源和應用架構的云原生化相對滯后?！?/p>
面對這些挑戰(zhàn)，小紅書開始反思：在增強業(yè)務穩(wěn)定性、資源調度和架構優(yōu)化方面，是否有更成熟的行業(yè)方案可借鑒？畢竟，云原生發(fā)展已有十年，但許多企業(yè)仍停留在“用容器但不做調度”的階段，即使這種做法在企業(yè)快速成長時期難以避免。
OpenKruise 和 Koordinator 這兩個開源項目，正是在這樣的背景下，開始進入小紅書團隊的視野。
先看看 OpenKruise 。OpenKruise 是 Kubernetes 擴展套件，專注于云原生應用的自動化管理，包括部署、發(fā)布、運維及高可用性防護。通常被用來解決有狀態(tài)服務云原生化的一些問題，和 Kubernetes 官方工具 StatefulSet 定位接近。
但在選擇有狀態(tài)應用編排工具的技術選型中，小紅書團隊放棄了 StatefulSet，轉而選擇了 OpenKruise。
原因在于，在小紅書有狀態(tài)應用容器化場景中，核心業(yè)務主要包含以下兩類技術形態(tài)：
數據密集型有狀態(tài)服務，比如：Kafka、Mysql、NoSQL
分布式在線推理服務
搜索的 Merger-Searcher 架構：實現檢索與排序解耦，通過異構 Pod（檢索節(jié)點與排序節(jié)點）協(xié)同工作
稀疏模型相關的（PS-Worker）訓練架構：隨著模型參數量和數據規(guī)模增長，此類服務需要數據分片化處理和分布式計算，這會導致應用內部 Pod 不再同質化，必須采用有狀態(tài)的編排方式進行管理
總的來說，這些有狀態(tài)編排的訴求可以分為 多角色 和 多分片 兩大類。
StatefulSet 作為 Kubernetes 官方的有狀態(tài)應用編排方案，在基礎場景中能滿足多分片 / 多角色應用的簡單編排需求，但在企業(yè)級生產環(huán)境中面臨顯著局限性，主要體現在兩個核心場景：
多副本分片部署場景：生產環(huán)境中的多分片應用（如分布式數據庫、搜索推薦服務）通常需要 每個分片部署多副本 以保證業(yè)務高可用和負載均衡。而 StatefulSet 的默認設計為每個分片僅支持單 Pod，無法直接實現分片內的水平擴展。
大規(guī)模存儲分片場景：當存儲類應用（如 Kafka/MySQL 集群）數據量達到 PB 級時，動態(tài)分片擴容 和 跨分片數據均衡 成為剛需。
綜上所述，社區(qū) StatefulSet 并不能滿足生產級要求。
小紅書把這些應用的編排形態(tài)抽象成了一個二維矩陣，并稱為行列編排，其中一列代表一個分片，行數代表了一個分片的副本數量。當發(fā)現上游對服務的調用量增加，可以在行的維度進行擴容；另一方面，當數據量發(fā)生變化，可以在列的維度進行擴容。
在這個過程中，小紅書技術團隊發(fā)現 OpenKruise 的 UnitedDeployment 可以提供關鍵技術支撐。并根據業(yè)務場景構建統(tǒng)一工作負載模型，封裝到小紅書云原生平臺中，解決小紅書內部有狀態(tài)服務的編排問題。
而選擇 Koordinator，則是為了重點解決資源調度問題。
2023 年初，隨著資源規(guī)模擴大，對資源效能的要求提高，公司開始構建自主的混部調度能力。不同于以往在資源壓力較小時，僅依靠簡單的資源騰挪、二次調度和碎片治理，此次調整是一次更深層次的架構升級。
然而，小紅書云原生架構師熊峰也強調，必須構建自己的協(xié)調層，這樣才能真正掌控技術棧。
這源于小紅書本身業(yè)務需求的特殊性，在混部和相關能力增強方面，很難在業(yè)內找到開箱即用的方案。因此，需要進一步的定制化，構建更符合業(yè)務需求且易用的上層能力，形成一個可插拔、可擴展的調度體系。在保障核心業(yè)務穩(wěn)定性的基礎上，進一步提升資源編排和調度的效率。
無論是快手、美團、滴滴還是小紅書，大家在進入原生化深水區(qū)時遇到的問題和需求，最終有相當一部分會歸結到調度及其相關領域上。對于小紅書而言，混部技術正是小紅書云原生平臺能力的核心戰(zhàn)場。
2023 年初，團隊在多種社區(qū)開源方案中反復權衡，最終，他們選擇了阿里云開源的 Koordinator。
“選擇 Koordinator，既有歷史路徑依賴，也有技術理性?！绷指窠忉尅Ｔ缙谛〖t書基于 ACK 搭建技術底座，Koordinator 作為其開源延伸，天然適配現有架構；更重要的是，阿里內部多年混部實踐為方案提供了“規(guī)?；炞C”背書。
小紅書深度參與了 Koordinator 社區(qū)的建設。在 Koordinator 開源初期，小紅書就積極參與了方案討論，并發(fā)現其資源模型抽象和 QoS 策略與小紅書的思路一致，因此結合自身的具體場景進行了探索并參與社區(qū)代碼提交。與其他開源架構相比，Koordinator 底層構建了一個可插拔、可擴展的體系。基于這一特點，小紅書并未完全照搬其架構，而是選擇性地使用了部分組件或借鑒了其部分能力，并結合自研成果和內部積累的開源能力進行了整合。
小紅書的案例在業(yè)內具有普遍性，特別是在大數據調度方面。許多客戶由于各種原因仍依賴現有調度方式，無法立即切換至 K8s 原生的 Operator 調度模式。為了解決 EMR 場景下的資源效能問題，小紅書自 2023 年 5 月起開始啟動 YARN & K8s 混部方案。
最初階段，小紅書主要進行技術探索。同業(yè)界其他 Yarn on K8s 方案不同的是，小紅書并未對 Yarn 進行侵入式改造，而是基于開源 Yarn 版本進行開發(fā)。在過去一年中，小紅書的 Yarn 與 K8s 混合調度方案逐漸成熟，規(guī)模也在持續(xù)擴大，覆蓋了數萬臺節(jié)點，提供了數十萬核資源，效果也很明顯：CPU 利用率平均增長 8%~10%，部分達到 45% 以上。在此基礎上，團隊進一步嘗試優(yōu)化 Yarn on K8s 的方案。短期目標是提升資源復用率和效能，而長期規(guī)劃是借鑒 Koordinator 的統(tǒng)一調度理念，在 K8s 中支持 Spark 和 Flink 等業(yè)務的統(tǒng)一調度，從兩套調度體系并存演進為統(tǒng)一調度，逐步實現從 Yarn 向 K8s 的切換過渡。最終，Yarn 將逐步退出歷史舞臺，K8s 生態(tài)則需全面承接大數據負載。
值得注意的是，小紅書與阿里云開源社區(qū)之間采用的，是一種帶有共創(chuàng)性質的社區(qū)協(xié)作范式，打破了傳統(tǒng)“用戶提問題→云廠商做方案”的單向路徑。
小紅書早期就一直持續(xù)數月定期參與社區(qū)會議，并結合自身落地場景參與了技術方案設計。特別是離線混部、大數據生態(tài)融合等領域，資源畫像和數據預測能力的早期 proposal，均由小紅書提供了場景和 idea，并與阿里云社區(qū)開發(fā)者共同討論實現路徑。這種合作也催生了意料之外的“共鳴”：Koordinator 開源團隊也從小紅書提出的 Proxy 組件方案中發(fā)現雙方對架構設計理念和資源模型的理解竟高度一致，隨即開放核心模塊的代碼共建。
通過 issue 跟進、代碼提交等方式，持續(xù)推動核心功能的完善，小紅書的場景需求成為了開源組件設計的原生基因，讓技術方案在一開始就烙上了生產級場景的印記。
眾所周知，調度領域很難做出一種完全通用的方案，尤其當業(yè)務規(guī)模達到一定體量后，往往會出現許多定制化需求。而這種開源協(xié)作形式以及最終形成的方案，對很多類似企業(yè)都具有重要的參考價值。而且面對中國開源生態(tài)中“曇花一現”的挑戰(zhàn)，這種以真實場景驅動、多方持續(xù)投入的深度共建模式，或許正是維持社區(qū)生命力的關鍵。
ACK 為核心的技術底座高效支撐小紅書落地混部
以上只是解決了小紅書在開源層面的選型問題，在混部方案啟動后，如何進一步提升收益、避免資源浪費，保障傳統(tǒng)核心業(yè)務的高效運行，又能從調度層面解決不同業(yè)務間的資源供給問題，成為了下一階段的核心命題。
這是一個涉及業(yè)務和基礎設施層面的整體工程，要求對調度系統(tǒng)、內核等多個維度進行優(yōu)化，同時還要在業(yè)務指標中引入響應時間（RT）劣化率、CPU 分層利用率等指標，以降低低效資源比例，倒逼架構優(yōu)化。
在這一系統(tǒng)性工程中，“大 Node 小 Pod”成為小紅書混部落地的核心方法論。
在混部的情況下，首先需要確認的是資源供給方式。早期，小紅書的許多業(yè)務在一定程度上將 Pod 和虛擬機綁定在一起。一臺機器上通常只部署一到兩個應用，導致遷移成本高、彈性差，并且由于負載特性相似，對資源的訴求同質化嚴重，比如流量到來后在某個時間這些業(yè)務同時將 CPU 打高，容易出現資源共振問題，影響系統(tǒng)穩(wěn)定性。因此，要在同一節(jié)點上對不同業(yè)務進行混部，并為業(yè)務提供彈性和性能緩沖的空間非常有限。
于是技術團隊突破性提出“大 Node 小 Pod”策略：將物理節(jié)點規(guī)格做大，將應用拆小，實例增多并打散分布，既規(guī)避了虛擬化層潛在的資源干擾，又為跨業(yè)務混部創(chuàng)造了靈活的資源調度空間：在單機故障或出現熱點問題時，可以更快速地進行應用遷移，從而減少停機時間和對業(yè)務的影響。
小紅書進一步提升混部收益的一個非常關鍵的手段是將核心的一些業(yè)務線，約 50 萬核的計算資源，替換為了“大 Node”的基于阿里云 CIPU 架構的大規(guī)格 ECS 實例。
“基于阿里云自研的 CIPU 架構的云服務器，確實幫了我們大忙?！绷指駨娬{。
小紅書主力使用的是 64 核的 VM 與 192 核的整機規(guī)格服務器，其中整機規(guī)格的服務器作為大 Node 使用時，小紅書能夠直接掌控從 CPU、內存到緩存的全量硬件資源，避免跨租戶資源爭搶導致的性能抖動。在推進“大 Node、小 Pod”策略時，這相當于提供了一種極限規(guī)格的大型計算節(jié)點能力。
在構建大規(guī)模計算節(jié)點時，阿里云云服務器 ECS AMD 實例（以下簡稱 ECS AMD 實例）是小紅書在大 Node 方案中的另一個重要選擇。ECS AMD 實例構建在多層技術架構之上，最底層是 AMD CPU 芯片，并疊加阿里云自研的 CIPU 架構，其上一層為容器相關產品如容器服務 Kubernetes 版 ACK（以下簡稱 ACK），最上層則是用戶的應用層。
自 2022 年起，小紅書便開始采用 ECS AMD 實例。近年來，特別是第八代推出后，CPU 能力方面得到了更大提升。例如，主頻提升到 2.7GHz，最高睿頻到 3.7GHz，核心密度不斷優(yōu)化，同時相比上一代單核的二級緩存提升一倍，IPC 提升了 14%，使其在相同功耗水平下算力提升約 25%。
除了高密度核心帶來的性價比收益，還有一個是在大數據和搜推場景下的性能優(yōu)勢。
在深度學習驅動的搜推業(yè)務中，小紅書采用 PS-Worker 分布式訓練架構作為技術底座。該架構下，參數服務器需要在內存中存儲并快速讀取大量參數，那么內存帶寬以及網絡吞吐率都是重要的性能瓶頸點。
為了突破這些瓶頸，小紅書選擇基于阿里云自研的 CIPU 架構的 ECS AMD 實例，將內存帶寬提升 125%，達到 350GB。
這一顯著提升，主要來自兩個方面。
一是傳統(tǒng)的 VM 由于虛擬化開銷，會丟失部分內存帶寬和 Cache 資源的隔離能力。而 CIPU 架構保留了這些能力，也能夠接入 VPC 網絡、云盤及訪問大數據 EMR 系統(tǒng)的能力。這種特性使得服務器在保持云計算靈活性的同時，也能提供精細化的資源控制能力，包括內存帶寬和 L3 Cache 的調優(yōu)，從而更好地適配大規(guī)模混部場景。
二是 ECS AMD 實例處理器在第八代升級中，將內存通道數從 8 個擴展到 12 個，并提升了內存速率，使得數據吞吐能力顯著增強。同時，這代處理器還采用了先進工藝實現了硬件微架構上比如 CPU 內核密度、io 等多方面的提升。除硬件外，在指令方面，不僅兼容了 AVX512 同時還支持了 bf16，使得在高并發(fā)、大規(guī)模計算任務下，系統(tǒng)能夠保持更高的穩(wěn)定性和效率。
在超大規(guī)模計算（大 Node）場景下，網絡性能往往是影響整體計算效率的關鍵因素。PS-Worker 節(jié)點里，網絡的開銷通常會在整個性能權重中占據很大一部分。
CIPU 架構引入的 eRDMA（Elastic RDMA）網絡，以其低時延、高吞吐性能使大 Node 之間的數據傳輸時延最低可達 8-10 微秒，相比傳統(tǒng) VPC 網絡，通信開銷降低達 45%。結合任務并行度優(yōu)化算法，使 AI 訓練和在線推理的長尾延遲顯著改善。
超大集群規(guī)模支持
早期小紅書集群資源管理粗放，存在大量業(yè)務獨占資源池，導致資源池割裂、碎片化嚴重。業(yè)務為保障穩(wěn)定性過度囤積資源，進一步加劇浪費。為此，小紅書調整集群架構，建成包含 7000 至 8000 個節(jié)點的超大規(guī)模集群，成為云上單集群節(jié)點數最多的案例之一。
在業(yè)內，突破 K8s 社區(qū)的節(jié)點規(guī)模上限，一直被視為衡量技術能力的重要指標。隨著阿里云產品能力的不斷提升，ACK 目前對外承諾的單集群節(jié)點上限已達到 1.5 萬個節(jié)點。這意味著，從 K8s 社區(qū)推薦的 5000 節(jié)點，到 ACK 支持的 1.5 萬節(jié)點，規(guī)模足足提升了三倍。
阿里云在應對單集群 1.5 萬節(jié)點的挑戰(zhàn)過程中，針對控制面和數據面進行了多項優(yōu)化。
ACK 的控制面與數據面優(yōu)化
在 AI 和大規(guī)模彈性場景下，單集群規(guī)模擴大會導致資源膨脹，對控制面和數據面提出更高要求。節(jié)點數增至 5000 時，控制面壓力顯著增加，表現為內存與 CPU 消耗成倍增長，以及 API Server 穩(wěn)定性問題 —— 控制面需緩存全部數據面資源信息，導致資源占用遠高于常規(guī)集群。ACK 針對控制面組件實施多項優(yōu)化：
API Server：作為控制面核心，其穩(wěn)定性至關重要。ACK 引入自動化彈性擴容和限流機制，采用 KON K 架構將 API Server Pod 部署在專屬集群，可根據負載動態(tài)調整副本數，秒級完成彈性擴容。
ETCD：作為有狀態(tài)組件，采用三副本架構，引入自動化垂直彈性擴容（VPA），緊急時自動擴展資源配置；將社區(qū)版存儲空間優(yōu)化，默認提升 quota，解決存儲瓶頸。
限流機制：當擴容后壓力仍較大時，主動限制數據面部分訪問以保障控制面穩(wěn)定，恢復后自動解除。該機制避免了類似 OpenAI 因 API Server 壓力導致的集群失控問題，確保用戶對集群的控制權。
數據面的優(yōu)化主要針對大規(guī)模彈性場景（如小紅書離線任務）：
節(jié)點初始化并行化處理組件部署、OpenAPI 訪問等步驟，提升啟動速度。
優(yōu)化 Pod 創(chuàng)建與事件推送效率，加快數據面彈性響應。
事實上，在應對單集群 1.5 萬節(jié)點挑戰(zhàn)過程中，ACK 的優(yōu)化不僅滿足了自身業(yè)務的高標準需求，還貢獻至 K8s 社區(qū)，有些優(yōu)化已在 1.30 版本中得到應用。
當然，面對超大規(guī)模的集群管理，不同企業(yè)也會采用不同的策略。有些企業(yè)選擇將業(yè)務拆分到多個小集群中，而有些則傾向于將大部分業(yè)務集中在少量的大集群中，以簡化運維管理和降低發(fā)布復雜度。
小紅書的集群管理策略
作為用戶，小紅書本身不需要太關注管控面的穩(wěn)定性該怎么去建設，但因為業(yè)務需要，落地了一個 8000 節(jié)點級別的規(guī)模，所以也一直對爆炸半徑問題保持高度警惕，并通過一系列策略加以控制。
首先，小紅書在內部對集群規(guī)模進行了嚴格限制。為了防止集群規(guī)模過大帶來的爆炸半徑風險，每個集群設定了水位線，當規(guī)模達到上限后，將停止承接新業(yè)務，僅對存量業(yè)務進行擴容。
隨著 K8s 原生化的發(fā)展，越來越多的業(yè)務方開始自行開發(fā) Operator，并通過 K8s 管控面與業(yè)務系統(tǒng)進行交互。對此，小紅書制定了嚴格的規(guī)范，禁止業(yè)務方將 K8s 管控面作為核心數據鏈路，要求盡可能使用緩存，并對高頻訪問進行限流，以防止管控面被打掛。
同時，小紅書還通過定期巡檢和治理機制，及時發(fā)現并修復不規(guī)范的使用方式，確保集群在高并發(fā)、高負載場景下的穩(wěn)定性。
此外，在架構設計上，還將管控面不可用作為極端情況下的前提條件，并以此為基礎進行了容災設計。
當然，相較于阿里云支持的 1.5 萬節(jié)點集群，小紅書集群由于計算節(jié)點多采用大規(guī)格配置，對單集群規(guī)模的實際需求較低，因此整體規(guī)模相對較小；在管控面加固方面，小紅書充分借鑒行業(yè)成熟方案，從而有效提升了平臺的穩(wěn)定性與安全性。
寫在最后
“云計算的標準化交付恰恰為滿足企業(yè)個性化需求提供了前提。”林格強調。
技術路徑并非非此即彼, 在 ACK 等標準化能力基礎上，通過共建的方式滿足個性化需求，小紅書實現了業(yè)務場景精細化資源效率管理與業(yè)務穩(wěn)定性的動態(tài)平衡。
在混部架構與資源調度優(yōu)化的驅動下，小紅書成功將集群資源利用率提升至 40%，這一數字背后是內核調優(yōu)、精細化調度策略及資源池優(yōu)化的協(xié)同作用。
值得注意的是，小紅書團隊對云原生演進方向的判斷與社區(qū)趨勢高度契合：簡化復雜性與適配新興場景將成為下一階段的關鍵。小紅書技術團隊指出，大家都認為云原生“好”，但是想把它真的用起來卻太難，所以我們需要破解云原生技術的“復雜度悖論”。
正如團隊所強調的，云原生的價值在于持續(xù)解決業(yè)務的實際問題。面對 AI 驅動的算力革命與混合架構的常態(tài)化，小紅書的技術實踐或將為行業(yè)提供一條可參考的路徑——在效率與靈活性之間尋找平衡，以持續(xù)演進的架構能力迎接未來的業(yè)務挑戰(zhàn)。
更進一步看，今天的云計算，已經成為 IT 技術歷史中，最重要的一筆——它橫跨 Web 時代、移動互聯網時代、AI 時代，不斷進化，極大地降低了企業(yè)的 IT 成本，將基礎設施企業(yè)與技術企業(yè)、平臺企業(yè)、應用企業(yè)緊緊連接在一起。
當我們回望阿里云彈性計算 15 年技術演進軌跡，這條路徑清晰勾勒出云計算與時代需求的同頻共振——從早期助力傳統(tǒng)企業(yè)叩開互聯網大門，到深度陪伴互聯網企業(yè)完成從業(yè)務上云到架構云原生化的蛻變，直至今日成為 AI 時代算力革命的核心基礎設施。這場持續(xù)升級的底層邏輯，始終圍繞 “讓算力服務于業(yè)務價值” 展開：在基礎資源層構建兼具彈性擴展能力與極致性能的算力矩陣（如 ECS AMD 實例提供的高性能算力選項），在調度管理層打造覆蓋 “算力供給 – 資源調度 – 應用交付” 的全鏈路閉環(huán)（如容器服務 ACK 實現的高效應用管理），形成支撐企業(yè)數字化轉型的技術底座。
從虛擬化技術的突破到智能混部調度，每一次技術跨越都是在踐行 “降低用云門檻” 的普惠理念。在 AI 重塑產業(yè)的當下，阿里云彈性計算將繼續(xù)與客戶并肩同行，不止是為 AI 企業(yè)提供支撐大模型訓練、智能推理的澎湃算力，更是技術演進的同路人。在持續(xù)迭代的架構創(chuàng)新中為企業(yè)打開業(yè)務增長的新空間，讓云計算真正成為跨越時代的技術核心紐帶。（作者：InfoQ）
