Merge pull request johnlui#17 from gxlct008/main

fix:调整排版，调整常见英文的大小写

06. 拆分网络单点(下)：SDN 如何替代百万人民币的负载均衡硬件(网关、LVS、交换机)/README.md

@@ -1,12 +1,12 @@
 # 高并发的哲学原理（六）-- 拆分网络单点(下)：SDN 如何替代百万人民币的负载均衡硬件(网关、LVS、交换机)
 
-上一篇文章的末尾，我们利用负载均衡器打造了一个五万 QPS 的系统，本篇文章我们就来了解一下负载均衡技术的发展历程，并一起用 SDN（软件定义网络）技术打造出一个能够抗住 200Gbps 的负载均衡集群。
+上一篇文章的末尾，我们利用负载均衡器打造了一个五万 QPS 的系统，本篇文章我们就来了解一下负载均衡技术的发展历程，并一起用 SDN（软件定义网络）技术打造出一个能够扛住 200Gbps 的负载均衡集群。
 
 ## 负载均衡发展史
 
 ### F5 创业史
 
-1996 年，华盛顿大学的几个学生共同创建了一家生产负载均衡设备的公司，并用美国人民的老朋友——飓风的最高等级 F5 作为品牌名，以表示他们的设备可以抗住最狂暴的网络流量。彼时，互联网的规模每 100 天增长一倍，这也让 F5 在成立三年后火速上市。2001 年，F5 公司在经历了互联网泡沫后，顺利地把设备卖进了银行等大型机构，因为 F5 比微软和甲骨文都更有前瞻性：他们的 iControl 系统可以提供 API，让大型机构自己开发软件来控制通过负载均衡设备的所有流量。
+1996 年，华盛顿大学的几个学生共同创建了一家生产负载均衡设备的公司，并用美国人民的老朋友——飓风的最高等级 F5 作为品牌名，以表示他们的设备可以扛住最狂暴的网络流量。彼时，互联网的规模每 100 天增长一倍，这也让 F5 在成立三年后火速上市。2001 年，F5 公司在经历了互联网泡沫后，顺利地把设备卖进了银行等大型机构，因为 F5 比微软和甲骨文都更有前瞻性：他们的 iControl 系统可以提供 API，让大型机构自己开发软件来控制通过负载均衡设备的所有流量。
 
 早在 2001 年，软件的威力就已经开始展现。
 
@@ -30,7 +30,7 @@
 
 2002 年 2 月，戴尔为 PowerEdge 1650 服务器第一次配上了千兆以太网。当时，负载均衡的主流实现还是基于硬件的，或者说是基于“软硬件一体化解决方案”的。在当时，服务器 CPU 的单核性能还很低，甚至核心数都很少，网卡芯片技术也没有今天这般牛皮（相比于下面将的 NPU），所以当时想用运行在标准操作系统(Windows/Linux)内的软件来实现千兆软网关还是一个“前沿探索项目”。更不要说万兆负载均衡了：PowerEdge 1650 发布的四个月后，万兆以太网的标准“IEEE 802.3ae 10 Gb/s 光纤以太网”才首次发布，距离万兆网卡在服务器端普及更是还有十多年的光景。
 
-不为人知的是，千兆以太网的光纤标准 1998 年才发布，千兆以太网的双绞线标准 1999 年才发布，而到了 2002 年，万兆以太网光纤标准就已经发布了。实际上，千兆以太网在消费端开始普及，也已经是 2010 年的事情了。
+鲜为人知的是，千兆以太网的光纤标准 1998 年才发布，千兆以太网的双绞线标准 1999 年才发布，而到了 2002 年，万兆以太网光纤标准就已经发布了。实际上，千兆以太网在消费端开始普及，也已经是 2010 年的事情了。
 
 21 世纪的头十年，最优秀的超千兆解决方案是：利用二层网络的链路聚合协议，使用多个千兆口同时负载均衡，实现超千兆的速度。而且当时能做到数 G 带宽的负载均衡设备动辄上百万，价格惊人，有需求的终端客户简直就是大冤种，不过在那个移动通信基站都要完全进口的年代，哪个中国人不是大冤种呢。
 
@@ -93,13 +93,13 @@
 
 ### 交换机技术的优缺点
 
-优点
+优点：
 
 1. 足够简单，所以硬件成本可以做到足够低
 2. 不需要和任何设备通信即可支持新设备接入，完全自学习
 3. 扩展性无敌，交换机可以随便级联，只要 MAC 表容量够，理论上可以插成一颗无限层级的树
 
