Jupiter Rising — Google 数据中心网络十年怎么做到带宽涨百倍

是什么

Jupiter Rising 是 Google 第一次把自己十年自建数据中心网络的故事公开讲完。论文盘了 5 代设计（2004 到 2012），讲清楚一件事：单集群对分带宽从第一代的 十几 Tbps 量级，最后涨到 1.3 Pbps——按论文原话是 比 Firehose 1.0 多 100 倍以上。

日常类比：原来你家小区只有一条主干道，再修也是越修越宽。Google 说不行，我们直接把”一条粗路”换成”几百条小路 + 每个路口都有红绿灯”，靠数量堆带宽。

这个”数量堆出来”的拓扑叫 Clos 网络——名字是 1953 年贝尔实验室的 Charles Clos 设计电话交换机时留下的。Google 把 60 年前的电话网络数学，搬到了 21 世纪的数据中心。

为什么重要

不读这篇论文，下面几件事都说不通：

为什么 2010 年后 Google / Facebook / Microsoft 都不再买思科/Juniper 的大机框，转而自己拼网络
为什么”软件定义网络”（SDN）这个词突然在 2012 年前后火起来——Google 的 B4 和 Jupiter 是最大推手
为什么现在一个数据中心动辄几十万台服务器还能”任意两台之间高速互通”
为什么 AI 训练（万卡集群）能跑起来——底层就是 Jupiter 这种 Clos + SDN 思路

核心要点

论文把十年成功总结成 5 条原则：

Clos 拓扑 — 不用一台超大交换机，用很多小交换机堆成多级网络。任何两台服务器之间都有多条等价路径。
通用商用芯片（merchant silicon） — 当时大公司都用思科/Juniper 的”大机框”（chassis switch），一台几十万美金还锁死功能。Google 直接买 Broadcom 的标准芯片，自己拼板子。
中心化控制 — 传统网络靠 BGP/OSPF 分布式协议自己收敛，慢且难调。Google 改用 SDN 风格的中心控制器，一处统一下发路由。
边缘聚合路由 — 把”知道全网拓扑”这件事只放在网络边缘，核心层只做无脑转发。类比：只有快递员需要知道收件人地址，公路本身不用知道。
模块化部署 — 一个集群按 pod（基本单元）增量扩，不用一次性买齐。

实践案例

案例 1：五代演进的速度阶梯

代号	年份	接入带宽	单集群对分带宽
Firehose 1.0	2004	10 Gbps/机	设计了没全上
Firehose 1.1	2005	10 Gbps/机	真上生产
Watchtower	2008	10 Gbps/机	87 Tbps
Saturn	2009	10 Gbps/机	207 Tbps
Jupiter	2012+	40 Gbps/机	1.3 Pbps

从 Firehose 1.0 到 Jupiter，百倍量级（论文里说 “over 100x”）。每一代都不是从零设计，是在上一代的基础上换芯片、加层数、改控制平面。

每一代的”瓶颈搬家”也很有意思：

Firehose 时代瓶颈在芯片端口数——商用芯片当时只有 8 口
Watchtower 时代瓶颈在光纤密度——一个机架几百根光纤怎么布
Jupiter 时代瓶颈在控制平面——每秒上千次链路抖动，分布式协议根本跟不上

读论文的乐趣就在这里：每一代的”主要矛盾”都不一样。

案例 2：为什么 Clos 比”传统大机框”省钱

传统做法：买一台 N 端口超大交换机，里面也是多级互联，但所有钱都给一家厂商。 Clos 做法：买 3 * k 台小交换机，每台只有 m 个端口，按 Clos 数学拼起来，等效一个 N 端口的”无阻塞”大交换机。

数字感受：2012 年一台 64 口商用 10 GbE 芯片成本几千美金，一台思科/Juniper 旗舰大机框要几十万。Google 的算法是：用一千台几千美金的小盒子，等效一台几亿美金的不存在的超级机框。

案例 3：中心化控制怎么救命

传统 BGP 收敛：一台设备挂了，邻居发现，再传给邻居的邻居…几十秒到几分钟才稳定。 Jupiter 中心化：控制器知道全网状态，秒级算出新路由，统一推下去。

副作用：控制器自己挂了怎么办？Google 的答案是两套机制并存——中心控制器是主路径，每台交换机本地仍保留简化版协议作为兜底。论文专门讲了这个 fallback 设计。

案例 4：商用芯片的钱账

2012 年 Google Jupiter 用的是 Broadcom Trident 系列芯片，单芯片 64 口 10 GbE，成本约几千美金。

同期思科旗舰 Nexus 7000 大机框：起步价几十万美金，单端口成本是商用芯片的 5 到 10 倍，且功能锁死。

