Spine+Leaf 网络架构起源：CLOS 模型解析

2026年8月25日 LOG admin

几乎每一篇数据中心网络设计文章都会提到Spine+Leaf，但很少有人讲清楚它从哪来、为什么长这样。这篇文章源自华为数据中心网络设计指南，从贝尔实验室工程师Charles Clos在1952年提出的CLOS模型讲起：为什么需要无阻塞交换架构、三层CLOS结构（Ingress/Middle/Egress）如何工作，以及把这个结构"对折"之后如何演化出现代Spine+Leaf架构——包括全交叉连接带来的高可靠性，以及通过增加Spine和Leaf间链路带宽来降低收敛比的设计逻辑，帮你从原理层面真正理解数据中心Fabric。

从传统三层架构的痛点说起

在很长一段时间里，数据中心网络沿用了园区网的经典三层结构：接入层（Access）负责终端接入，汇聚层（Aggregation）负责策略与网关，核心层（Core）负责高速转发。这个金字塔式的层次在南北向流量为主、终端规模有限的年代运转良好——上层设备端口少而贵，下层设备端口多而便宜，带宽自下而上逐级收敛，成本结构非常合理。

但云计算的普及把流量模型彻底改变了：数据中心内部服务器之间的东西向流量迅速占据主导，在很多业务中已超过 70% 甚至 90%。三层架构的先天缺陷随之暴露：

纵向收敛瓶颈：接入层上行带宽远小于下行，汇聚层和核心层成为天然的拥塞点，扩容只能靠不断升级更高端的核心设备。
冗余带宽被 STP 冻结：为了防环，生成树协议必须阻塞多余链路，结果是花两倍的钱只用到一半带宽。
横向扩展能力差：从千兆到万兆、从万兆到十万兆，每一次换代都意味着核心设备被整体替换，成本和风险都很高。
收敛速度慢：STP 的收敛时间以秒计，对时延敏感的业务影响明显。

业界因此开始寻找一种"可横向扩展、全链路负载分担、无阻塞"的架构。令人意外的是，这个问题的答案早在半个多世纪前就已经写好了。

CLOS 网络模型起源

Spine+Leaf两层扁平化网络架构来源于CLOS网络，以贝尔实验室研究人员Charles Clos命名，他在1952年提出这一模型，用于克服电话网络中机电交换机的性能和成本挑战。Clos用数学理论证明：如果交换机按层次结构组织，在交换阵列（Fabric）中实现非阻塞性能是可行的。在此之前，要实现无阻塞架构只能采用N×N的Cross-bar方式，规模和成本都受限。

要理解这个结论的分量，先要理解 Cross-bar 的困境。一个纯粹的交叉开关要达到 N 路入、N 路出且完全无阻塞，就需要 N×N 个交叉点：当 N 增长到几百、几千时，交叉点的数量以平方级膨胀，接线、功耗与硬件成本都不可承受。Clos 的洞见在于：与其把一个大交换矩阵做得越来越复杂，不如把它拆成若干层小规模的交换单元，再用级间连线把它们"重组"起来——只要层数和小交换单元的规模选得合适，就能在理论上保证整体依然是无阻塞的。

三层 CLOS 结构（Ingress、Middle & Egress）

Charles Clos的设计是一个三层网络架构的CLOS模型：由Ingress节点（入口）、Middle节点（中间）和Egress节点（出口）组成。通过合理组织这三个层级，可以用大量小规模交换机组成非常大规模的无阻塞网络，本质上追求的是无阻塞转发能力。

它的巧妙之处在于：任何一条从入口到出口的路径，都要经过"入口 → 中间 → 出口"三段跳线，而中间层的小交换单元并不绑定某对固定的入出口。当入出口之间的连接需求变化时，只要中间层的转发能力足够，就可以通过调度把流量安排到没有冲突的中间单元上，从而让整体呈现出无阻塞特性。这意味着规模可以靠"堆数量"而不是"堆单机能力"来扩展——这正是后来数据中心 Fabric 能够用商用芯片横向扩容的思想源头。

沉寂半个世纪：Clos 如何在数据中心复兴

CLOS 模型提出后，长期只在电话交换领域使用，在数据网络里几乎被遗忘。真正的复兴发生在 2000 年代末到 2010 年代初：一方面，服务器网卡速率从千兆迈向万兆，单台交换机的端口密度和带宽开始跟不上；另一方面，商用交换芯片（merchant silicon）成熟起来，让"用小盒子拼大网络"在经济上第一次成立。学术界很快给出了可工程化的方案：加州大学圣地亚哥分校在 2008 年前后提出的 Fat-Tree 结构，用同样的分层交叉思路，把数据中心的组网规模推进到数万台服务器，并给出了路由与寻址的具体做法。

