Spine-Leaf 架构

枫桥2026/6/30大约 7 分钟

Spine-Leaf 架构

一个数据中心为什么扩容到一半推倒重来

2015 年某互联网公司新建数据中心，按经典三层架构（核心 → 汇聚 → 接入）设计，机柜到位 5000 个。结果上线半年发现：

东西向流量（服务器之间互访）占 75%，南北向（服务器到外网）只占 25%
三层架构为南北向优化，东西向流量要绕到核心交换机再返回
一台服务器到同机房另一台服务器，延迟 0.5ms（其中 0.3ms 浪费在不必要的核心跳转）
带宽利用率不均，核心交换机 80% 端口满，汇聚层 30% 闲置

最后推倒重来，改成 Spine-Leaf 架构——任何两台服务器之间最多 2 跳（Leaf → Spine → Leaf），东西向延迟砍一半。

这一章讲数据中心网络架构的演化：传统三层的问题、Spine-Leaf 的设计、ECMP 怎么工作、真实部署的坑。

问题一：传统三层架构为什么不够

经典三层架构（Tier 1/2/3）：

                    [核心层 Core]
                   ↙          ↘
            [汇聚层]            [汇聚层]
           ↙ ↓ ↘  ↘           ↙ ↘ ↙
       [接入][接入][接入]   [接入][接入][接入]
        服务器 服务器       服务器 服务器

核心层：高速骨干，连接外部网络和汇聚层。
汇聚层：策略控制（ACL、QoS）、路由聚合、网关。
接入层：直接连服务器，1G/10G 下行。

优势：层次清晰，南北向（服务器到外网）路径短。

致命问题：东西向流量（服务器之间）要绕：

服务器 A → 接入层 → 汇聚层 → 核心层 → 汇聚层 → 接入层 → 服务器 B
         ↑————————————————4 跳————————————————↑

机柜内部服务器互访 75% 是这种模式。三层架构下，核心层成为瓶颈——所有东西向流量都要经过核心交换机。1000 台服务器每台 10G 互联，核心交换机要提供 10000G 带宽。商用核心交换机最大 8T，再多就堆叠。堆叠后还是单点故障。

另一个问题：带宽不均。核心到汇聚是 40G，汇聚到接入是 10G，服务器到接入是 1G。带宽像漏斗，越上层越窄。下层 24 个 1G 端口打满上行的 10G 端口，立刻拥塞。

问题二：Spine-Leaf 怎么"压平"网络

Spine-Leaf（也叫 Fat-Tree 胖树）只有两层：

          Spine 1  Spine 2  Spine 3  Spine 4
          ↗  |  ↖  ↗  |  ↖  ↗  |  ↖  ↗  |  ↖
        Leaf 1  Leaf 2  Leaf 3  Leaf 4  Leaf 5
         |      |      |      |      |
       服务器 服务器 服务器 服务器 服务器

Spine 层：骨干交换机。所有 Spine 交换机角色相同，互相不连。
Leaf 层：接入交换机。每个 Leaf 交换机连接所有 Spine 交换机。

关键特性：

任意两台服务器最多 2 跳：服务器 A 在 Leaf 1，服务器 B 在 Leaf 3。流量路径：Leaf 1 → 任一 Spine → Leaf 3。固定 2 跳（不计接入层）。
带宽比 1:1：传统三层接入 1G、汇聚 10G、核心 40G，带宽逐层收敛。Spine-Leaf 接入 10G，每个 Leaf 到 Spine 都是 10G，全网带宽 1:1——任意 2 个 Leaf 之间的可用带宽都是 10G × Spine 数量。
水平扩展容易：加服务器就加 Leaf，Leaf 加到上限就加 Spine，两者正交扩展。不需要重新设计拓扑。

规模计算：

如果 Leaf 用 48 端口交换机（48 个 10G 下行给服务器 + 4 个 40G 上行给 Spine），Spine 用 32 端口 40G 交换机：

单 Pod 容量 = 48 服务器 × 4 Leaf = 192 服务器
Spine 数量 ≥ Leaf 上行端口数 = 4（每个 Leaf 4 个 40G 上行，所以至少 4 个 Spine 才有意义）
支持 192 台服务器

要扩到 1000+ 服务器？升级到 64 端口 Leaf，加 Spine 数量。

问题三：ECMP 怎么"随机选路"

Spine-Leaf 网络里，Leaf 1 到 Leaf 3 有 4 条等价路径（每个 Spine 是一条）。流量怎么分配？

答案：ECMP（Equal-Cost Multi-Path，等价多路径）。

ECMP 是路由协议的功能。路由器看到目的地址有多个下一跳，开销相同，就在多个路径上哈希分摊流量。

哈希的输入通常是"五元组"：源 IP、目的 IP、源端口、目的端口、协议。同一个 TCP 连接的所有包哈希结果相同，保证包不乱序。