Google 算过一笔账：自己拼的 Clos 网络，每 Gbps 成本只有买大机框的 1/4 到 1/10。规模到一定程度（几十万台服务器），自研团队的工资远低于这个差价。

踩过的坑

第一代 Firehose 1.0 没上线 — 2004 年商用芯片功能太弱，光纤接口数不够，论文坦白这一代基本没上生产环境。教训：硬件能力跟不上设计，再漂亮也跑不起来。
多路径会乱序 — Clos 拓扑下两台机器之间有几十条等价路径，TCP 包走不同路径会乱序，触发重传降速。Google 的解法：靠 ECMP 哈希让同一条流走同一路径，但仍要小心大象流（elephant flow）打爆某条路径。
控制器和数据平面要解耦 — 早期版本控制器一卡，整个集群路由不更新。后来强制要求数据平面在控制器失联时也能继续转发现有路由。
物理布线是工程难点 — 一个 Jupiter pod 有几千根光纤，布错一根全集群报警。Google 内部专门做了布线机器人 + 自动校验——论文没细讲，但暗示了规模化布线本身就是研发课题。

适用 vs 不适用场景

适用：

单数据中心内部，百万级流量、低延迟、高对分带宽的场景
需要”任意两台机器之间都接近线速通信”——典型如 AI 训练、MapReduce、分布式存储
自己有能力做软件控制器和运维平台

不适用：

跨数据中心广域网——那是 Google B4 / Microsoft SWAN 那篇论文的领域，目标不同
中小公司 — Clos 至少需要数百台交换机和大量光纤，规模太小不划算
不愿意自研控制平面 — 直接买思科/Juniper 整套方案省心
强多租户隔离场景 — Jupiter 设计是单租户（Google 自己用），云厂商如 AWS 的 VPC 隔离另有方案

历史小故事（可跳过）

1953 年：贝尔实验室 Charles Clos 为电话交换机设计了一种”多级无阻塞”网络，论文发表后 50 多年主要用在电信领域。
2004 年：Google 流量爆炸，思科大机框跟不上。内部启动 Firehose 项目，第一次把 Clos 数学搬进数据中心。
2005 年：Firehose 1.1 真上线，是 Google 数据中心第一代自建网络。
2008 年：Watchtower 进入 10 GbE 时代。
2012 年：Jupiter 上 40 GbE，单集群 1.3 Pbps。同期 Google 的广域网项目 B4 也用 SDN，两者并称 SDN 工业落地的两座灯塔。
2015 年：SIGCOMM 这篇论文一次性把十年讲完——之前 Google 一直只字不提，业界靠论文片段和招聘要求猜。

学到什么

大规模问题往往要换数学模型 — 不是把现有交换机做大，是换成 Clos 这种 60 年前的拓扑数学。
专用 vs 通用的钟摆——网络设备这一波是”通用商用芯片 + 软件定义”赢，跟 CPU/GPU 通用化是同一个道理。
中心化 vs 分布式不是非此即彼 — Jupiter 是主路径中心化 + 兜底分布式，两套都要。
百倍量级的增长不是一代搞定 — 是 5 代、10 年、不断换硬件 + 改控制平面累积出来的。
公开十年总结的勇气 — 论文 2015 年才发，意味着 Google 内部已经迭代到下一代了。这种”领先一代再公开”的节奏值得学。

给零基础读者的阅读建议

如果你是第一次读这种网络系统论文：

不要纠结具体的端口数——论文里很多”k 个 m 端口交换机拼成 N 端口”的数学，第一遍跳过没关系
重点读第 3 节（拓扑演进）和第 5 节（控制平面）——这两节讲故事性最强
先理解”对分带宽”（bisection bandwidth）这个词——把网络一刀切两半，这两半之间能跑多少 Gbps，就是这个网络的真实能力
配合 B4 论文一起读——一个讲数据中心内部，一个讲数据中心之间，凑成 Google 网络全貌

关联

akamai-2002 —— Akamai 是从用户侧做边缘加速；Jupiter 是从数据中心内部做高速互联，互补
fielding-rest-2000 —— 都是”约束驱动设计”的范例，REST 约束 Web、Jupiter 约束数据中心网络
llvm —— 模块化设计哲学相通：都把巨型系统拆成可换零件
lamport-tla-1994 —— 中心化控制器的状态机正确性，正是 TLA 这种工具的用武之地

反向链接

akamai-2002 —— Akamai 2002 — 把网站搬到离用户 10 毫秒的地方
b4-2013 —— B4 — Google 用 SDN 把跨数据中心 WAN 利用率拉到 95%+
lamport-tla-1994 —— TLA — 把状态机和时序逻辑捏成一个公式
llvm —— LLVM — 模块化编译器框架