波仔
☁️ 第四章 构建云服务的技术
📄 一句话概括

扁平网络（Spine-Leaf 结构）让任意两台服务器之间的跳数都一样——它把传统三层结构里【同架 3 跳、跨架 5 跳、还要看当时负载】变成【无论在哪都是 2 跳】；之所以要这么改，是因为流量方向变了：传统时代南北向（外面进来）占八成，云时代东西向（服务器互相调用）占八成。

📝 本节和前面几节的关系

这是【网络的虚拟化】三节的最后一节。前两节讲的是隔离方式（4-11）和谁来决定路径（4-12）；这一节讲的是物理拓扑本身该长什么样。

顺序上它是前面几节的结果：因为应用被拆成了微服务（4-10），服务器之间的调用次数暴涨——原来一次页面请求可能只访问一次数据库，现在要穿过十几个服务。流量结构变了，网络结构就必须跟着变。

一、先把三种流量分清楚

讨论网络结构之前，先分清流量往哪儿走：

名称 从哪到哪 传统时代 云时代
南北向 用户 ↔ 数据中心 约占 80% 约占 20%
东西向 服务器 ↔ 服务器 约占 20% 约占 80%

这个翻转是一切变化的起因：

二、扁平网络的结构与收益

扁平结构（通常叫 Spine-Leaf）改掉的就是这个绕路：

架构 同机架 跨机架 说明
传统三层结构 3 跳 5 跳 同架也要上汇聚，跨架必过核心
扁平（Spine-Leaf） 2 跳 2 跳 任何两台之间跳数都一样

为什么【跳数一样】这件事这么重要：因为它让延迟变得可预测。

再往下推一层，收益是三个：

  1. 容量可计算：从【靠经验】变成【可以做算术】
  2. 扩展是水平加设备：带宽不够就多加一组 Spine/Leaf，不需要重新设计层次
  3. 排障路径固定：任何一条链路出问题，影响的是【经过它的那一批】，范围清楚

三、动手 Demo：跳数、延迟与流量方向

看到什么算成功：

==================================================================================================
【Demo 13】扁平网络：为什么云数据中心不用传统三层结构
==================================================================================================
  传统数据中心是三层结构：接入层 → 汇聚层 → 核心层 → 再往下。
  问题在于：服务器之间的流量要一路上到核心再下来，每一跳都要时间。

  两台服务器通信的跳数：

    架构                      同机架        跨机架        说明
    ----------------------------------------------------------------------------------------
    传统三层结构              3 跳          5 跳          同架也要上汇聚，跨架必过核心
    扁平（Spine-Leaf）        2 跳          2 跳          任何两台之间跳数都一样
    ----------------------------------------------------------------------------------------
  【跳数一样】这件事看着不起眼，实际是扁平网络的精髓：
  延迟变得可预测。传统结构里，两个机架的机器之间隔多少跳，取决于
  当时网络的拓扑和负载，做性能测试时数据会飘；扁平的答案是固定的 2 跳。

  推动这件事的是流量方向变了：

    时期                    南北向流量        东西向流量
    --------------------------------------------------------------------------------
    传统（客户端服务器）    约占 80%          约占 20%
    云数据中心（微服务）    约占 20%          约占 80%
    --------------------------------------------------------------------------------
  原来流量是【外面进来、里面出去】，三层结构天然合适；
  现在 80% 是服务器内部互相调用，那就要好好优化横向这条路——
  这正是扁平网络存在的理由。

读结果：

30 秒实验

在任意一台机器上执行（Windows 用 tracert，Linux/macOS 用 traceroute）：

tracert 8.8.8.8

看输出有多少跳，以及每一跳的延迟。

做完这个你会看到两件事：① 跳数越多，累计延迟越大（这解释了为什么减少跳数有意义）；② 要到达同一个目的，路径通常是固定的——因为网络协议会选一条稳定的路径，而这条路径一旦变了（比如某条链路故障），延迟就会跟着变。扁平网络做的事就是把【路径会变】这件事圈到最小范围。

常见误区

  1. 错误：扁平网络的【扁平】是指只有一层交换机。——纠正：【扁平】指的是跳数一致，不是层数少。它其实是有层次的（Spine 在上、Leaf 在下），只是任何两台服务器之间都固定走【上到 Spine 再下来】这条 2 跳的路。所以叫【扁平】是因为延迟分布变得平坦，而不是拓扑被压成了一层。

  2. 错误：跳数少就一定快。——纠正：延迟由【每一跳的处理时间 × 跳数】加上【链路传输时间】共同决定，而链路传输时间往往是大头（尤其是跨机房、跨城）。所以在局域网内 3 跳改 2 跳，省的是几微秒到几百微秒——这不是性能优化，是让你的性能变得【可计算、可预测】。追求极限性能时要看的是带宽、拥塞和排队，而不是只数跳数。

  3. 错误：既然东西向占八成，那外部访问就不重要了。——纠正：占比少不等于不重要。南北向是用户感知到的那条路——它慢一点都不行，因为用户直接看到。所以扁平网络的结构必须同时把南北向接好（通常的做法是让外部的流量也从 Leaf 进来，由同一层转发）。这里的关键是【占比用来决定设计重点，不是决定谁能被牺牲】。

  4. 错误：扁平网络是云服务商才需要的，一般企业用不上。——纠正：它由【东西向流量占比】决定，而不是由【是不是云】决定。一个企业内部如果大量系统互相调用（比如微服务、大数据集群、虚拟化集群的存储流量），它同样会撞上同一个问题。所以判断标准是：你的网络里，服务器之间的流量占比有多高？ 高，就值得考虑扁平结构。

自测三问（点开对答案） 1. 为什么【跳数一致】这件事比【跳数少】更重要？ —— 因为**一致意味着可预测，而可预测才能做规划**。跳数少但不一致（同架 3 跳、跨架 5 跳），意味着**同一对服务器的通信质量取决于它们被放在哪儿**——那容量规划、性能测试、故障影响范围都算不准。跳数一致之后，**【两个服务之间隔多远】不再是一个变量**，于是可以放心地按平均值做设计。**工程上，可预测往往比绝对最优更有价值。** 2. 流量从南北向为主变到东西向为主，这个变化是什么造成的？ —— **由应用架构的变化造成的**。传统单体应用跑在两三台服务器上，用户从外面访问它——流量自然是南北向；而微服务把系统拆成几十个服务，**一次用户请求会在服务器之间引发十几次调用**（用户只看到一次，但内部走了十几趟）。**所以东西向流量的增长，是【拆】的必然结果**——这也是 4-10 里那三条代价之一（网络调用变多）在网络层面的体现。 3. 如果一个企业的东西向流量也很高，它该怎么做？ —— **先量一下，再决定**。第一步是**确认占比**（网络设备通常能给出端口流量的统计），因为【凭感觉】经常是错的——很多企业以为自己东西向很多，实际统计下来南北向仍是大头。第二步才是**如果东西向确实占多数，再考虑调整结构**（不一定非要重建，也可以【先优化关键路径】，比如把互调最多的几台服务器放在同一对 Leaf 下面）。**先测量后动结构，是这一类改造的通用顺序。**

相关笔记