更新内容

architecture/architect.md

@@ -2,7 +2,7 @@
 
 云原生架构是优雅的、灵活的、弹性的...，但不能否认这些优势的背后是它的学习曲线相当陡峭。
 
-如果你有志投入云原生领域，希望构建一个高可用（高研发效率、低资源成本，且兼具稳定可靠）的云原生架构，对能力要求已提升到史无前例的程度。总结来说，除了掌握基础的 Docker 和 Kubernetes 知识外，知晓图 1-34 所示的几个领域也是必备要求。
+如果你有志投入云原生领域，希望构建一个高可用（高研发效率、低资源成本，且兼具稳定可靠）的云原生架构，对能力要求已提升到史无前例的程度。总结来说，除了掌握基础的 Docker 和 Kubernetes 知识外，熟知图 1-34 所示的几个领域也是必备要求。
 
 :::center
   ![](../assets/cloud.svg)<br/>

balance/balance4-ha.md

@@ -27,22 +27,3 @@ VRRP 解决的问题是，通过 VRRP 协议协商，虚拟出一个 IP 地址
 - 平稳状态下 50% 的资源是空闲的，备用服务器一直空转，**资源无法充分利用**。
 - 其次，**现代分布式系统追求更高的容错性**。理想情况下，一个系统就算多个实例同时挂掉，预期仍能继续运行，而主/备实例同时挂掉时，服务就彻底挂了。
 
-## 2.一致性哈希容错方式
-
-接下来我们继续看**基于集群的一致性哈希容错和可扩展设计方案**，它的工作原理如图 4-12 所示。
-
-:::center
-  ![](../assets/balancer-ha-2.svg)<br/>
-  图 4-12 负载均衡一致性哈希容错和可扩展设计方案
-:::
-
-- 多个边缘路由器以相同的 BGP 权重通告所有 Anycast VIP，通过 ECMP（Equal-cost, Multi-path routing，等价多路由）保证每个 flow 的所有包都会到达同一个边缘路由器。
-- 多个四层负载均起以相同的 BGP 权重向所有的边缘路由器通告所有的 VIP 继续使用 ECMP 的方式为相同 flow 的包选择相同的四层负载均衡器。
-- 每个四层负载均衡器实例会做部分连接跟踪（conntrack）工作，然后使用一致性哈希为每个 flow 选择 一个后端。通过 GRE 封装将包从负载均衡器发送到后端。
-- 然后使用三角传输模式将应答包从后端直接发送到边缘路由器，最后到客户端。
-
-综合上述，看看一致性哈希容错模式是如何避免主备方式的缺陷：
-- **边缘路由器和负载均衡器实例可以按需添加**。因为每一层都用到了 ECMP，当新实例加入的时候，能最大程度地减少受影响的 flow 数量；
-- 在预留足够的突发量和容错的前提下，系统的资源利用率想达到多高就可以到多高。
-
-各类云厂商中的 SLB 以及绝大部分的现代四层负载均衡系统都在朝着这种设计演进。

balance/balance4.md

@@ -112,7 +112,7 @@ Tunnel 模式相当于 DR 模式的升级（支持了跨网）。由于需要对
 
 从上述可见，NAT 模式下，负载均衡器代表整个服务集群接收和响应请求，当流量压力较大时，系统的瓶颈就很容易体现在负载均衡器上。
 
-## 4.4.4 主备方式的设计
+## 4.4.4 主备容错模式
 
 到目前为止，本节讨论的单个负载均衡器的工作模式。假如单个负载均衡器挂了呢？如果一个负载均衡器实例挂了，那所有经过这个负载均衡器的的连接都会受到影响。
 
@@ -132,6 +132,26 @@ Tunnel 模式相当于 DR 模式的升级（支持了跨网）。由于需要对
 
 
 
-## 4.2.5 一致性哈希的设计
+## 4.5.5 一致性哈希容错模式
+
+
+接下来我们继续看**基于集群的一致性哈希容错和可扩展设计方案**，它的工作原理如图 4-12 所示。
+
+:::center
+  ![](../assets/balancer-ha-2.svg)<br/>
+  图 4-12 负载均衡一致性哈希容错和可扩展设计方案
+:::
+
+- 多个边缘路由器以相同的 BGP 权重通告所有 Anycast VIP，通过 ECMP（Equal-cost, Multi-path routing，等价多路由）保证每个 flow 的所有包都会到达同一个边缘路由器。
+- 多个四层负载均起以相同的 BGP 权重向所有的边缘路由器通告所有的 VIP 继续使用 ECMP 的方式为相同 flow 的包选择相同的四层负载均衡器。
+- 每个四层负载均衡器实例会做部分连接跟踪（conntrack）工作，然后使用一致性哈希为每个 flow 选择 一个后端。通过 GRE 封装将包从负载均衡器发送到后端。
+- 然后使用三角传输模式将应答包从后端直接发送到边缘路由器，最后到客户端。
+
+综合上述，看看一致性哈希容错模式是如何避免主备方式的缺陷：
+- **边缘路由器和负载均衡器实例可以按需添加**。因为每一层都用到了 ECMP，当新实例加入的时候，能最大程度地减少受影响的 flow 数量；
+- 在预留足够的突发量和容错的前提下，系统的资源利用率想达到多高就可以到多高。
+
+各类云厂商中的 SLB 以及绝大部分的现代四层负载均衡系统都在朝着这种设计演进。
+
 
 

