创业初期，小红书与多数互联网公司一样，采用相对“单调”的上云、用云策略。
但当容器化率突破80%、资源量突破数百万核CPU时，粗放用云模式的代价开始显现：集群利用率明显低于其他互联网企业，跨云环境的应用部署复杂度飙升，可观测性和运维能力面临新挑战。同时，还要充分满足业务快速稳定迭代的诉求，灵活应对市场和业务变化。
技术团队清醒意识到，需要在云厂商基础设施之上构建一系列小红书独有的云原生技术中台能力。
面对既要延续技术积累又要突破发展瓶颈的双重课题，小红书技术团队选择了一条独特的技术路径：没有陷入“推倒重来”或“简单复用”的二元对立，在多云的资源结构下，以阿里云容器服务ACK+云服务器ECS构建稳固云基座，将小红书特有的社区电商、内容分发等复杂业务场景需求，与阿里云开源项目OpenKruise(已捐赠给CNCF)、Koordinator的技术优势深度融合。这种“云基座打底-通过开源共建满足个性化需求”的创新模式，既能在保留原有技术架构核心价值的基础上，通过深度定制的方式满足高效稳定的业务用云需求;又能通过开源共建的方式，让小红书的技术具备足够的先进性与可持续性。
InfoQ与小红书技术团队、阿里云技术团队分别聊了聊，希望能尽可能完整地复盘本次云上创新，也为业界贡献更多技术选型的思路和案例。
云服务为小红书带来了显著的便捷，能在几分钟内创建Kubernetes(K8s)集群并交付机器。但与此同时，对于小红书团队而言，新的管理挑战也随之浮现。
早期小红书允许各业务线自行申请独立集群，虽然单个集群规模不大，却因数量庞大，且缺乏专业团队维护，致使K8s版本高度碎片化。许多集群长期停留在初始申请版本。不同版本的K8s在资源调度、管理策略上存在差异，无法统一优化资源分配，加上低版本缺少高效资源管理特性和性能优化，无法充分利用硬件资源。
更深层次的问题在于，资源效能与业务稳定性之间存在天然的矛盾。正如小红书云原生平台负责人林格所说：“过去我们总是依靠资源冗余来保障稳定性，资源和应用架构的云原生化相对滞后。”
面对这些挑战，小红书开始反思：在增强业务稳定性、资源调度和架构优化方面，是否有更成熟的行业方案可借鉴？毕竟，云原生发展已有十年，但许多企业仍停留在“用容器但不做调度”的阶段，即使这种做法在企业快速成长时期难以避免。
原因在于，在小红书有状态应用容器化场景中，核心业务主要包含以下两类技术形态：
稀疏模型相关的(PS-Worker)训练架构：随着模型参数量和数据规模增长，此类服务需要数据分片化处理和分布式计算，这会导致应用内部Pod不再同质化，必须采用有状态的编排方式进行管理
StatefulSet作为Kubernetes官方的有状态应用编排方案，在基础场景中能满足多分片/多角色应用的简单编排需求，但在企业级生产环境中面临显著局限性，主要体现在两个核心场景：
多副本分片部署场景：生产环境中的多分片应用(如分布式数据库、搜索推荐服务)通常需要每个分片部署多副本以保证业务高可用和负载均衡。而StatefulSet的默认设计为每个分片仅支持单Pod，无法直接实现分片内的水平扩展。
小红书把这些应用的编排形态抽象成了一个二维矩阵，并称为行列编排，其中一列代表一个分片，行数代表了一个分片的副本数量。当发现上游对服务的调用量增加，可以在行的维度进行扩容;另一方面，当数据量发生变化，可以在列的维度进行扩容。
在这个过程中，小红书技术团队发现OpenKruise的UnitedDeployment可以提供关键技术支撑。并根据业务场景构建统一工作负载模型，封装到小红书云原生平台中，解决小红书内部有状态服务的编排问题。
2023年初，随着资源规模扩大，对资源效能的要求提高，公司开始构建自主的混部调度能力。不同于以往在资源压力较小时，仅依靠简单的资源腾挪、二次调度和碎片治理，此次调整是一次更深层次的架构升级。
然而，小红书云原生架构师熊峰也强调，必须构建自己的协调层，这样才能真正掌控技术栈。
这源于小红书本身业务需求的特殊性，在混部和相关能力增强方面，很难在业内找到开箱即用的方案。因此，需要进一步的定制化，构建更符合业务需求且易用的上层能力，形成一个可插拔、可扩展的调度体系。在保障核心业务稳定性的基础上，进一步提升资源编排和调度的效率。
无论是快手、美团、滴滴还是小红书，大家在进入原生化深水区时遇到的问题和需求，*终有相当一部分会归结到调度及其相关领域上。对于小红书而言，混部技术正是小红书云原生平台能力的核心战场。
“选择Koordinator，既有历史路径依赖，也有技术理性。”林格解释。早期小红书基于ACK搭建技术底座，Koordinator作为其开源延伸，天然适配现有架构;更重要的是，阿里内部多年混部实践为方案提供了“规模化验证”背书。
小红书深度参与了Koordinator社区的建设。在Koordinator开源初期，小红书就积极参与了方案讨论，并发现其资源模型抽象和QoS策略与小红书的思路一致，因此结合自身的具体场景进行了探索并参与社区代码提交。与其他开源架构相比，Koordinator底层构建了一个可插拔、可扩展的体系。基于这一特点，小红书并未完全照搬其架构，而是选择性地使用了部分组件或借鉴了其部分能力，并结合自研成果和内部积累的开源能力进行了整合。
值得注意的是，小红书与阿里云开源社区之间采用的，是一种带有共创性质的社区协作范式，打破了传统“用户提问题→云厂商做方案”的单向路径。
小红书早期就一直持续数月定期参与社区会议，并结合自身落地场景参与了技术方案设计。特别是离线混部、大数据生态融合等领域，资源画像和数据预测能力的早期proposal，均由小红书提供了场景和idea，并与阿里云社区开发者共同讨论实现路径。这种合作也催生了意料之外的“共鸣”：Koordinator开源团队也从小红书提出的Proxy组件方案中发现双方对架构设计理念和资源模型的理解竟高度一致，随即开放核心模块的代码共建。
通过issue跟进、代码提交等方式，持续推动核心功能的完善，小红书的场景需求成为了开源组件设计的原生基因，让技术方案在一开始就烙上了生产级场景的印记。
众所周知，调度领域很难做出一种完全通用的方案，尤其当业务规模达到一定体量后，往往会出现许多定制化需求。而这种开源协作形式以及*终形成的方案，对很多类似企业都具有重要的参考价值。而且面对中国开源生态中“昙花一现”的挑战，这种以真实场景驱动、多方持续投入的深度共建模式，或许正是维持社区生命力的关键。
以上只是解决了小红书在开源层面的选型问题，在混部方案启动后，如何进一步提升收益、避免资源浪费，保障传统核心业务的高效运行，又能从调度层面解决不同业务间的资源供给问题，成为了下一阶段的核心命题。
这是一个涉及业务和基础设施层面的整体工程，要求对调度系统、内核等多个维度进行优化，同时还要在业务指标中引入响应时间(RT)劣化率、CPU分层利用率等指标，以降低低效资源比例，倒逼架构优化。
在混部的情况下，首先需要确认的是资源供给方式。早期，小红书的许多业务在一定程度上将Pod和虚拟机绑定在一起。一台机器上通常只部署一到两个应用，导致迁移成本高、弹性差，并且由于负载特性相似，对资源的诉求同质化严重，比如流量到来后在某个时间这些业务同时将CPU打高，容易出现资源共振问题，影响系统稳定性。因此，要在同一节点上对不同业务进行混部，并为业务提供弹性和性能缓冲的空间非常有限。
于是技术团队突破性提出“大Node小Pod”策略：将物理节点规格做大，将应用拆小，实例增多并打散分布，既规避了虚拟化层潜在的资源干扰，又为跨业务混部创造了灵活的资源调度空间：在单机故障或出现热点问题时，可以更快速地进行应用迁移，从而减少停机时间和对业务的影响。
小红书进一步提升混部收益的一个非常关键的手段是将核心的一些业务线万核的计算资源，替换为了“大Node”的基于阿里云CIPU架构的大规格ECS实例。
“基于阿里云自研的CIPU架构的云服务器，确实帮了我们大忙。”林格强调。
小红书主力使用的是64核的VM与192核的整机规格服务器，其中整机规格的服务器作为大Node使用时，小红书能够直接掌控从CPU、内存到缓存的全量硬件资源，避免跨租户资源争抢导致的性能抖动。在推进“大Node、小Pod”策略时，这相当于提供了一种极限规格的大型计算节点能力。
除了高密度核心带来的性价比收益，还有一个是在大数据和搜推场景下的性能优势。
在深度学习驱动的搜推业务中，小红书采用PS-Worker分布式训练架构作为技术底座。该架构下，参数服务器需要在内存中存储并快速读取大量参数，那么内存带宽以及网络吞吐率都是重要的性能瓶颈点。
一是传统的VM由于虚拟化开销，会丢失部分内存带宽和Cache资源的隔离能力。而CIPU架构保留了这些能力，也能够接入VPC网络、云盘及访问大数据EMR系统的能力。这种特性使得服务器在保持云计算灵活性的同时，也能提供精细化的资源控制能力，包括内存带宽和L3Cache的调优，从而更好地适配大规模混部场景。
二是ECSAMD实例处理器在第八代升级中，将内存通道数从8个扩展到12个，并提升了内存速率，使得数据吞吐能力显著增强。同时，这代处理器还采用了先进工艺实现了硬件微架构上比如CPU内核密度、io等多方面的提升。除硬件外，在指令方面，不仅兼容了AVX512同时还支持了bf16，使得在高并发、大规模计算任务下，系统能够保持更高的稳定性和效率。
在超大规模计算(大Node)场景下，网络性能往往是影响整体计算效率的关键因素。PS-Worker节点里，网络的开销通常会在整个性能权重中占据很大一部分。
早期小红书集群资源管理粗放，存在大量业务独占资源池，导致资源池割裂、碎片化严重。业务为保障稳定性过度囤积资源，进一步加剧浪费。为此，小红书调整集群架构，建成包含7000至8000个节点的超大规模集群，成为云上单集群节点数*多的案例之一。
阿里云在应对单集群1.5万节点的挑战过程中，针对控制面和数据面进行了多项优化。
在AI和大规模弹性场景下，单集群规模扩大会导致资源膨胀，对控制面和数据面提出更高要求。节点数增至5000时，控制面压力显著增加，表现为内存与CPU消耗成倍增长，以及APIServer稳定性问题——控制面需缓存全部数据面资源信息，导致资源占用远高于常规集群。ACK针对控制面组件实施多项优化：
ETCD：作为有状态组件，采用三副本架构，引入自动化垂直弹性扩容(VPA)，紧急时自动扩展资源配置;将社区版存储空间优化，默认提升quota，解决存储瓶颈。
限流机制：当扩容后压力仍较大时，主动限制数据面部分访问以保障控制面稳定，恢复后自动解除。该机制避免了类似OpenAI因APIServer压力导致的集群失控问题，确保用户对集群的控制权。
数据面的优化主要针对大规模弹性场景(如小红书离线任务)：
节点初始化并行化处理组件部署、OpenAPI访问等步骤，提升启动速度。
当然，面对超大规模的集群管理，不同企业也会采用不同的策略。有些企业选择将业务拆分到多个小集群中，而有些则倾向于将大部分业务集中在少量的大集群中，以简化运维管理和降低发布复杂度。
作为用户，小红书本身不需要太关注管控面的稳定性该怎么去建设，但因为业务需要，落地了一个8000节点级别的规模，所以也一直对爆炸半径问题保持高度警惕，并通过一系列策略加以控制。
首先，小红书在内部对集群规模进行了严格限制。为了防止集群规模过大带来的爆炸半径风险，每个集群设定了水位线，当规模达到上限后，将停止承接新业务，仅对存量业务进行扩容。
随着K8s原生化的发展，越来越多的业务方开始自行开发Operator，并通过K8s管控面与业务系统进行交互。对此，小红书制定了严格的规范，禁止业务方将K8s管控面作为核心数据链路，要求尽可能使用缓存，并对高频访问进行限流，以防止管控面被打挂。
同时，小红书还通过定期巡检和治理机制，及时发现并修复不规范的使用方式，确保集群在高并发、高负载场景下的稳定性。
此外，在架构设计上，还将管控面不可用作为极端情况下的前提条件，并以此为基础进行了容灾设计。
当然，相较于阿里云支持的1.5万节点集群，小红书集群由于计算节点多采用大规格配置，对单集群规模的实际需求较低，因此整体规模相对较小;在管控面加固方面，小红书充分借鉴行业成熟方案，从而有效提升了平台的稳定性与安全性。
“云计算的标准化交付恰恰为满足企业个性化需求提供了前提。”林格强调。
技术路径并非非此即彼,在ACK等标准化能力基础上，通过共建的方式满足个性化需求，小红书实现了业务场景精细化资源效率管理与业务稳定性的动态平衡。
在混部架构与资源调度优化的驱动下，小红书成功将集群资源利用率提升至40%，这一数字背后是内核调优、精细化调度策略及资源池优化的协同作用。
值得注意的是，小红书团队对云原生演进方向的判断与社区趋势高度契合：简化复杂性与适配新兴场景将成为下一阶段的关键。小红书技术团队指出，大家都认为云原生“好”，但是想把它真的用起来却太难，所以我们需要破解云原生技术的“复杂度悖论”。
正如团队所强调的，云原生的价值在于持续解决业务的实际问题。面对AI驱动的算力革命与混合架构的常态化，小红书的技术实践或将为行业提供一条可参考的路径——在效率与灵活性之间寻找平衡，以持续演进的架构能力迎接未来的业务挑战。
更进一步看，今天的云计算，已经成为IT技术历史中，*重要的一笔——它横跨Web时代、移动互联网时代、AI时代，不断进化，极大地降低了企业的IT成本，将基础设施企业与技术企业、平台企业、应用企业紧紧连接在一起。
当我们回望阿里云弹性计算15年技术演进轨迹，这条路径清晰勾勒出云计算与时代需求的同频共振——从早期助力传统企业叩开互联网大门，到深度陪伴互联网企业完成从业务上云到架构云原生化的蜕变，直至今日成为AI时代算力革命的核心基础设施。这场持续升级的底层逻辑，始终围绕“让算力服务于业务价值”展开：在基础资源层构建兼具弹性扩展能力与极致性能的算力矩阵(如ECSAMD实例提供的高性能算力选项)，在调度管理层打造覆盖“算力供给-资源调度-应用交付”的全链路闭环(如容器服务ACK实现的高效应用管理)，形成支撑企业数字化转型的技术底座。
从虚拟化技术的突破到智能混部调度，每一次技术跨越都是在践行“降低用云门槛”的普惠理念。在AI重塑产业的当下，阿里云弹性计算将继续与客户并肩同行，不止是为AI企业提供支撑大模型训练、智能推理的澎湃算力，更是技术演进的同路人。在持续迭代的架构创新中为企业打开业务增长的新空间，让云计算真正成为跨越时代的技术核心纽带。
