导语

过去十几年，数据中心网络经历了一次并不喧哗、但影响深远的架构迁移：从以“三层架构”为代表的层级化设计，逐步转向以 Spine-Leaf 为核心的 CLOS 化组网。推动这次迁移的，不只是服务器数量的增长，更是流量方向的根本变化——当业务从“用户访问服务器”转向“服务器之间高频对话”，网络的设计目标也随之从“南北向通达”转向“东西向高效”。

一、三层架构：一个时代的合理答案

传统数据中心网络通常被概括为三层结构：接入层（Access）、汇聚层（Aggregation）、核心层（Core）。

它的逻辑非常清晰：

• 接入层负责连接服务器，是网络边缘；
• 汇聚层把多台接入交换机聚合起来，承担策略、网关等职能；
• 核心层负责高速转发与跨区域互联，是整张网的中枢。

在“客户端—服务器”为主的时代，这种结构是合理的。业务流量以南北向为主：外部用户请求进入数据中心，落到某台服务器，服务器处理后返回。核心层承担的是“把流量送进来、再送出去”的角色，层级清晰、边界明确，便于按层扩容和排障。

但三层架构有一个内生的结构性问题：收敛比。接入层向上连接到汇聚层、汇聚层再向上连接到核心层的链路数量，通常远少于向下连接的服务器数量。这意味着，一旦流量模式从“上下”变成“横向”，带宽就会在汇聚层和核心层形成瓶颈。

二、东西向流量：压垮传统架构的那根稻草

真正改变游戏规则的，是东西向流量的崛起。

分布式系统、虚拟化、微服务、大数据计算，这些技术有一个共同特征：一次业务请求，往往需要几十甚至上百台服务器协同完成。数据库要复制，缓存要同步，计算节点要交换中间结果，存储节点要响应读写。流量不再主要发生在“用户与服务器”之间，而是发生在“服务器与服务器”之间。

这对网络提出了几个新要求：

1. 高带宽：节点之间需要大量并行通信；
2. 低延迟：分布式协调、一致性协议对时延敏感；
3. 可预测的路径：多跳层级转发容易带来时延抖动；
4. 易扩展：扩容时不应牵一发动全身。

三层架构在这些要求面前显得吃力。层级越多，跳数越多；收敛比越高，横向带宽越紧张；而扩容往往意味着要动汇聚层甚至核心层，工程复杂度和风险都不低。

三、Spine-Leaf 与 CLOS：把“层级”换成“平面”

Spine-Leaf 架构的流行，本质上是用 CLOS 网络的思想重构数据中心内部组网。

它的结构可以简单理解为：

• Leaf 交换机：直接连接服务器，是服务器的“第一跳”；
• Spine 交换机：只与 Leaf 相连，不与服务器直连；
• 每一个 Leaf 都连接到每一个 Spine，形成全互联的二分图结构。

这种设计带来几个关键特性：

第一，路径长度固定。 任意两台服务器之间，通常是“Leaf—Spine—Leaf”三跳（同 Leaf 下则为两跳）。跳数稳定，时延更可预测。

第二，带宽更均衡。 通过等价多路径（ECMP）等机制，流量可以在多条 Spine 链路上分摊，缓解单点拥塞。

第三，扩展方式更“横向”。 需要更多服务器端口时，加 Leaf；需要更多互联带宽时，加 Spine。扩容的颗粒度更清晰，对既有业务影响更小。

第四，更适合东西向。 由于任意 Leaf 之间都只隔一个 Spine，服务器之间的通信不再需要穿越多层核心，横向流量的效率显著提升。

可以说，Spine-Leaf 并不是简单地“把三层压成两层”，而是把网络的关注点从“层级归属”转向了“任意两点之间的等价可达”。

四、AI 集群：把网络推到新的极限

如果说微服务和分布式计算让 Spine-Leaf 成为主流，那么 AI 集群则把网络架构推向了更极端的场景。

AI 训练，尤其是大模型训练，具有几个鲜明的网络特征：

• 大规模并行：成百上千张加速卡需要协同；
• 高频集合通信：梯度同步、参数广播等操作会周期性产生大量通信；
• 对带宽和时延极度敏感：网络一旦成为瓶颈，加速卡就会“等数据”，算力利用率下降；
• 流量模式集中且突发：某些阶段通信量会瞬间抬升。

这带来几个架构层面的新课题：

一是组网规模。 当集群规模扩大，Spine-Leaf 的层级可能需要进一步扩展，出现多层 CLOS 或更复杂的拓扑设计。依据现有素材判断，具体层数和规模需结合集群大小与厂商方案确定，本文不给出具体数字。

二是拥塞控制与负载均衡。 传统 ECMP 基于流哈希，容易在“大流”场景下出现链路负载不均。AI 场景对更细粒度的负载均衡和拥塞控制机制提出了需求，这也是近年来网络技术讨论的热点方向之一。

三是网络与计算的协同。 在 AI 集群中，网络不再是“配套”，而是决定整体效率的关键一环。拓扑设计、通信库、调度策略需要协同考虑。

四是运维复杂度上升。 规模越大、链路越多、协议越复杂，配置一致性、故障定位、变更管理的难度都会显著增加。

五、架构选择：没有银弹，只有权衡

从三层到 Spine-Leaf，并不是“新架构一定优于旧架构”的简单结论。实际选择需要结合业务形态和运维能力。

三层架构仍然适用的场景：

• 业务以南北向流量为主；
• 规模相对有限，层级扩展压力不大；
• 运维团队对传统架构更熟悉，变更风险可控。

Spine-Leaf 更适合的场景：

• 东西向流量占比高；
• 需要横向扩展、按需增加端口和带宽；
• 对时延稳定性和路径可预测性有要求；
• 有相应的自动化运维能力支撑。

需要正视的代价：

• 全互联结构意味着链路数量增加，布线和管理更复杂；
• 对自动化配置、监控和故障定位能力要求更高；
• 架构设计不当（如 Spine 数量、收敛比规划不合理）同样会形成瓶颈。

换句话说，Spine-Leaf 解决的是“横向扩展与东西向效率”的问题，但它并没有消除网络设计的复杂性，只是把复杂性从“层级规划”转移到了“拓扑规划与自动化运维”。

六、趋势判断

基于上述架构演进逻辑，可以做出几点偏保守的趋势判断：

1. CLOS 化仍将是数据中心组网的主流思路。 其核心价值——等价多路径、可预测跳数、横向扩展——与分布式业务的长期方向一致。

2. 网络与业务的耦合会更深。 尤其在 AI 场景下，网络设计越来越难脱离计算任务单独讨论。

3. 运维自动化从“加分项”变成“必选项”。 架构越扁平、链路越多，越依赖自动化来保证一致性和可观测性。

4. 架构选择将更强调场景匹配。 不会出现“所有数据中心都长一样”的局面，南北向与东西向、通用计算与 AI 计算，可能会采用不同的组网策略。

结语

从三层到 Spine-Leaf，表面上是拓扑图的变化，实质上是数据中心网络设计目标的迁移：从“把流量送进来”，到“让服务器高效对话”。AI 集群的出现，进一步放大了这一迁移的紧迫性。

对技术团队而言，重要的不是追逐某个架构名词，而是理解自身业务的流量特征、扩展节奏和运维能力，再据此做出取舍。网络架构没有绝对的最优解，只有与业务阶段相匹配的合理选择。

生成标记：本文由 ITPUB 文章生成平台基于已选素材整理生成。