fix typo

application-centric/application-centric.md

@@ -2,7 +2,7 @@
 
 回顾过去十几年间的技术演进历程，精彩纷呈！
 
-从单体应用到分布式架构，系统能力大幅提升，但也引入了更多的不确定性，比如节点可能随时宕机、网络有不等的延迟、消息可能丢失。为了解决这些不确定性，业界提出了诸多的分布式理论和协议，如 CAP 定理、BASE 理论以及共识算法（Paxos、Raft 等），以保障系统稳定运行。
+从单体系统到分布式系统，系统能力大幅提升，但也引入了更多的不确定性。比如节点可能随时宕机、网络有不等的延迟、消息可能丢失。为了解决这些不确定性，业界提出了诸多的分布式理论和协议，如 CAP 定理、BASE 理论以及共识算法（Paxos、Raft 等），以保障系统稳定运行。
 
 进入微服务时代，这些理论推动基础设施能力演进，这些能力（服务发现、负载均衡、故障转移、动态扩容）从业务逻辑中抽象出来，以 SDK（中间件）形式提供给应用开发者。中间件的出现其实体现了一种朴素的“关注点分离”的思想，使得你可以在不需要深入了解具体基础设施能力细节的前提下，以最小的代价学习和使用这些基础设施能力！
 

balance/balance-features.md

@@ -1,8 +1,8 @@
-# 6.2 负载均衡器总体功能
+# 4.2 负载均衡器总体功能
 
 现代负载均衡器的功能已远超其初衷。本节将简要介绍负载均衡器的常见功能，以帮助读者对其有个整体性的认识。
 
-## 6.2.1 服务发现
+## 4.2.1 服务发现
 
 服务发现是负载均衡器识别后端服务器的一种机制，不同的实现方式差异较大，以下是几种常见的实现方式：
 
@@ -11,38 +11,38 @@
 - **服务注册中心**（如 Zookeeper、Etcd、Consul 等）：后端服务器启动时将服务名称、地址、端口及健康检查信息注册到这些系统中。客户端通过查询 API 获取服务信息。这些系统通常内置健康检查机制，定期监控服务状态，并自动更新服务列表。
 - **Envoy 通用数据平面 API**：提供标准化的数据平面接口（xDS 协议），支持跨平台和跨环境的服务发现（详见本书第八章 8.3 节）。
 
-## 6.2.2 健康检查
+## 4.2.2 健康检查
 
 健康检查用于评估后端服务器是否能够正常处理请求，识别不可用的服务器并将流量重新分配。健康检查有两种方式：
 
 - **主动健康检查**：负载均衡器定期向后端发送健康探测请求，根据响应状态判断后端服务器是否健康。例如，某些七层负载均衡器会请求特定的健康检查路径（如 /health 或 /status），通过 HTTP 状态码来判断后端服务的健康状态。
 - **被动健康检查**：负载均衡器通过持续监控请求、响应和连接的状态，分析异常情况来判断后端服务器的健康状态。如果在一段时间内发现某个后端出现多次连接失败或超时等问题，负载均衡器会将该后端标记为不健康。
 
-## 6.2.3 粘性会话
+## 4.2.3 粘性会话
 
 对于某些特定应用，确保属于同一会话的请求被路由到相同的后端服务器至关重要。
 
 会话的定义因业务而异，可能基于 HTTP cookies、客户端地址、请求头或其他相关属性来确定。大部分七层负载均衡器支持通过配置 HTTP cookies 或 IP 哈希来实现“粘性会话”（sticky session）。
 
 值得注意的是，粘性会话涉及缓存、临时状态管理，实现粘性会话的设计通常很脆弱（赖于特定服务器、无法动态扩展、不可预测的负载分配问题等）。一旦处理会话的后端出现故障，整个服务都会受到影响。因此，设计具有该特性的系统时，需要格外谨慎！
 
-## 6.2.4 TLS 卸载
+## 4.2.4 TLS 卸载
 
 TLS 卸载（TLS Termination）是指将 TLS 加密/解密、证书管理等操作由负载均衡器统一处理。这样做的好处是：
 
 - **减轻后端负载**：后端服务器无需处理加密/解密操作，可以专注于业务逻辑处理。
 - **减少运维负担**：负载均衡器集中管理 SSL 证书的配置和更新，避免每个后端服务器单独管理证书。
 - **提升请求效率**：负载均衡器通常具备硬件加速能力，并经过优化，能更高效地处理 TLS 连接（详见本书第二章 2.5.2 节）。
 
-## 6.2.5 安全和 DDoS 防御
+## 4.2.5 安全和 DDoS 防御
 
 作为集群的唯一入口，负载均衡器不仅是流量的调度中心，也是系统安全的第一道防线。
 
 负载均衡器可以作为访问控制点，拦截来自不受信任的来源的请求，防止恶意流量进入内部系统。此外，负载均衡器可以通过部署 IP 黑/白名单、流量限速、请求鉴权等功能，强化对外部攻击的防护能力。
 
 另一方面，负载均衡器通过支持高级安全功能（如 SSL/TLS 终端加密和 Web 应用防火墙）进一步增强了系统的安全性。在面临 DDoS 攻击时，负载均衡器能够通过流量分散、智能限速等手段，有效减轻攻击压力，保护内部资源不受影响。
 