balance/global-load-balancer.md

@@ -1,4 +1,4 @@
-# 4.6 全局负载均衡与集中式控制平面
+# 4.6 全局负载均衡
 
 未来的负载均衡系统会越来越将单个负载均衡器看做通用组件。
 

network/RDMA.md

@@ -25,9 +25,9 @@ InfiniBand 贸易协会）在 2000 年提出，因其极致的性能（能够实
 
 	如图 3-11 所示，RoCE 发展过程中出现了两个版本 RoCEv1 和 RoCEv2：
 	- RoCEv1 基于二层以太网，局限于同一子网，无法跨子网通信；
-	- RoCEv2 基于三层 IP，支持跨子网通信，使用标准的以太网交换设备。
+	- RoCEv2 基于三层 IP 网络，支持跨子网通信。
 
-	RoCEv2 解决了 RoCEv1 无法跨子网的局限，凭借其低成本和兼容性优势，广泛应用于分布式存储、并行计算等通用数据中心场景。根据云计算平台 Azure 公开的信息，至 2023 年，Azure 整个数据中心 70% 的流量已经是 RDMA 流量了[^1]。
+	RoCEv2 解决了 RoCEv1 无法跨子网的局限，凭借其低成本和兼容性优势，RoCE 技术开始广泛应用于分布式存储、并行计算等通用数据中心场景。根据云计算平台 Azure 公开的信息，至 2023 年，Azure 整个数据中心 70% 的流量已经是 RDMA 流量了[^1]。
 :::center
   ![](../assets/RoCE_Header_format.png)<br/>
   图 3-11 RoCE v1 只能在广播域内通信，RoCE v2 支持 L3 路由

network/tuntap.md

@@ -1,15 +1,15 @@
-# 3.5.2 虚拟网络设备 tun 和 tap
+# 3.5.2 虚拟网络设备 TUN 和 TAP
 
-tun 和 tap 是 Linux 内核 2.4.x 版本之后引入的虚拟网卡设备，主要用于用户空间（user space）和内核空间（kernel space）双向传输数据。这两种设备的区别与含义为：
-- tun 设备工作在网络层，处理的是 IP 数据包。它模拟的是一个网络层接口，允许用户空间程序接收和发送 IP 层的数据包。tun 设备常用于 VPN 应用，将网络流量从一个远程网络重定向到本地虚拟网络接口；
-- tap 设备工作在数据链路层，处理的是以太网帧。它模拟的是一个以太网接口，允许用户空间程序发送和接收以太网帧。TAP 设备通常用于虚拟机网络、桥接网络、虚拟交换机等场景，以模拟完整的二层网络通信。
+TUN 和 TAP 是 Linux 内核 2.4.x 版本之后引入的虚拟网卡设备，主要用于用户空间（user space）和内核空间（kernel space）双向传输数据。这两种设备的区别与含义为：
+- TUN 设备是虚拟网络接口设备，工作在网络层（Layer 3），主要处理 IP 数据包。它模拟了一个网络层接口，可以让用户空间程序接收和发送 IP 数据包；
+- TAP 设备也是虚拟网络接口，但它工作在数据链路层（Layer 2），主要处理 以太网帧。与 TUN 设备不同，TAP 设备传递的是完整的以太网帧，包括数据链路层头部，允许用户空间程序发送和接收以太网帧。
 
 
-Linux 系统中，内核空间和用户空间之间数据传输有多种方式，字符设备文件是其中一种。tap/tun 对应的字符设备文件为 /dev/net/tun。
+Linux 系统中，内核空间和用户空间之间数据传输有多种方式，字符设备文件是其中一种。TUN/TAP 对应的字符设备文件为 /dev/net/tun。
 
 当用户空间的程序 open() 字符设备文件时，返回一个 fd 句柄，同时字符设备驱动创建并注册相应的虚拟网卡网络接口，并以 tunX 或 tapX 命名。当用户空间的程序向 fd 执行 read()/write() 时，就可以和内核网络互通了。
 