-缺点
+缺点：
 
 1. 有网络风暴的风险：数据包被无脑的发到所有口，可能会被别的交换机再发回来，到时候你来我往，跑满线速，造成正常数据包的拥堵
 2. 网络回环非常恐怖：如果把交换机的两个口用一根线插在一起，那这台交换机会瞬间断网，左右互搏之术对交换机这种低层级设备来说过于困难了
@@ -116,7 +116,7 @@
 
 1998 年，在章文嵩博士二年级的时候，他发现 Cisco 的硬件负载均衡器要卖几万美金，觉得这玩意儿不难写，于是利用两周的课余时间创建并开源了 LVS（当时叫 IPVS）。时至今日，LVS 技术创造的商业价值已经无法计算，互联网上的绝大部分数据包，都会被 LVS 或者承袭 LVS 思想的软件处理。
 
-### 合并进 Linux kernel
+### 合并进 Linux Kernel
 
 2004 年，LVS（IPVS）被合并进了 kernel 2.4，从此开始，所有 Linux 都拥有了变身为负载均衡器的能力。
 
@@ -140,31 +140,31 @@ LVS 有三个常用模式：
 
 DR 模式下，LVS 只负责篡改数据包，不负责充当网关，所以我们还是需要一个网关在公网 ip 和私网 ip 之间进行 NAT 转换。我们依然假设客户端 ip 为 123.123.123.123，它发起了一个针对 110.242.68.3 的 80 端口的 HTTP 请求。
 
-当网关接收到一个发送给 110.242.68.3 的数据包时，发现协议为 TCP，目标端口为 80，查询自己的 NAT 表发现内部 ip 为 10.0.0.100（VIP，即虚拟ip），内部端口为 80，于是网关向局域网发出了一个 ip 包。由于端口都是 80 不变，协议都是 TCP 不变，所以本次网络请求中，有四个数据非常关键：源 ip 地址，目的 ip 地址，源 MAC 地址，目的 MAC 地址。
+当网关接收到一个发送给 110.242.68.3 的数据包时，发现协议为 TCP，目标端口为 80，查询自己的 NAT 表发现内部 ip 为 10.0.0.100（VIP，即虚拟ip），内部端口为 80，于是网关向局域网发出了一个 IP 包。由于端口都是 80 不变，协议都是 TCP 不变，所以本次网络请求中，有四个数据非常关键：源 ip 地址，目的 ip 地址，源 MAC 地址，目的 MAC 地址。
 
 1. 客户端发给网关的数据包情况为：
-    1. 源 ip：123.123.123.123
-    2. 目的 ip：110.242.68.3
-    3. 源 MAC：客户端 MAC
-    4. 目的 MAC：网关 MAC
+   (1). 源 ip：123.123.123.123
+   (2). 目的 ip：110.242.68.3
+   (3). 源 MAC：客户端 MAC
+   (4). 目的 MAC：网关 MAC
 2. 网关向局域网发出的数据包情况为：
-    1. 源 ip：123.123.123.123
-    2. 目的 ip：10.0.0.100（变了）
-    3. 源 MAC：网关 MAC（变了）
-    4. 目的 MAC：LVS MAC（变了）
+   (1). 源 ip：123.123.123.123
+   (2). 目的 ip：10.0.0.100（变了）
+   (3). 源 MAC：网关 MAC（变了）
+   (4). 目的 MAC：LVS MAC（变了）
 3. LVS 接到该数据包后，会选择一个后端服务器，假设它选中的是 10.0.0.1 来真正处理请求，则 LVS 会对数据包进行如下修改后，再发送给 10.0.0.1：
-    1. 源 ip：123.123.123.123
-    2. 目的 ip：10.0.0.100
-    3. 源 MAC：LVS MAC（变了）
-    4. 目的 MAC：10.0.0.1 的 MAC（变了）
+   (1). 源 ip：123.123.123.123
+   (2). 目的 ip：10.0.0.100
+   (3). 源 MAC：LVS MAC（变了）
+   (4). 目的 MAC：10.0.0.1 的 MAC（变了）
 4. 10.0.0.1 在收到该数据包后，发现这个包的目的 MAC 地址确实是自己，而且目的 ip 10.0.0.100（VIP）也是自己，于是对该数据包进行正常的处理，然后将处理结果发送出去：
-    1. 源 ip：10.0.0.100
-    2. 目的 ip：123.123.123.123
-    3. 源 MAC：10.0.0.1 的 MAC
-    4. 目的 MAC：网关 MAC（因为目的 ip 不在“ip+子网掩码”所确定的局域网范围内，所以该数据包会被发送给网关）
+   (1). 源 ip：10.0.0.100
+   (2). 目的 ip：123.123.123.123
+   (3). 源 MAC：10.0.0.1 的 MAC
+   (4). 目的 MAC：网关 MAC（因为目的 ip 不在“ip+子网掩码”所确定的局域网范围内，所以该数据包会被发送给网关）
 5. 网关收到返回的数据包后，通过查询“五元组关系表”，对端口和 ip 信息做出正常的 NAT 修改后，将数据包发送回 123.123.123.123，请求结束。
 