真正让这一架构成为工业标准的是超大规模数据中心的自研实践。Google 在其数据中心网络演进中逐步放弃了传统三层结构，转向了基于 Clos 的可扩展 Fabric：早期用 1G 链路的试验网验证了"分层交叉 + 集中式控制"的可行性，随后在 2010 年代中期上线的 Jupiter 网络中，把这一思路放大到十万级服务器规模，用商用芯片搭建出聚合带宽达到 Pb/s 量级的数据中心网络。Jupiter 的公开论文系统总结了这一代 Fabric 的设计取舍——用统一的 Clos 拓扑取代核心/汇聚/接入的层级，用大量等价路径取代被 STP 阻塞的冗余链路，用集中的控制平面取代逐台设备的分布式协议。这次实践之后，"叶脊"从学术结构变成了数据中心的标准答案。

对折三层 CLOS 得到 Spine+Leaf

将三层CLOS网络架构"对折"，把入口和出口统一放在一边，就得到了与Spine+Leaf完全相同的网络架构。接入连接的数量仍然等于折叠后Spine与Leaf之间的连接数。流量可以分布在所有可用链路上，不用担心过载问题。随着更多连接接入Leaf交换机，链路带宽收敛比会增加；可以通过增加Spine和Leaf设备间的链路带宽来降低收敛比——这就是数据中心设计中"收敛比"概念的来源。

换句话说，今天机房里"一排 Spine、一排 Leaf、全交叉互联"的布线，本质上就是把 1952 年那个三层交换阵列对折后的结果：Ingress 与 Egress 合并成 Leaf（既接入服务器又承担出口），Middle 层单独留作 Spine（只负责转发）。三层的数学性质被完整地保留了下来，物理上却少了一层设备，布线和管理都更简单。

全交叉连接的高可靠性

除了支持Overlay层面技术（如VXLAN、BGP EVPN）之外，Spine+Leaf架构的另一个核心好处是组网可靠性：Spine层与Leaf层全交叉连接，任一层中的单台交换机故障都不会影响整个网络结构，任何一台设备失效都不会使整体架构瘫痪。这种结构天然消除了单点故障，是数据中心Fabric选择它的根本原因之一。

由于每一台 Leaf 都与所有 Spine 相连，任意一台 Spine 宕机只损失 1/N 的跨叶带宽，路径自动切换到其余 Spine；任意一台 Leaf 宕机也只影响挂在其下的服务器，不会波及整个 Fabric。相比传统三层架构中"核心设备一挂全楼瘫痪"的风险，这种扁平化的全交叉拓扑把故障域压缩到了最小。

收敛比与超订：设计必须回答的问题

Spine+Leaf 并不是"无限带宽"的魔法，它只是把矛盾转移到了一个可以量化的设计参数上：收敛比（oversubscription）。收敛比描述的是下层接入带宽之和与上层上行带宽之和的比值。例如一台 Leaf 提供 48 个 10G 下行端口、配 4 条 40G 上联时，下行总量 480G、上行总量 160G，收敛比就是 3:1。

收敛比越小，意味着上行越充裕、突发流量越不容易丢包，但需要的 Spine 和链路也越多、成本越高；收敛比越大，成本越省，却要求业务能够容忍一定程度的拥塞。实际设计中没有统一答案：计算密集型的分布式训练集群往往追求接近 1:1 的无收敛，而普通业务的接入区采用 3:1 或 4:1 也很常见。关键在于明确业务模型，再据此选择 Spine 数量与单条链路速率，而不是照搬某个"标准值"。

从 1G 到 400G：Fabric 的持续演进

从 1952 年的电话交换阵列到今天的数据中心 Fabric，这套架构经历了一轮完整的轮回：最初的 Clos 是为了用便宜的小交换机搭出大容量电话网，如今它又在数据中心里承担同样的使命——用商用交换芯片搭出可横向扩展的大规模网络。几十年间变化的是速率（1G、10G、25G、100G、400G）和芯片密度，不变的是那条核心思路：分层 + 全交叉 + 等价多路径。

也正因为这条思路足够稳固，"叶脊"在每一代硬件上都只需要做参数调整：链路更快了，就把 Spine 做得更胖（更少台数、更多端口）；接入密度更高了，就增加 Leaf 数量。架构本身不需要推倒重来，这正是它能够持续二十年仍作为数据中心默认拓扑的原因，也是理解现代数据中心网络的起点。