fix typo

balance/balance-features.md

@@ -1,6 +1,6 @@
-# 6.2 负载均衡器特性
+# 6.2 负载均衡器总体功能
 
-现代负载均衡器的功能已经远远超出了其最初的设计目标，本节简要介绍负载均衡器的常见功能，以帮助读者建立一个全面的认识。
+现代负载均衡器的功能已远超其初衷。本节将简要介绍负载均衡器的常见功能，以帮助读者对其有个整体性的认识。
 
 ## 6.2.1 服务发现
 
@@ -13,7 +13,7 @@
 
 ## 6.2.2 健康检查
 
-健康检查用于评估后端服务器是否能够正常处理请求，目的是及时识别不可用的服务器并将流量重新分配。健康检查有两种方式：
+健康检查用于评估后端服务器是否能够正常处理请求，识别不可用的服务器并将流量重新分配。健康检查有两种方式：
 
 - **主动健康检查**：负载均衡器定期向后端发送健康探测请求，根据响应状态判断后端服务器是否健康。例如，某些七层负载均衡器会请求特定的健康检查路径（如 /health 或 /status），通过 HTTP 状态码来判断后端服务的健康状态。
 - **被动健康检查**：负载均衡器通过持续监控请求、响应和连接的状态，分析异常情况来判断后端服务器的健康状态。如果在一段时间内发现某个后端出现多次连接失败或超时等问题，负载均衡器会将该后端标记为不健康。
@@ -24,7 +24,7 @@
 
 会话的定义因业务而异，可能基于 HTTP cookies、客户端地址、请求头或其他相关属性来确定。大部分七层负载均衡器支持通过配置 HTTP cookies 或 IP 哈希来实现“粘性会话”（sticky session）。
 
-值得注意的是，粘性会话涉及缓存、临时状态管理，实现粘性会话的设计通常很脆弱（赖于特定服务器、无法动态扩展、不可预测的负载分配问题等）。一旦处理会话的后端出现故障，整个服务都会受到影响。因此，设计依赖于该特性的系统时，需要格外谨慎！
+值得注意的是，粘性会话涉及缓存、临时状态管理，实现粘性会话的设计通常很脆弱（赖于特定服务器、无法动态扩展、不可预测的负载分配问题等）。一旦处理会话的后端出现故障，整个服务都会受到影响。因此，设计具有该特性的系统时，需要格外谨慎！
 
 ## 6.2.4 TLS 卸载
 
@@ -36,9 +36,11 @@ TLS 卸载（TLS Termination）是指将 TLS 加密/解密、证书管理等操
 
 ## 6.2.5 安全和 DDoS 防御
 
-负载均衡器可以实现 IP 黑/白名单、请求限速和鉴权等功能。根据 IP 的访问流量实现 QoS 控制，保证高优先级请求的响应时间，同时限制低优先级请求的频率，确保系统资源得到合理分配。
+作为集群的唯一入口，负载均衡器不仅是流量的调度中心，也是系统安全的第一道防线。
 
-此外，通过稍后介绍的边缘代理的拓扑，即不同地理位置部署多个边缘代理，在靠近用户的位置分散流量，不仅能减少延迟，对于防御 DDos 攻击也尤其有效。
+负载均衡器可以作为访问控制点，拦截来自不受信任的来源的请求，防止恶意流量进入内部系统。此外，负载均衡器可以通过部署 IP 黑/白名单、流量限速、请求鉴权等功能，强化对外部攻击的防护能力。
+
+另一方面，负载均衡器通过支持高级安全功能（如 SSL/TLS 终端加密和 Web 应用防火墙）进一步增强了系统的安全性。在面临 DDoS 攻击时，负载均衡器能够通过流量分散、智能限速等手段，有效减轻攻击压力，保护内部资源不受影响。
 
 ## 6.2.6 可观测性
 
@@ -51,7 +53,7 @@ TLS 卸载（TLS Termination）是指将 TLS 加密/解密、证书管理等操
 
 ## 6.2.7 负载均衡
 