-大家可以看出 DR 模式的特点：
+#### 大家可以看出 DR 模式的特点：
 
 1. LVS 只需要处理正向数据包，通常正向数据包（请求）要远小于反向数据包（响应），所以带宽占用较低
 2. 反向数据包走的是标准的二层以太网，每台上游服务器都可以跑满自己的线速
@@ -200,13 +200,13 @@ LVS 就是网关型负载均衡继续拆单点的结果：LVS 自己只承担数
 
 LVS 单机 20G 的带宽显然和我们 200G 的目标还相去甚远，但是我们接下来要做的第一件事并不是提升系统容量，而是先提升系统的稳定性：搭建高可用架构。
 
-Keepalived 是一个非常优秀的搭建高可用集群的开源软件，它最开始就是为了和 LVS 配合而出现的，主要的作用是构建一个自选举集群。它支持 3 台控制器集群独立部署，也支持部署到应用机器上。它和 LVS 一样基于虚拟 ip 技术，可以在任意标准以太网内运行。
+Keepalived 是一个非常优秀的搭建高可用集群的开源软件，它最开始就是为了和 LVS 配合而出现的，主要的作用是构建一个自选举集群。它支持 3 台控制器集群独立部署，也支持部署到应用机器上。它和 LVS 一样基于虚拟 IP 技术，可以在任意标准以太网内运行。
 
 ### Keepalived 运行原理
 
 Keepalived 运行原理说起来其实非常简单：
 
-1. 两台机器上都配置同一个虚拟 ip（VIP）：即两台机器的真实 ip 分别是 10.0.0.101 和 10.0.0.102，但是虚拟出一个 ip 10.0.0.100，这个 ip 不属于任何物理设备，可以在两台机器之间任意切换绑定
+1. 两台机器上都配置同一个虚拟 IP（VIP）：即两台机器的真实 ip 分别是 10.0.0.101 和 10.0.0.102，但是虚拟出一个 ip 10.0.0.100，这个 ip 不属于任何物理设备，可以在两台机器之间任意切换绑定
 2. 两台机器频繁通信，通过分数计算确定哪台机器的分数更高，由这台机器向局域网发送 VRRP 组播报文宣称 VIP 在我这里
 3. 当分数高的那台机器宕机，或者断网，或者检测到服务进程消失（例如 Nginx 挂掉），分数低的那台机器会在极短时间内立刻顶上，宣称 VIP 在自己这里
 4. 发送给 VIP 的数据包会在短时间失效之后由新机器承接（实测中断时间小于 1 秒），实现集群高可用
@@ -235,7 +235,7 @@ LVS 和 Keepalived 配合，基于多台物理机，可以实现一个高可用
 
 ### Linux 网络栈优化
 
-由于 LVS 基于 kernel 里的 netfilter，依赖 Linux 网络栈，导致进程切换需要读写内存，数据包的发送和接收也要读写内存，在极高的带宽需求之下，相对耗时的内存读写就成了阻碍性能进一步提升的最大障碍。DPDK 和 NPU 硬件卸载就是这个问题的两个解决方案。
+由于 LVS 基于 Kernel 里的 Netfilter，依赖 Linux 网络栈，导致进程切换需要读写内存，数据包的发送和接收也要读写内存，在极高的带宽需求之下，相对耗时的内存读写就成了阻碍性能进一步提升的最大障碍。DPDK 和 NPU 硬件卸载就是这个问题的两个解决方案。
 
 #### DPDK
 
@@ -245,7 +245,7 @@ DPDK 是 Intel 开源的高性能网络数据处理框架，运行在用户态
 
 #### 网卡芯片硬件卸载
 
-最新的 NPU 已经可以支持很多的硬件卸载特性：IP 分片、TCP 分段、小包重组、checksum 校验、硬件 QOS，以及最重要的 VXLAN 的剥离和插入：此功能是 DPVS 的重要组成部分，可以减少数据流互相干扰，大幅提升系统总容量。
+最新的 NPU 已经可以支持很多的硬件卸载特性：IP 分片、TCP 分段、小包重组、checksum 校验、硬件 QOS，以及最重要的 VXLAN(虚拟扩展本地局域网) 的剥离和插入：此功能是 DPVS 的重要组成部分，可以减少数据流互相干扰，大幅提升系统总容量。
 
 此外，RDMA 技术也是网卡芯片的一大进步方向，我们将会在后面讲数据库的计算和存储分离的时候详细了解。
 
