万字解读：小红书是怎么用云的？

创业初期，小红书与多数互联网公司一样，采用相对“单调”的上云、用云策略。

但当容器化率突破 80%、资源量突破数百万核 CPU 时，粗放用云模式的代价开始显现：集群利用率明显低于其他互联网企业，跨云环境的应用部署复杂度飙升，可观测性和运维能力面临新挑战。同时，还要充分满足业务快速稳定迭代的诉求，灵活应对市场和业务变化。

技术团队清醒意识到，需要在云厂商基础设施之上构建一系列小红书独有的云原生技术中台能力。

面对既要延续技术积累又要突破发展瓶颈的双重课题，小红书技术团队选择了一条独特的技术路径：没有陷入 “推倒重来” 或 “简单复用” 的二元对立，在多云的资源结构下，以阿里云容器服务 ACK + 云服务器 ECS 构建稳固云基座，将小红书特有的社区电商、内容分发等复杂业务场景需求，与阿里云开源项目 OpenKruise（已捐赠给 CNCF）、Koordinator 的技术优势深度融合。这种 “云基座打底 - 通过开源共建满足个性化需求” 的创新模式，既能在保留原有技术架构核心价值的基础上，通过深度定制的方式满足高效稳定的业务用云需求；又能通过开源共建的方式，让小红书的技术具备足够的先进性与可持续性。

InfoQ 与小红书技术团队、阿里云技术团队分别聊了聊，希望能尽可能完整地复盘本次云上创新，也为业界贡献更多技术选型的思路和案例。

小红书云原生平台

2018 年，小红书迈出了容器化建设的第一步。

云服务为小红书带来了显著的便捷，能在几分钟内创建 Kubernetes（K8s）集群并交付机器。但与此同时，对于小红书团队而言，新的管理挑战也随之浮现。

早期小红书允许各业务线自行申请独立集群，虽然单个集群规模不大，却因数量庞大，且缺乏专业团队维护，致使 K8s 版本高度碎片化。许多集群长期停留在初始申请版本。不同版本的 K8s 在资源调度、管理策略上存在差异，无法统一优化资源分配，加上低版本缺少高效资源管理特性和性能优化，无法充分利用硬件资源。

更深层次的问题在于，资源效能与业务稳定性之间存在天然的矛盾。正如小红书云原生平台负责人林格所说：“过去我们总是依靠资源冗余来保障稳定性，资源和应用架构的云原生化相对滞后。”

面对这些挑战，小红书开始反思：在增强业务稳定性、资源调度和架构优化方面，是否有更成熟的行业方案可借鉴？毕竟，云原生发展已有十年，但许多企业仍停留在“用容器但不做调度”的阶段，即使这种做法在企业快速成长时期难以避免。

OpenKruise 和 Koordinator 这两个开源项目，正是在这样的背景下，开始进入小红书团队的视野。

先看看 OpenKruise 。OpenKruise 是 Kubernetes 扩展套件，专注于云原生应用的自动化管理，包括部署、发布、运维及高可用性防护。通常被用来解决有状态服务云原生化的一些问题，和 Kubernetes 官方工具 StatefulSet 定位接近。

但在选择有状态应用编排工具的技术选型中，小红书团队放弃了 StatefulSet，转而选择了 OpenKruise。

原因在于，在小红书有状态应用容器化场景中，核心业务主要包含以下两类技术形态：

1. 数据密集型有状态服务，比如：Kafka、Mysql、NoSQL

2. 分布式在线推理服务

• 搜索的 Merger-Searcher 架构：实现检索与排序解耦，通过异构 Pod（检索节点与排序节点）协同工作

• 稀疏模型相关的（PS-Worker）训练架构：随着模型参数量和数据规模增长，此类服务需要数据分片化处理和分布式计算，这会导致应用内部 Pod 不再同质化，必须采用有状态的编排方式进行管理

总的来说，这些有状态编排的诉求可以分为 多角色 和 多分片 两大类。

StatefulSet 作为 Kubernetes 官方的有状态应用编排方案，在基础场景中能满足多分片 / 多角色应用的简单编排需求，但在企业级生产环境中面临显著局限性，主要体现在两个核心场景：

• 多副本分片部署场景：生产环境中的多分片应用（如分布式数据库、搜索推荐服务）通常需要 每个分片部署多副本 以保证业务高可用和负载均衡。而 StatefulSet 的默认设计为每个分片仅支持单 Pod，无法直接实现分片内的水平扩展。

• 大规模存储分片场景：当存储类应用（如 Kafka/MySQL 集群）数据量达到 PB 级时，动态分片扩容 和 跨分片数据均衡 成为刚需。

综上所述，社区 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 跟进、代码提交等方式，持续推动核心功能的完善，小红书的场景需求成为了开源组件设计的原生基因，让技术方案在一开始就烙上了生产级场景的印记。

图中为小红书（songzh215）与阿里云（zwzhang0107）

众所周知，调度领域很难做出一种完全通用的方案，尤其当业务规模达到一定体量后，往往会出现许多定制化需求。而这种开源协作形式以及最终形成的方案，对很多类似企业都具有重要的参考价值。而且面对中国开源生态中“昙花一现”的挑战，这种以真实场景驱动、多方持续投入的深度共建模式，或许正是维持社区生命力的关键。

ACK 为核心的技术底座高效支撑小红书落地混部

以上只是解决了小红书在开源层面的选型问题，在混部方案启动后，如何进一步提升收益、避免资源浪费，保障传统核心业务的高效运行，又能从调度层面解决不同业务间的资源供给问题，成为了下一阶段的核心命题。

这是一个涉及业务和基础设施层面的整体工程，要求对调度系统、内核等多个维度进行优化，同时还要在业务指标中引入响应时间（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，使得在高并发、大规模计算任务下，系统能够保持更高的稳定性和效率。

eRDMA 加速搜推广混部集群性能示意图

在超大规模计算（大 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 万节点的挑战过程中，针对控制面和数据面进行了多项优化。

ACK 的控制面与数据面优化

在 AI 和大规模弹性场景下，单集群规模扩大会导致资源膨胀，对控制面和数据面提出更高要求。节点数增至 5000 时，控制面压力显著增加，表现为内存与 CPU 消耗成倍增长，以及 API Server 稳定性问题 —— 控制面需缓存全部数据面资源信息，导致资源占用远高于常规集群。ACK 针对控制面组件实施多项优化：

• API Server：作为控制面核心，其稳定性至关重要。ACK 引入自动化弹性扩容和限流机制，采用 KON K 架构将 API Server Pod 部署在专属集群，可根据负载动态调整副本数，秒级完成弹性扩容。

• ETCD：作为有状态组件，采用三副本架构，引入自动化垂直弹性扩容（VPA），紧急时自动扩展资源配置；将社区版存储空间优化，默认提升 quota，解决存储瓶颈。

• 限流机制：当扩容后压力仍较大时，主动限制数据面部分访问以保障控制面稳定，恢复后自动解除。该机制避免了类似 OpenAI 因 API Server 压力导致的集群失控问题，确保用户对集群的控制权。

数据面的优化主要针对大规模弹性场景（如小红书离线任务）：

• 节点初始化并行化处理组件部署、OpenAPI 访问等步骤，提升启动速度。

• 优化 Pod 创建与事件推送效率，加快数据面弹性响应。

事实上，在应对单集群 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 企业提供支撑大模型训练、智能推理的澎湃算力，更是技术演进的同路人。在持续迭代的架构创新中为企业打开业务增长的新空间，让云计算真正成为跨越时代的技术核心纽带。