-负载均衡解决的是：“给到一组健康的后端，选择谁来处理用户请求？”，也就是负载均衡器所采用的调度算法。
+负载均衡器字面意思是，给到一组健康的后端，选择谁来处理用户请求？也就是负载均衡器的调度算法。
 
 负载均衡调度算法是一个相对活跃的研究领域，从简单的随机选择，到更复杂的考虑各种延迟和后端负载状态的算法，笔者无法逐一展开，这里仅从功能和应用的角度简要介绍一些常见的负载均衡算法。
 

balance/balance-topology.md

@@ -1,62 +1,62 @@
 # 6.3 负载均衡部署拓扑
 
-前面介绍了负载均衡高层概览、四层负载均衡与七层负载均衡的区别，接下来介绍它们的四种部署拓扑。
+本节将介绍四种负载均衡部署拓扑，不同的部署拓扑决定了流量如何被分配、如何实现冗余和高可用性，进而影响系统的性能、可扩展性和容错能力。
 
-## 6.3.1 中间代理型拓扑
-第一种是中间代理型拓扑，如图 6-5 所示。该模式是最常见的负载均衡部署方式，负载均衡器位于客户端与后端服务器之间，负责将请求转发至多个后端服务器。
+## 6.3.1 中间代理型
 
-典型的中间代理型负载均衡产品有：
+第一种是中间代理型部署拓扑，如图 6-5 所示。这是最常见的负载均衡部署方式，负载均衡器位于客户端与后端服务器之间，负责将请求转发至多个后端服务器。
 
-- 硬件设备：Cisco、Juniper、F5 Networks 等公司的产品；
-- 纯软件方案：Nginx、HAProxy、Envoy、Traefik 等；
-- 云软件解决方案：阿里云的 SLB（Server Load Balancer）、AWS 的 ELB（Elastic Load Balancer）、Azure 的 Load Balancer 和 Google Cloud 的 Cloud Load Balancing 等。
+在这种拓扑中，负载均衡器可以分为以下三类：
 
+- 硬件设备：由 Cisco、Juniper、F5 Networks 等公司提供的硬件负载均衡设备；
+- 纯软件：如 Nginx、HAProxy、Envoy 和 Traefik 等开源软件负载均衡器；
+- 云服务：包括阿里云的 SLB（Server Load Balancer）、AWS 的 ELB（Elastic Load Balancer）、Azure 的 Load Balancer 和 Google Cloud 的 Cloud Load Balancing 等云平台提供的负载均衡服务。
 
-总结中间代理型拓扑的优缺点：
-- 优点：配置简单，用户只需通过 DNS 连接到负载均衡器，无需关注其他细节；
-- 缺点：存在单点故障风险，尤其在负载均衡器采用集中式设计时。出现故障会导致整个系统无法访问。
+总结中间代理型优缺点：
+- 优点：配置简便，用户只需通过 DNS 连接到负载均衡器，无需关心后端细节，使用体验简单直观；
+- 缺点：存在单点故障的风险，负载均衡器一旦出现故障，会导致整个系统无法访问。
 
 :::center
   ![](../assets/balancer.svg)<br/>
- 图 6-5 中间代理型负载均衡拓扑
+ 图 6-5 中间代理型
 :::
 
-## 6.3.2 边缘代理型拓扑
+## 6.3.2 边缘代理型
 
-第二种边缘代理型拓扑实际上是中间代理型拓扑的一种变种。
+边缘代理型实际上是中间代理型拓扑的一个变种。
 
 一个典型的边缘代理示例是本书第二章 2.7 节中提到的动态请求‘加速’技术。Akamai 在全球多个数据中心部署边缘节点，这些节点具备代理功能，用户请求会被路由至最近的节点。收到请求后，边缘节点会执行安全检查（如 DDoS 防护），根据缓存策略决定是返回缓存内容（CDN 技术），或者将请求转发至源服务器（请求加速技术）。
 