-tun 和 tap 的工作原理基本相同，只是两者工作的网络层面不一样。如图 3-13所示，笔者以 tun 设备构建 VPN 隧道为例，说明其工作原理：
+TUN 和 TAP 两者工作原理基本相同，只是工作的网络层面不一样。如图 3-13 所示，笔者以 TUN 设备构建 VPN 隧道为例，说明其工作原理：
 - 首先，一个普通的用户程序发起一个网络请求；
 - 接着，数据包进入内核协议栈时并找路由。大致的路由规则如下:
 	```bash
@@ -27,4 +27,4 @@ tun 和 tap 的工作原理基本相同，只是两者工作的网络层面不
 
 将一个数据包封装到另一个数据包是构建网络隧道，实现虚拟网络的典型方式。
 
-本书第七章介绍的容器网络插件 Flannel，早期的设计中曾使用 tun 设备实现了 UDP 模式下的跨主机通信，但使用 tun 设备传输数据需要经过两次协议栈，且有多次的封包/解包过程，产生额外的性能损耗。这是后来 Flannel 弃用 UDP 模式的主要原因。
+本书第七章介绍的容器网络插件 Flannel，早期的设计中曾使用 TUN 设备实现了 UDP 模式下的跨主机通信，但使用 TUN 设备传输数据需要经过两次协议栈，且有多次的封包/解包过程，产生额外的性能损耗。这是后来 Flannel 弃用 UDP 模式的主要原因。

network/vxlan.md

@@ -31,7 +31,7 @@ VLAN 划分子网的具体方法是在以太帧的报文头中加入 VLAN Tag，
 
 通过 VLAN 划分子网固然可以解决广播风暴的频繁出现，但对那些既希望隔离，又希望某些主机能互通场景来说，划分 VLAN 的同时为不同 VLAN 建立互相访问的通道也是必要的。由于两个 VLAN 之间完全隔离的，不存在重合的广播域，因此它们之间的通信只能通过三层路由设备。
 
-最简单的三层路由模式通过单臂路由实现。单臂路由的网络拓扑如图 3-17 所示。路由器和交换机之间只有一条线路，该线路称 Trunk 链路。与之相对的，主机与交换机之间的链路称 Access 链路。Trunk 链路允许任何 VLAN ID 的数据包通过。需要路由的数据包通过 Trunk 链路到达路由器，路由后原路返回至交换机转发处理。所以大家给这种拓扑起了一个形象的名字 - 单臂路由。
+最简单的三层路由模式通过单臂路由实现。单臂路由的网络拓扑如图 3-17 所示。路由器和交换机之间只有一条线路，该线路称 Trunk 链路。与之相对的，主机与交换机之间的链路称 Access 链路。Trunk 链路允许任何 VLAN ID 的数据包通过。需要路由的数据包通过 Trunk 链路到达路由器，路由后原路返回至交换机转发处理。所以大家给这种拓扑起了一个形象的名字 —— 单臂路由。
 
 说白了，单臂路由就是从哪个口进去，再从哪个口出来，而不像传统网络拓扑中数据包从某个接口进入路由器又从另外一个接口离开路由器。为了实现上述中的单臂路由模式，以太网 802.1Q 规范中专门定义了子接口（Sub-Interface）的概念，它的作用是允许在同一张物理网卡上，针对不同的 VLAN 绑定不同的 IP 地址。通过将各子网的默认网关配置为对应的子接口地址，路由器通过修改 VLAN tag，即可实现不同 VLAN 之间跨子网的数据转发。
 
@@ -43,7 +43,7 @@ VLAN 划分子网的具体方法是在以太帧的报文头中加入 VLAN Tag，
 
 VLAN 固然通过划分子网的形式解决广播风暴，但它的缺陷也非常明显：
 - 第一个缺陷：在于 VLAN Tag 的设计。当时的网络工程师完全未料及云计算会发展得会如此普及，只设计了 12 位 bit 存储 VLAN ID，导致一个 VLAN 子网内的设备数量局限在 4000 个左右，显然无法支持大型数据中心数以万计的设备。
-- 第二个缺陷：跨数据中心通信非常麻烦。VLAN 属于二层网络技术，但是两个独立的数据中心之间只能通过三层网络互通。云计算的高速发展下，一个业务跨多个数据中心部署成为普遍需求，跨数据中心间传递 VLAN Tag 又是一件麻烦的事情；特别是系统容器化后，一台物理机内有数百个容器，每个容器都有独立的 IP 地址和 MAC 地址，带给路由、交换机等设备的容量压力成倍增加。
+- 第二个缺陷：跨数据中心通信非常麻烦。VLAN 属于二层网络技术，但是两个独立的数据中心之间只能通过三层网络互通。云计算的高速发展下，一个业务跨多个数据中心部署成为普遍需求，数据中心之间传递 VLAN Tag 又是一件麻烦的事情；特别是系统容器化后，一台物理机内运行着数百个容器，每个容器都有独立的 IP 地址和 MAC 地址，带给路由、交换机等设备的压力成倍增加。
 
 ## 2. 虚拟可扩展局域网 VXLAN