-## 6.2.6 可观测性
+## 4.2.6 可观测性
 
 从基本的统计信息（如流量、连接数和错误率）到与微服务架构集成的调用链追踪，不同层次的负载均衡器输出的可观测性数据各异：
 
@@ -51,7 +51,7 @@ TLS 卸载（TLS Termination）是指将 TLS 加密/解密、证书管理等操
 
 需要注意的是，输出可观测性数据并非没有代价，负载均衡器需要进行额外处理来生成这些数据，但所带来的收益远超过那一点性能损失。
 
-## 6.2.7 负载均衡
+## 4.2.7 负载均衡
 
 负载均衡器字面意思是，给到一组健康的后端，选择谁来处理用户请求？也就是负载均衡器的调度算法。
 

balance/balance-topology.md

@@ -1,10 +1,10 @@
-# 6.3 负载均衡部署拓扑
+# 4.3 负载均衡部署拓扑
 
 本节将介绍四种负载均衡部署拓扑，不同的部署拓扑决定了流量如何被分配、如何实现冗余和高可用性，进而影响系统的性能、可扩展性和容错能力。
 
-## 6.3.1 中间代理型
+## 4.3.1 中间代理型
 
-第一种是中间代理型部署拓扑，如图 6-5 所示。这是最常见的负载均衡部署方式，负载均衡器位于客户端与后端服务器之间，负责将请求转发至多个后端服务器。
+第一种是中间代理型部署拓扑，如图 4-5 所示。这是最常见的负载均衡部署方式，负载均衡器位于客户端与后端服务器之间，负责将请求转发至多个后端服务器。
 
 在这种拓扑中，负载均衡器可以分为以下三类：
 
@@ -18,7 +18,7 @@
 
 :::center
   ![](../assets/balancer.svg)<br/>
- 图 6-5 中间代理型
+ 图 4-5 中间代理型
 :::
 
 ## 6.3.2 边缘代理型
@@ -33,30 +33,30 @@
 
 :::center
   ![](../assets/balancer-edge-proxy.svg)<br/>
- 图 6-6 网络边缘型
+ 图 4-6 网络边缘型
 :::
 
-## 6.3.3 客户端内嵌
+## 4.3.3 客户端内嵌
 
-为解决中间代理型拓扑的单点故障问题，出现了更复杂的解决方案，其中之一是将负载均衡器以 SDK 库形式嵌入客户端（如图 6-7 所示）。这些 SDK 库如 Finagle、Eureka、Ribbon 和 Hystrix 等，它们优缺点是：
+为解决中间代理型拓扑的单点故障问题，出现了更复杂的解决方案，其中之一是将负载均衡器以 SDK 库形式嵌入客户端（如图 4-7 所示）。这些 SDK 库如 Finagle、Eureka、Ribbon 和 Hystrix 等，它们优缺点是：
 
 - 优点：将负载均衡器功能“转移”至客户端，避免了单点故障问题；
 - 缺点：需要为每种编程语言实现相应的 SDK，且在项目复杂时，处理版本依赖和兼容性问题变得棘手（微服务框架的相关问题将在本书第八章 8.2 节中详细讨论，读者可参考进一步了解）。
 
 :::center
   ![](../assets/balancer-sdk.svg)<br/>
- 图 6-7 客户端内嵌型
+ 图 4-7 客户端内嵌型
 :::
 
-## 6.3.4 边车代理型
+## 4.3.4 边车代理型
 
 边车代理型拓扑近年来在微服务架构中得到广泛应用，并发展成为一种被称为“服务网格”（Service Mesh）的架构模式。
 
 边车代理的基本原理是在应用容器或服务旁边部署一个独立的代理容器，用于实现请求的负载均衡和流量管理。目前，像 Envoy 和 Linkerd 等网络型边车代理已被广泛应用。关于服务网格的技术原理，笔者将在第八章中进行详细阐述。
 
 :::center
   ![](../assets/balancer-sidecar.svg)<br/>
- 图 6-8 边车代理型
+ 图 4-8 边车代理型
 :::
 
 总体而言，中间代理型负载均衡器正逐步演变为功能更强大的“网关”，所有请求通过单一入口（即网关）进入集群。在这种架构下，负载均衡器作为网关，不仅负责基本的请求转发，还承担更高级的请求管理与安全控制，包括 TLS 卸载、请求限制、身份验证和复杂内容路由等。同时，针对东西向流量（即服务间通信），边车代理模式“透明”地接管了服务间的通信治理，正逐渐成为主流选择。

balance/balance.md

@@ -1,16 +1,16 @@
-# 6.1 负载均衡与代理
+# 4.1 负载均衡与代理
 
 在讨论负载均衡时，"负载均衡器"（Load Balancer）和"代理"（Proxy）这两个术语常被混用。严格来说，并非所有代理都属于负载均衡器，但大多数代理的核心功能都涵盖负载均衡。为了简化表述，本文将这两个术语视为大致等同，不作严格区分。
 