Leaf 1 → Leaf 3 的 4 条路径：
  Leaf 1 → Spine 1 → Leaf 3
  Leaf 1 → Spine 2 → Leaf 3
  Leaf 1 → Spine 3 → Leaf 3
  Leaf 1 → Spine 4 → Leaf 3

哈希结果：TCP 连接 (1.1.1.1:1234 → 2.2.2.2:80) hash 到 Spine 2
另一连接 (1.1.1.1:5678 → 2.2.2.2:80) hash 到 Spine 4

ECMP 的局限：

哈希分布不均：几千个连接哈希到 4 条路径，统计上可能某条路径多 30%。这叫哈希极化。
大象流问题：少数大流量（备份、视频）可能哈希到同一条路径，该路径拥塞，其他路径空闲。传统 ECMP 不知道流量大小。
解决方案：更新的技术用 DLB（Dynamic Load Balancing） 或 INT（In-band Network Telemetry） 检测实时负载，动态调度。

问题四：Spine-Leaf 部署的真实案例

Facebook（Meta）数据中心架构演进：

2014 年公开的 "Facebook's Data Center Network Architecture" 论文揭示他们用了 4 层 Clos 变体：

服务器 1G → ToR（Leaf 1）→ 中间层（Spine）→ Spine → 接入层（Leaf 2）→ 核心

Google Jupiter Network：

2015 年 Jupiter 论文（SIGCOMM）展示 Google 自研的 Spine-Leaf 架构，单集群支持 100000+ 服务器。关键技术：

自制交换机：ASIC 芯片定制，端口 16×40G 或 32×100G
SDN 控制：用集中控制器计算路径，避免 ECMP 哈希极化
多平面设计：多个独立 Spine-Leaf 集群通过核心互联

Microsoft Azure：

2018 年公开的 Azure 网络架构，Spine-Leaf 用了 6 个 Spine 平面，每个 Leaf 到每个 Spine 是 100G。单 Leaf 带宽 6×100G = 600G 出口。

问题五：Spine-Leaf 的边界

Spine-Leaf 不是银弹，它有自己的限制。

限制 1：Spine 数量受限于 Leaf 上行端口数。

如果 Leaf 交换机只有 4 个 100G 上行，整个 Pod 最多 4 个 Spine。再多也接不上。

限制 2：VLAN 数量限制。

传统 VLAN 只有 4094 个 ID（12 位）。现代数据中心动辄万级租户、千级 VPC，VLAN 不够用。要用 VXLAN（RFC 7348）扩展到 1600 万个虚拟网络。

VXLAN 在原始以太网帧外面再包一层 UDP（端口 4789），里面带 24 位 VNI（VXLAN Network Identifier）。这样可以跨三层网络扩展二层域——不同机柜的服务器在同一个 VXLAN 网络里。

[VM 1 内层以太网帧] → [VXLAN 头 + UDP] → [外层 IP 路由] → [对端 Leaf] → 解 VXLAN → [VM 2]

限制 3：东西向流量仍然可能成为瓶颈。

Spine-Leaf 解决了"层数多"问题，但 Spine 交换机仍然可能拥塞——1000 台服务器每台 10G 出口都流向同一个 Spine，那条 Spine 就是瓶颈。

真实设计原则：

服务器到服务器流量尽量本地消化（用 Leaf 内通信避免跨 Leaf）
大数据流（MapReduce、备份）走专用网络，不走业务 Spine-Leaf
跨 Pod 流量走独立的核心 Spine-Leaf 平面

思考题

Spine-Leaf 架构里每个 Leaf 上行 4 个 40G 端口，Spine 用 32 端口 40G 交换机。这个 Pod 最大能支持多少台 10G 服务器？如果要扩到 5000 台服务器，Leaf 和 Spine 怎么升级？
ECMP 用五元组哈希保证同连接不乱序。但 UDP 流没有"连接"概念（IP + 端口可能不变），ECMP 怎么处理 UDP 流？视频流（UDP）会有什么问题？
VXLAN 用 UDP 4789 端口封装，每包增加 50 字节开销。对 MTU 1500 的网络，最大有效载荷变成 1450。设计 Spine-Leaf 时要怎么考虑这个开销？MTU 黑洞（两端 MTU 不一致）怎么排查？
假设一个 Spine-Leaf 数据中心有 10000 台服务器，1% 突发流量达到 1Gbps（10 台同时打满 1G）。传统 ECMP 怎么分配？会出什么问题？怎么用 DLB 或 SDN 控制器解决？
数据中心内部服务器之间的延迟要求 <100 微秒（高频交易、分布式存储）。Spine-Leaf 一跳 Leaf 1G 交换 1 微秒，但跨 Leaf 流量要 2-3 微秒。这种超低延迟场景下 Spine-Leaf 够用吗？需要什么补充技术？