-总结边缘代理型拓扑的优缺点：
+总结边缘代理型优缺点：
 - 优点：通过将负载均衡、缓存和安全策略集中在网络边缘，边缘代理显著降低延迟、提高响应速度，并增强安全性（如 DDoS 防护）；
 - 缺点：虽然边缘代理减少了单点故障的风险，但若某个边缘节点发生故障，仍会影响到该节点服务的用户。
 
 :::center
   ![](../assets/balancer-edge-proxy.svg)<br/>
- 图 6-6 网络边缘型负载均衡拓扑
+ 图 6-6 网络边缘型
 :::
 
 ## 6.3.3 客户端内嵌
 
-为解决中间代理型拓扑的单点故障问题，出现了更复杂的解决方案，其中之一是将负载均衡器以 SDK 库形式嵌入客户端（如图 4-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 客户端内嵌库实现负载均衡
+ 图 6-7 客户端内嵌型
 :::
 
-## 6.3.4 边车代理型拓扑
+## 6.3.4 边车代理型
 
-客户端内嵌的一个变种是“边车代理”（SideCar）型拓扑。这种拓扑近年来在微服务架构中变得非常流行，并被称为“服务网格”（ServiceMesh）。
+边车代理型拓扑近年来在微服务架构中得到广泛应用，并发展成为一种被称为“服务网格”（Service Mesh）的架构模式。
 
-边车代理的基本原理是，将请求转发到另一个进程，通过牺牲少量性能来实现客户端内嵌库模式的优势，同时避免编程语言绑定的问题。目前，像 Envoy、Linkerd 等网络型边车代理在业内广泛应用。关于服务网格的技术原理，笔者将在第八章详细介绍。
+边车代理的基本原理是在应用容器或服务旁边部署一个独立的代理容器，用于实现请求的负载均衡和流量管理。目前，像 Envoy 和 Linkerd 等网络型边车代理已被广泛应用。关于服务网格的技术原理，笔者将在第八章中进行详细阐述。
 
 :::center
   ![](../assets/balancer-sidecar.svg)<br/>
- 图 6-8 边车代理实现负载均衡
+ 图 6-8 边车代理型
 :::
 
-总体而言，中间代理型负载均衡器正在演变为功能更强大的‘网关’，所有请求通过唯一入口（即网关）进入集群。在这种架构中，负载均衡器作为网关，不仅负责基本的请求转发，还承担更高层次的请求管理与安全控制，如 TLS 卸载、请求限制、身份验证和复杂内容路由等。另一方面，针对东西向流量（服务间通信），边车代理模式将代理部署在服务实例旁边，透明地接管服务间通信治理，正逐渐取代其他拓扑类型。
+总体而言，中间代理型负载均衡器正逐步演变为功能更强大的“网关”，所有请求通过单一入口（即网关）进入集群。在这种架构下，负载均衡器作为网关，不仅负责基本的请求转发，还承担更高级的请求管理与安全控制，包括 TLS 卸载、请求限制、身份验证和复杂内容路由等。同时，针对东西向流量（即服务间通信），边车代理模式“透明”地接管了服务间的通信治理，正逐渐成为主流选择。

balance/balance.md

@@ -2,7 +2,7 @@
 
 在讨论负载均衡时，"负载均衡器"（Load Balancer）和"代理"（Proxy）这两个术语常被混用。严格来说，并非所有代理都属于负载均衡器，但大多数代理的核心功能都涵盖负载均衡。为了简化表述，本文将这两个术语视为大致等同，不作严格区分。
 
-图 6-1 展示了客户端（Client）的请求通过负载均衡器（Load Balancer）转发至某个后端服务器（Backend）。从整体架构来看，负载均衡器作为核心组件，主要承担以下职责：
+图 6-1 展示了负载均衡高层架构图，客户端（Client）的请求通过负载均衡器（Load Balancer）转发至某个后端服务器（Backend）。从整体架构来看，负载均衡器承担以下职责：
 
 - **服务发现**：识别系统中可用的后端服务器，并获取它们的地址，以便与后端进行通信。
 - **健康检查**：监测后端服务器的状态，确保只有健康的服务器能够接收请求。