-图 6-1 展示了负载均衡高层架构图，客户端（Client）的请求通过负载均衡器（Load Balancer）转发至某个后端服务器（Backend）。从整体架构来看，负载均衡器承担以下职责：
+图 4-1 展示了负载均衡高层架构图，客户端（Client）的请求通过负载均衡器（Load Balancer）转发至某个后端服务器（Backend）。从整体架构来看，负载均衡器承担以下职责：
 
 - **服务发现**：识别系统中可用的后端服务器，并获取它们的地址，以便与后端进行通信。
 - **健康检查**：监测后端服务器的状态，确保只有健康的服务器能够接收请求。
 - **负载均衡**：根据适合的分配算法，将请求均匀分配到健康的后端服务器上，提高系统的整体性能与可靠性。
 
 :::center
   ![](../assets/balancer.svg)<br/>
- 图 6-1 负载均衡高层架构图
+ 图 4-1 负载均衡高层架构图
 :::
 
 合理使用负载均衡能为分布式系统带来多方面的好处：
@@ -20,18 +20,18 @@
 - **成本和性能收益**：后端服务器通常分布在多个网络区域（Zone/Region），负载均衡器根据策略将请求保持在同一网络区域内，从而提高服务性能（减少延迟）并降低资源成本（减少跨区域带宽费用）。
 
 从网络层次的角度来看，所有负载均衡器可以分为两类：四层负载均衡和七层负载均衡，分别对应 OSI 模型的第四层（传输层）和第七层（应用层）。
-## 6.1.1 四层负载均衡
+## 4.1.1 四层负载均衡
 
 需要注意的是，所谓的“四层负载均衡”并非严格限定于 OSI 模型的第四层（传输层）。实际上，它的工作模式涉及多个网络层次：
 - **第二层**（数据链路层）：通过修改帧头中的 MAC 地址，将请求从一个物理网络节点转发到另一个节点。这种方式通常用于同一广播域内的转发，例如交换机或桥接设备完成的二层转发操作。
 - **第三层**（网络层）：通过修改 IP 地址，实现跨子网的请求路由和转发。这是路由器的核心功能，通过修改数据包的源或目的 IP 地址，实现子网之间的通信和流量转发。
 - **第四层**（传输层）：通过修改 TCP/UDP 端口号或连接的目标地址，利用网络地址转换（NAT）技术隐藏内部网络结构，将请求从一个入口转发至多个后端服务。
 
-如图 6-2 所示，上述各个网络层次的共同特点是维持了传输层协议（如 TCP、UDP）的连接特性。如果读者在其他资料中看到“二层负载均衡”或“三层负载均衡”的说法，应该理解到这是负载均衡器在不同网络层次上的工作模式。
+如图 4-2 所示，上述各个网络层次的共同特点是维持了传输层协议（如 TCP、UDP）的连接特性。如果读者在其他资料中看到“二层负载均衡”或“三层负载均衡”的说法，应该理解到这是负载均衡器在不同网络层次上的工作模式。
 
 :::center
   ![](../assets/balancer4.svg)<br/>
- 图 6-2 四层负载均衡器“转发”客户端的 TCP 连接
+ 图 4-2 四层负载均衡器“转发”客户端的 TCP 连接
 :::
 
 典型情况下，四层负载均衡器处理的是 TCP、UDP 等连接协议，它并不关心传输字节所代表的具体应用内容，这些字节可能来自 Web 应用、数据库服务或其他网络服务。因此，四层负载均衡器具有广泛的应用范围，能够适应各种不同类型的网络服务。
@@ -47,7 +47,7 @@
 
 :::center
   ![](../assets/l4-connection-v2.svg)<br/>
-  图 6-3 四层负载均衡器下的“连接保持”问题
+  图 4-3 四层负载均衡器下的“连接保持”问题
 :::
 
 随着用户规模扩大，四层负载均衡器面临的“阻抗不匹配”问题将变得更加明显。
@@ -63,13 +63,13 @@
 
 七层负载均衡器工作在应用层，这意味着负载均衡器必须与后端服务器建立新的传输层连接，并将客户端的请求代理到后端服务器。
 
-图 6-4 展示了七层负载均衡器的工作原理。当客户端发送 HTTP 请求（stream）时：
+图 4-4 展示了七层负载均衡器的工作原理。当客户端发送 HTTP 请求（stream）时：
 
 - 请求 1（stream1）被代理至第一个后端服务器；
 - 请求 2（stream2）被代理至第二个后端服务器。
 :::center
   ![](../assets/balancer7.svg)<br/>
-  图 6-4 七层负载均衡器新建 TCP 连接至后端服务器
+  图 4-4 七层负载均衡器新建 TCP 连接至后端服务器
 :::
 
 七层负载均衡器能够处理更复杂的操作，原因在于它工作在应用层，能够检测和处理请求内容，包括：