再见，叶脊网络？

# 再见，叶脊网络？« ipSpace.net 博客 来源：https://blog.ipspace.net/2026/06/goodbye-leaf-spine-networks/ 一位朋友给我发了链接，一篇是 AWS 工程师发表的**新论文** (https://arxiv.org/abs/2604.15261)，另一篇是相关的**LinkedIn 帖子** (https://www.linkedin.com/feed/update/urn:li:activity:7465785618414051328/)，其中声称： > 我们打造了精简、弹性、大规模聚合的架构，吞吐量提升 33%，路由器减少 69%，成本节省 27%，功耗降低 40%，二氧化碳排放减少 45%。 读完那篇夸张的 **Radical Network Redesign** (https://www.aboutamazon.com/stories/aws-random-graph-theory-data-center-network-design) 博文后，一个显而易见的问题就是：这是否意味着叶脊网络的终结？当然不是。让我们深入细节。 **他们究竟做了什么？** 他们重新发现了 **Plexxi 构建数据中心架构** (https://blog.ipspace.net/2013/09/the-plexxi-challenge-or-dont-blame-tools/) 的方法。Plexxi 不是使用脊交换机，而是尝试直接互连叶交换机，最初使用 CWDM（他们梦想着动态叶到叶带宽），后来改用预布线的中间盒（AWS 工程师称之为 ShuffleBox）。 显然，这样会浪费大量带宽，因为总有一些叶交换机即使有直接链路也不交换流量。Plexxi 通过不等价多路径解决了这个问题（流量也会使用更长的路径，而不仅仅是直接链路）；AWS 博文称之为“随机路由”。 任何试图理解 **LFA** (https://blog.ipspace.net/2012/01/loop-free-alternate-ospf-meets-eigrp/) 的人都知道，**不等价多路径** (https://blog.ipspace.net/2021/03/ucmp-link-state-protocols/) 的能力是有限的。如果你想进一步提高链路利用率，就需要“适当的”流量工程，这需要虚电路（以及额外的封装层）。至于这额外一层是使用 MAC 帧¹ (https://blog.ipspace.net/2026/06/goodbye-leaf-spine-networks/#fn:1)、MPLS、SRv6 还是鸽子，都无关紧要。 **预布线的 ShuffleBox 怎么会是随机的？** 嗯，这是我吐槽的第一大触发点。起初，我以为他们使用了光交换机（由于产量较低，它可能和传统脊交换机一样昂贵），但读了文章后，我得到的印象是，他们将交换机上行链路拆分为独立的通道（例如，400GE 上行端口中有四个 100GE 通道），并在 ShuffleBox 中预布线了通道到通道的矩阵，这使得它和 **XKCD 随机数生成器** (https://xkcd.com/221/) 一样随机。值得注意的是，**Plexxi 也做了完全相同的事** (https://blog.ipspace.net/2013/09/plexxi-psi-mau-at-gigabit-speed/) 来消除 CWDM 成本，而通道拆分是一种古老的方法，我们在十多年前就用它来“折磨自己”，以构建更大的叶脊架构（一些细节 (https://blog.ipspace.net/2023/03/leaf-spine-theory-reality/)）。 他们声称使用了优化方法来寻找具有 D 个上行链路的 N 个交换机之间的最佳部分网状连接。结果可能在某种约束下是最优的，并且对普通观察者来说可能看起来是随机的，但其中并没有什么随机性。arXiv 论文正确地将其称为准随机图；这种细微差别由于显而易见的原因² (https://blog.ipspace.net/2026/06/goodbye-leaf-spine-networks/#fn:2) 在博文和类似的宣传材料中丢失了。 **他们的吞吐量能超过叶脊架构吗？** 在同类比较中，当然不能。我**很久以前就解释过** (https://blog.ipspace.net/2012/04/full-mesh-is-worst-possible-fabric/)，但当然没人会读旧文章，所以让我们再做一次简单的思想实验： * 你构建了一个叶脊架构，在叶交换机上采用 N:1 的超分——边缘端口的总带宽是上行链路总带宽的 N 倍。N 通常设为三。 * 你的架构中的脊（或超级脊架构）没有超分。唯一的拥塞资源是叶交换机的上行链路。 * 因此，在叶脊架构中，从任意端点到任意其他端点的流量必须恰好经过两个叶交换机上行链路和一个非超分架构。 * 在 Plexxi 或 AWS 的解决方案中，流量可能需要经过两个以上的叶交换机上行链路（当它们使用其他叶交换机作为中继节点时）。 在一个有很多小流量的环境中（为了让负载均衡工作良好），因此，在部分网状结构中，**不可能**获得比没有核心超分的叶脊架构更好的总吞吐量，而且只要叶交换机上行链路是拥塞点，**流量模式是什么根本不重要**。细节留给好奇的读者作为练习。 **但他们声称在 arXiv 论文中获得了更好的吞吐量！** 是的，我试图弄清楚，但论文在细节上有点含糊。看起来他们是用仿真生成了吞吐量图，但源代码没有提供，所以我们无法确切知道他们做了什么³ (https://blog.ipspace.net/2026/06/goodbye-leaf-spine-networks/#fn:3)。此外，他们将他们的解决方案与 **fat tree** 进行了比较，但没有定义所使用的 fat tree 的参数。 我可以想到几个相对简单的解释来解释他们的结果： * 他们架构中的脊层（或核心架构）是超分⁴ (https://blog.ipspace.net/2026/06/goodbye-leaf-spine-networks/#fn:4) 的。 * 他们叶脊架构中的负载均衡是次优的（某些上行链路拥塞而其他空闲）。在转向包喷洒之前有多种方法可以解决这个挑战；Cisco ACI 据称使用了其中一种，如果你对细节感兴趣，我写过几篇关于这个主题的博文。 * 他们在解决方案中使用了**跨虚拟路径**的负载均衡，这导致了更多数量的备用路径，从而获得了更好的负载均衡性能。 * 他们使用了考虑链路负载的路由算法，导致链路拥塞更加均衡。 * 他们在解决方案中使用了包喷洒（将同一会话的包发送到多条路径），但在基线叶脊架构中没有使用。 我很愿意相信存在某种比最优实现的叶脊架构效果更好的神奇解决方案，但我认为物理定律并不认同这种观点。然而，根据**克拉克第一定律** (https://en.wikipedia.org/wiki/Clarke%27s_three_laws)，我也可能遗漏了一些显而易见的东西；如果是这样，请留下评论。 **这重要吗？** 这是一个有趣的方法，对于大多数用例来说很可能已经足够好了。毕竟，我一直告诉人们将四台叶交换机连接成全网状，而不是在脊层上浪费时间。我不相信它能给你带来更高的吞吐量，但我完全同意它使用更少的电力（ShuffleBox 很可能是无源元件）。 我们是否应该预期在企业级数据中心中出现类似的解决方案？可能不会。Plexxi 未能取得进展可能是有原因⁵ (https://blog.ipspace.net/2026/06/goodbye-leaf-spine-networks/#fn:5) 的。此外，只要财富 50 强公司需要**不到十几台交换机来构建两个数据中心** (https://blog.ipspace.net/2021/09/4-switch-fabric/)（基于真实故事），那么在优化架构设计上投入时间可能不是对每个人最好的投资。 另一方面，如果你要构建拥有数万台交换机的架构，你绝对应该仔细看看。如果你这样做了，我很乐意听到你的评论。