InfoQ 取小红书手艺团队、阿里云手艺团队别离聊了聊，但愿能尽可能完整地复盘本次云上立异，也为业界贡献更多手艺选型的思和案例。
这源于小红书本身营业需求的特殊性，正在混部和相关能力加强方面，很难正在业内找到开箱即用的方案。因而，需要进一步的定制化，建立更合适营业需求且易用的上层能力，构成一个可插拔、可扩展的安排系统。正在保障焦点营业不变性的根本上，进一步提拔资本编排和安排的效率。
小红书进一步提拔混部收益的一个很是环节的手段是将焦点的一些营业线 万核的计较资本，替代为了“大 Node”的基于阿里云 CIPU 架构的大规格 ECS 实例。
小红书的案例正在业内具有遍及性，出格是正在大数据安排方面。很多客户因为各类缘由仍依赖现有安排体例，无法当即切换至 K8s 原生的 Operator 安排模式。为领会决 EMR 场景下的资本效能问题，小红书自 2023 年 5 月起起头启动 YARN & K8s 混部方案。
限流机制：当扩容后压力仍较大时，自动数据面部门拜候以保障节制面不变，恢复后从动解除。该机制避免了雷同 OpenAI 因 API Server 压力导致的集群失控问题，确保用户对集群的节制权。
小红书深度参取了 Koordinator 社区的扶植。正在 Koordinator 开源初期，小红书就积极参取了方案会商，并发觉其资本模子笼统和 QoS 策略取小红书的思分歧，因而连系本身的具体场景进行了摸索并参取社区代码提交。取其他开源架构比拟，Koordinator 底层建立了一个可插拔、可扩展的系统。基于这一特点，小红书并未完全照搬其架构，而是选择性地利用了部门组件或自创了其部门能力，并连系自研和内部堆集的开源能力进行了整合。
晚期小红书答应各营业线自行申请集群，虽然单个集群规模不大，却因数量复杂，且缺乏专业团队，以致 K8s 版本高度碎片化。很多集群持久逗留正在初始申请版本。分歧版本的 K8s 正在资本安排、办理策略上存正在差别，无法同一优化资本分派，加上低版本贫乏高效资本办理特征和机能优化，无法充实操纵硬件资本。
当然，相较于阿里云支撑的 1。5 万节点集群，小红书集群因为计较节点多采用大规格设置装备摆设，对单集群规模的现实需求较低，因而全体规模相对较小；正在管控面加固方面，小红书充实自创行业成熟方案，从而无效提拔了平台的不变性取平安性。
正在深度进修驱动的搜推营业中，小红书采用 PS-Worker 分布式锻炼架构做为手艺底座。该架构下，参数办事器需要正在内存中存储并快速读取大量参数，那么内存带宽以及收集吞吐率都是主要的机能瓶颈点。
小红书把这些使用的编排形态笼统成了一个二维矩阵，并称为行列编排，此中一列代表一个分片，行数代表了一个分片的副本数量。当发觉上逛对办事的挪用量添加，能够外行的维度进行扩容；另一方面，当数据量发生变化，能够正在列的维度进行扩容。
更进一步看，今天的云计较，曾经成为 IT 手艺汗青中，最主要的一笔它横跨 Web 时代、挪动互联网时代、AI 时代，不竭进化，极大地降低了企业的 IT 成本，将根本设备企业取手艺企业、平台企业、使用企业紧紧毗连正在一路。
无论是快手、美团、滴滴仍是小红书，大师正在进入原生化深水区时碰到的问题和需求，最终有相当一部门会归结到安排及其相关范畴上。对于小红书而言，混部手艺恰是小红书云原生平台能力的焦点疆场。
“选择 Koordinator，既有汗青径依赖，也有手艺。”林格注释。晚期小红书基于 ACK 搭建手艺底座，Koordinator 做为其开源延长，天然适配现有架构；更主要的是，阿里内部多年混部实践为方案供给了“规模化验证”背书。
做为用户，小红书本身不需要太关心管控面的不变性该怎样去扶植，但由于营业需要，落地了一个 8000 节点级此外规模，所以也一曲对爆炸半径问题连结高度，并通过一系列策略加以节制。
晚期小红书集群资本办理粗放，存正在大量营业独有资本池，导致资本池割裂、碎片化严沉。营业为保障不变性过度囤积资本，进一步加剧华侈。为此，小红书调整集群架构，建成包含 7000 至 8000 个节点的超大规模集群，成为云上单集群节点数最多的案例之一。
正在 AI 和大规模弹性场景下，单集群规模扩大会导致资本膨缩，对节制面和数据面提出更高要求。节点数增至 5000 时，节制面压力显著添加，表示为内存取 CPU 耗损成倍增加，以及 API Server 不变性问题 节制面需缓存全数数据面资本消息，导致资本占用远高于常规集群。ACK 针对节制面组件实施多项优化。
搜刮的 Merger-Searcher 架构：实现检索取排序解耦，通过异构 Pod（检索节点取排序节点）协同工做？。
起首，小红书正在内部对集群规模进行了严酷。为了防止集群规模过大带来的爆炸半径风险，每个集群设定了水位线，当规模达到上限后，将遏制衔接新营业，仅对存量营业进行扩容。
StatefulSet 做为 Kubernetes 的无形态使用编排方案，正在根本场景中能满脚多分片 / 多脚色使用的简单编排需求，但正在企业级出产中面对显著局限性，次要表现正在两个焦点场景。
大规模存储分片场景：当存储类使用（如 Kafka/MySQL 集群）数据量达到 PB 级时，动态分片扩容 和 跨分片数据平衡 成为刚需。
正在混部的环境下，起首需要确认的是资本供给体例。晚期，小红书的很多营业正在必然程度大将 Pod 和虚拟机绑定正在一路。一台机械上凡是只摆设一到两个使用，导致迁徙成本高、弹性差，而且因为负载特征类似，对资本的同质化严沉，好比流量到来后正在某个时间这些营业同时将 CPU 打高，容易呈现资本共振问题，影响系统不变性。因而，要正在统一节点上对分歧营业进行混部，并为营业供给弹性和机能缓冲的空间很是无限。
先看看 OpenKruise 。OpenKruise 是 Kubernetes 扩展套件，专注于云原生使用的从动化办理，包罗摆设、发布、和 Kubernetes 东西 StatefulSet 定位接近。
自 2022 年起，小红书便起头采用 ECS AMD 实例。近年来，出格是第八代推出后，CPU 能力方面获得了更大提拔。例如，从频提拔到 2。7GHz，最高睿频到 3。7GHz，焦点密度不竭优化，同时比拟上一代单核的二级缓存提拔一倍，IPC 提拔了 14%，使其正在不异功耗程度下算力提拔约 25%。
面临这些挑和，小红书起头反思：正在加强营业不变性、资本安排和架构优化方面，能否有更成熟的行业方案可自创？终究，云原生成长已有十年，但很多企业仍逗留正在“用容器但不做安排”的阶段，即便这种做法正在企业快速成持久间难以避免。
值得留意的是，小红书取阿里云开源社区之间采用的，是一种带有共创性质的社区协做范式，打破了保守“用户提问题云厂商做方案”的单向径。
当我们回望阿里云弹性计较 15 年手艺演进轨迹，这条径清晰勾勒出云计较取时代需求的同频共振从晚期帮力保守企业叩开互联网大门，到深度陪同互联网企业完成从营业上云到架构云原生化的，曲至今日成为 AI 时代算力的焦点根本设备。这场持续升级的底层逻辑，一直环绕 “让算力办事于营业价值” 展开：正在根本资本层建立兼具弹性扩展能力取极致机能的算力矩阵（如 ECS AMD 实例供给的高机能算力选项），正在安排办理层打制笼盖 “算力供给 - 资本安排 - 使用交付” 的全链闭环（如容器办事 ACK 实现的高效使用办理），构成支持企业数字化转型的手艺底座。
正在建立大规模计较节点时，阿里办事器 ECS AMD 实例（以下简称 ECS AMD 实例）是小红书正在大 Node 方案中的另一个主要选择。ECS AMD 实例建立正在多层手艺架构之上，最底层是 AMD CPU 芯片，并叠加阿里云自研的 CIPU 架构，其上一层为容器相关产物如容器办事 Kubernetes 版 ACK（以下简称 ACK），最上层则是用户的使用层。
值得留意的是，小红书团队对云原生演进标的目的的判断取社区趋向高度契合：简化复杂性取适配新兴场景将成为下一阶段的环节。大师都认为云原生“好”，可是想把它实的用起来却太难，所以我们需要破解云原生手艺的“复杂度悖论”。
为了冲破这些瓶颈，小红书选择基于阿里云自研的 CIPU 架构的 ECS AMD 实例，将内存带宽提拔 125%，达到 350GB。
现实上，正在应对单集群 1。5 万节点挑和过程中，ACK 的优化不只满脚了本身营业的高尺度需求，还贡献至 K8s 社区，有些优化已正在 1。30 版本中获得使用。
2023 岁首年月，团队正在多种社区开源方案中频频衡量，最终，他们选择了阿里云开源的 Koordinator。
更深条理的问题正在于，资本效能取营业不变性之间存正在天然的矛盾。正如小红书云原生平台担任人林格所说：“过去我们老是依托资本冗余来保障不变性，资本和使用架构的云原生化相对畅后。”。
小红书从力利用的是 64 核的 VM 取 192 核的零件规格办事器，此中零件规格的办事器做为大 Node 利用时，小红书可以或许间接掌控从 CPU、内存到缓存的全量硬件资本，避免跨租户资本争抢导致的机能发抖。正在推进“大 Node、小 Pod”策略时，这相当于供给了一种极限规格的大型计较节点能力。
家喻户晓，安排范畴很难做出一种完全通用的方案，特别当营业规模达到必然体量后，往往会呈现很多定制化需求。对良多雷同企业都具有主要的参考价值。并且面临中国开源生态中“好景不常”的挑和，这种以实正在场景驱动、多方持续投入的深度共建模式，大概恰是维持社区生命力的环节。
正在这个过程中，小红书手艺团队发觉 OpenKruise 的 UnitedDeployment 能够供给环节手艺支持。并按照营业场景建立同一工做负载模子，封拆到小红书云原生平台中，处理小红书内部无形态办事的编排问题。
同时，小红书还通过按期巡检和管理机制，及时发觉并修复不规范的利用体例，确保集群正在高并发、高负载场景下的不变性。
正在超大规模计较（大 Node）场景下，收集机能往往是影响全体计较效率的环节要素。PS-Worker 节点里，收集的开销凡是会正在整个机能权沉中占领很大一部门。
这是一个涉及营业和根本设备层面的全体工程，要求对换度系统、内核等多个维度进行优化，同时还要正在营业目标中引入响应时间（RT）劣化率、CPU 分层操纵率等目标，以降低低效资本比例，倒逼架构优化。
正如团队所强调的，云原生的价值正在于持续处理营业的现实问题。面临 AI 驱动的算力取夹杂架构的常态化，小红书的手艺实践或将为行业供给一条可参考的径正在效率取矫捷性之间寻找均衡，以持续演进的架构能力驱逐将来的营业挑和。
面临既要延续手艺堆集又要冲破成长瓶颈的双沉课题，小红书手艺团队选择了一条奇特的手艺径：没有陷入 “推倒沉来” 或 “简单复用” 的二元对立，正在多云的资本布局下，以阿里云容器办事 ACK + 云办事器 ECS 建立安定云基座，将小红书特有的社区电商、内容分发等复杂营业场景需求，取阿里云开源项目 OpenKruise（已捐赠给 CNCF）、Koordinator 的手艺劣势深度融合。这种 “云基座打底 - 通过开源共建满脚个性化需求” 的立异模式，既能正在保留原有手艺架构焦点价值的根本上，通过深度定制的体例满脚高效不变的营业用云需求；又能通过开源共建的体例，让小红书的手艺具备脚够的先辈性取可持续性。
但当容器化率冲破 80%、资本量冲破数百万核 CPU 时，粗放用云模式的价格起头：集群操纵率较着低于其他互联网企业，跨云的使用摆设复杂度飙升，可不雅测性和运维能力面对新挑和。同时，还要充实满脚营业快速不变迭代的，矫捷应对市场和营业变化。
OpenKruise 和 Koordinator 这两个开源项目，恰是正在如许的布景下，起头进入小红书团队的视野。
正在业内，冲破 K8s 社区的节点规模上限，一曲被视为权衡手艺能力的主要目标。跟着阿里云产物能力的不竭提拔，ACK 目前对外许诺的单集群节点上限已达到 1。5 万个节点。这意味着，从 K8s 社区保举的 5000 节点，到 ACK 支撑的 1。5 万节点，规模脚脚提拔了三倍。
二是 ECS AMD 实例处置器正在第八代升级中，将内存通道数从 8 个扩展到 12 个，并提拔了内存速度，使得数据吞吐能力显著加强。同时，这代处置器还采用了先辈工艺实现了硬件微架构上好比 CPU 内核密度、io 等多方面的提拔。除硬件外，正在指令方面，不只兼容了 AVX512 同时还支撑了 bf16，大规模计较使命下，系统可以或许连结更高的不变性和效率。
当然，面临超大规模的集群办理，分歧企业也会采用分歧的策略。有些企业选择将营业拆分到多个小集群中，而有些则倾向于将大部门营业集中正在少量的大集群中，以简化运维办理和降低发布复杂度。
正在混部架构取资本安排优化的驱动下，小红书成功将集群资本操纵率提拔至 40%，这一数字背后是内核调优、精细化安排策略及资本池优化的协同感化。
稀少模子相关的（PS-Worker）锻炼架构：跟着模子参数量和数据规模增加，此类办事需要数据分片化处置和分布式计较，这会导致使用内部 Pod 不再同质化，必需采用无形态的编排体例进行办理！
从虚拟化手艺的冲破到智能混部安排，每一次手艺逾越都是正在践行 “降低用云门槛” 的普惠。正在 AI 沉塑财产的当下，阿里云弹性计较将继续取客户并肩同业，不止是为 AI 企业供给支持大模子锻炼、智能推理的磅礴算力，更是手艺演进的同人。正在持续迭代的架构立异中为企业打开营业增加的新空间，让云计较实正成为逾越时代的手艺焦点纽带。
云办事为小红书带来了显著的便利，能正在几分钟内建立 Kubernetes（K8s）集群并交付机械。但取此同时，对于小红书团队而言，新的办理挑和也随之浮现。
一是保守的 VM 因为虚拟化开销，会丢失部门内存带宽和 Cache 资本的隔离能力。而 CIPU 架构保留了这些能力，也可以或许接入 VPC 收集、云盘及拜候大数据 EMR 系统的能力。这种特征使得办事器正在连结云计较矫捷性的同时，也能供给精细化的资本节制能力，包罗内存带宽和 L3 Cache 的调优，从而更好地适配大规模混部场景。
API Server：做为节制面焦点，其不变性至关主要。ACK 引入从动化弹性扩容和限流机制，采用 KON K 架构将 API Server Pod 摆设正在专属集群，可按照负载动态调整副本数，秒级完成弹性扩容。
手艺径并非非此即彼， 正在 ACK 等尺度化能力根本上，通过共建的体例满脚个性化需求，小红书实现了营业场景精细化资本效率办理取营业不变性的动态均衡。
跟着 K8s 原生化的成长，越来越多的营业方起头自行开辟 Operator，并通过 K8s 管控面取营业系统进行交互。对此，小红书制定了严酷的规范，营业方将 K8s 管控面做为焦点数据链，要求尽可能利用缓存，并对高频拜候进行限流，以防止管控面被打挂。
于是手艺团队冲破性提出“大 Node 小 Pod”策略：将物理节点规格做大，将使用拆小，实例增加并打散分布，既规避了虚拟化层潜正在的资本干扰，又为跨营业混部创制了矫捷的资本安排空间：正在单机毛病或呈现热点问题时，能够更快速地进行使用迁徙，从而削减停机时间和对营业的影响。
通过 issue 跟进、代码提交等体例，持续鞭策焦点功能的完美，小红书的场景需求成为了开源组件设想的原生基因，让手艺方案正在一起头就烙上了出产级场景的印记。
小红书晚期就一曲持续数月按期参取社区会议，并连系本身落地场景参取了手艺方案设想。出格是离线混部、大数据生态融合等范畴，资本画像和数据预测能力的晚期 proposal，均由小红书供给了场景和 idea，并取阿里云社区开辟者配合会商实现径。这种合做也催生了预料之外的“共识”：Koordinator 开源团队也从小红书提出的 Proxy 组件方案中发觉两边对架构设想和资本模子的理解竟高度分歧，随即焦点模块的代码共建。
多副天职片摆设场景：出产中的多分片使用（如分布式数据库、搜刮保举办事）凡是需要 每个分片摆设多副本 以营业高可用和负载平衡。而 StatefulSet 的默认设想为每个分片仅支撑单 Pod，无法间接实现分片内的程度扩展。
最后阶段，小红书次要进行手艺摸索。同业界其他 Yarn on K8s 方案分歧的是，小红书并未对 Yarn 进行侵入式，而是基于开源 Yarn 版本进行开辟。正在过去一年中，小红书的 Yarn 取 K8s 夹杂安排方案逐步成熟，规模也正在持续扩大，笼盖了数万台节点，供给了数十万核资本，结果也很较着：CPU 操纵率平均增加 8%~10%，部门达到 45% 以上。正在此根本上，团队进一步测验考试优化 Yarn on K8s 的方案。短期方针是提拔资本复用率和效能，而持久规划是自创 Koordinator 的同一安排，正在 K8s 中支撑 Spark 和 Flink 等营业的同一安排，从两套安排系统并存演进为同一安排，逐渐实现从 Yarn 向 K8s 的切换过渡。最终，Yarn 将逐渐退出汗青舞台，K8s 生态则需全面衔接大数据负载。
但正在选择无形态使用编排东西的手艺选型中，小红书团队放弃了 StatefulSet，转而选择了 OpenKruise。
2023 岁首年月，跟着资本规模扩大，对资本效能的要求提高，公司起头建立自从的混部安排能力。分歧于以往正在资本压力较小时，仅依托简单的资本腾挪、二次安排和碎片管理，此次调整是一次更深条理的架构升级。
ETCD：做为无形态组件，采用三副本架构，引入从动化垂曲弹性扩容（VPA），告急时从动扩展资本设置装备摆设；将社区版存储空间优化，默认提拔 quota，处理存储瓶颈。
以上只是处理了小红书正在开源层面的选型问题，正在混部方案启动后，若何进一步提拔收益、避免资本华侈，保障保守焦点营业的高效运转，又能从安排层面处理分歧营业间的资本供给问题，成为了下一阶段的焦点命题。