@@ -255,8 +255,7 @@ DPDK 是 Intel 开源的高性能网络数据处理框架，运行在用户态
 
 #### 数据包亲和性优化
 
-阿里云通过 RSS 技术把同一个五源组报文扔到同一个 CPU 上处理，保证入方向的所有相同连接上的报文都能交给相同的 CPU 处理。同时在每个核在转发出去时都用当前 CPU 上的 Local 地址，通过设置一些 fdir 规则，报文回来时后端服务器访问的目的地址就是对应 CPU 上的 local 地址。这样就能实现这一条连接上面左右方向的报文都被同一个 CPU 处理，将存储“五元组对应关系”的内存数据库在不同的 CPU 核心上隔离开，这样就可以利用多个 VIP 来实现整体系统容量的线性提升³。
-
+阿里云通过 RSS 技术把同一个五源组报文扔到同一个 CPU 上处理，保证入方向的所有相同连接上的报文都能交给相同的 CPU 处理。同时在每个核在转发出去时都用当前 CPU 上的 local 地址，通过设置一些 fdir 规则，报文回来时后端服务器访问的目的地址就是对应 CPU 上的 local 地址。这样就能实现这一条连接上面左右方向的报文都被同一个 CPU 处理，将存储“五元组对应关系”的内存数据库在不同的 CPU 核心上隔离开，这样就可以利用多个 VIP 来实现整体系统容量的线性提升³。
 
 ### 性能问题还是要靠架构解决
 
@@ -270,7 +269,7 @@ DPDK 是 Intel 开源的高性能网络数据处理框架，运行在用户态
 
 #### 1. 拆除 ip 单点：朴素的 DNS
 
-基于 DNS 技术做单域名多 ip 扩容曾是第一代负载均衡技术：朴素的 DNS 协议可以将用户的终端流量直接导向全国多个机房，实现真·性能倍增，这种技术特别适合 web 1.0 时代的静态网页，也适合搜索引擎等没有数据同步需求的服务。
+基于 DNS 技术做单域名多 ip 扩容曾是第一代负载均衡技术：朴素的 DNS 协议可以将用户的终端流量直接导向全国多个机房，实现真·性能倍增，这种技术特别适合 Web 1.0 时代的静态网页，也适合搜索引擎等没有数据同步需求的服务。
 
 在当年电信、网通、铁通、教育网之间只有 40G 小水管的年代，DNS 技术极大地提升了普通用户获取网络资源的速度，提升了用户体验：引导每个运营商的用户访问放在该运营商机房的服务器，可以实现“手搓 CDN 架构”。最后一篇文章我们还会谈到 DNS 技术在终极高可用架构中的价值。
 
@@ -322,7 +321,7 @@ DPDK 是 Intel 开源的高性能网络数据处理框架，运行在用户态
 
 ![](https://qn.lvwenhan.com/2023-01-08-16731890288560.jpg)
 
-这是 H3C 集团 ComwareV7 通用操作系统的架构图，当下 H3C 正在销售的产品中，除了网络边界设备（如防火墙）外，其余几乎所有的交换机、AC、AP 等以局域网为主战场的设备已经全面采用了该系统。和上一代 V5 相比，最大的变化就是把系统内核切换到了 Linux kernel。
+这是 H3C 集团 ComwareV7 通用操作系统的架构图，当下 H3C 正在销售的产品中，除了网络边界设备（如防火墙）外，其余几乎所有的交换机、AC、AP 等以局域网为主战场的设备已经全面采用了该系统。和上一代 V5 相比，最大的变化就是把系统内核切换到了 Linux Kernel。
 
 这张图中最重要的就是那根“细细的红线”：网络管理进程完全位于用户态。这其实就是 DPDK 思想：传统的 UNIX 网络模型已经无法应付单机 10G 的速度了，需要读写内存的进程切换太慢了，必须要从底层网络数据处理流程上革命：抛弃操作系统提供的网络栈，直接在用户态接管所有网络流量，实现更高性能。
 
@@ -361,6 +360,3 @@ DPDK 是 Intel 开源的高性能网络数据处理框架，运行在用户态
 1. Envoy 作者 Matt Klein 2017 年的一篇英文博客 Introduction to modern network load balancing and proxying https://blog.envoyproxy.io/introduction-to-modern-network-load-balancing-and-proxying-a57f6ff80236
 2. 用dperf测试LVS的性能数据 https://mp.weixin.qq.com/s?__biz=Mzg5MjcyNzY4Mg==&mid=2247483684&idx=1&sn=9a065f97f1a239efbb371fedde3b8d3e
 3. 高性能负载均衡设计与实现 https://zhuanlan.zhihu.com/p/29949340
-
-
-