更新负载均衡器

balance/balance-features.md

@@ -1,36 +1,38 @@
 # 4.2 负载均衡器特性
 
 
-现代负载均衡器承担的职责已经远远超出了最初的目标。本节简要介绍负载均衡器能做的事情，以便读者有个总体性的认识。
+现代负载均衡器的职责已经远超其最初的设计目标。本节将简要介绍负载均衡器常见的功能，帮助读者有个总体性的认识。
 
 ## 4.2.1 服务发现
 
-服务发现是负载均衡器判断它有哪些可用后端的机制。不同系统实现服务发现的差异很大，以下是几种常见的实现方式：
+服务发现是负载均衡器用来识别可用后端的机制。不同的服务发现实现方式差异较大，以下是几种常见的实现方式：
 
-- **静态配置文件**：通过手动维护后端列表实现最初级的服务发现。
-- **DNS**：服务实例通过 SRV 记录或 A 记录注册到 DNS 服务器，客户端查询 DNS 记录获取服务的地址信息。
-- **Zookeeper、Etcd、Consul 等服务注册中心**：服务实例在启动时向这些系统注册服务名称、地址、端口和健康检查信息。客户端通过相应的查询 API 获取服务信息。此类方案一般内置健康检查机制，能够定期检查服务实例的健康状态，并根据检查结果自动更新服务状态。
-- **Envoy 的通用数据平面 API**：提供一种标准化的数据平面接口（xDS 协议），实现跨平台、跨环境的服务发现和负载均衡能力（参考本书第八章 8.3 节内容）。
+- **静态配置文件**：通过手动维护后端服务器配置实现基础的服务发现。
+- **DNS**：将后端服务器的 IP 地址通过 SRV 记录或 A 记录注册到 DNS 服务器，客户端通过查询 DNS 记录获取后端服务器 IP 地址。
+- **服务注册中心**（如 Zookeeper、Etcd、Consul 等）：后端服务器启动时向这些系统注册服务名称、地址、端口及健康检查信息。客户端通过查询 API 获取服务信息。这类方案通常内置健康检查机制，定期检测服务状态，并根据结果自动更新服务列表。
+- **Envoy 通用数据平面 API**：提供标准化的数据平面接口（xDS 协议），实现跨平台和跨环境的服务发现（详见本书第八章 8.3 节）。
 
 ## 4.2.2 健康检查
 
-健康检查用于判断后端服务器是否能正常处理请求，目的是及时识别不可用的后端并重新分配流量。其机制主要分为主动检查和被动检查两类。
+健康检查用于评估后端服务器是否能够正常处理请求，目的是及时识别不可用的服务器并将流量重新分配。健康检查有两种手段：
 
-- **主动健康检查**：负载均衡器定期向后端发送健康探测，通过响应状态来判断后端是否健康。如，七层负载均衡器通过发送 HTTP 请求到特定的健康检查路径（如 /health 或 /status），判断 HTTP 状态码是否为 200 或其他预期的状态。
-- **被动健康检查**：被动健康检查不需要负载均衡器主动发送探测请求，而是基于日常数据流监控后端服务器的状态。如，四层负载均衡中，如果在一定时间内发现某个后端出现多次连接失败、超时等异常，则负载均衡器可能标记该后端为不健康。七层负载均衡中，如果某个后端返回的 HTTP 状态码频繁出现错误（如 5xx 系列状态码），负载均衡器会视其为不健康。
+- **主动健康检查**：负载均衡器定期向后端发送健康探测，根据响应状态判断后端是否健康。如七层负载均衡器请求特定的健康检查路径（如 /health 或 /status），根据 HTTP 状态码判断后端服务健康状态。
+- **被动健康检查**：通过持续收集和分析请求、响应以及连接的状态信息，来判断后端服务器的状态。如在一段时间内发现某个后端出现多次连接失败、超时等异常，负载均衡器标记该后端为不健康。
 
 ## 4.2.3 粘性会话
 
-对于某些特定应用，确保属于同一会话的请求被路由到相同的后端服务器至关重要。会话的定义因应用而异，可能包括 HTTP cookies、客户端连接特性或其他相关属性。大部分的七层负载均衡器，支持配置 HTTP cookies 或 IP 哈希实现粘性会话（sticky session）。
+对于某些特定应用，确保属于同一会话的请求被路由到相同的后端服务器至关重要。
 
-需要注意的是，粘性会话涉及缓存和复杂的临时状态管理，它的设计本质上是脆弱的（赖于特定服务器、无法动态扩展、不可预测的负载分配问题等），一旦处理会话的后端出现故障，整个机制可能会受到影响。因此，设计依赖于该特性的系统时，需要格外谨慎。
+会话的定义因应用而异，可能根据 HTTP cookies、客户端地址、请求头或其他相关属性来定义。大部分七层负载均衡器支持通过配置 HTTP cookies 或 IP 哈希来实现粘性会话（sticky session）。
+
+需要注意的是，粘性会话涉及缓存和复杂的临时状态管理，实现粘性会话的设计通常很脆弱（赖于特定服务器、无法动态扩展、不可预测的负载分配问题等）。一旦处理会话的后端出现故障，整个服务可能都会受到影响。因此，设计依赖于该特性的系统时，需要格外谨慎。
 
 ## 4.2.4 TLS 卸载
 
 TLS 卸载（TLS Termination）指将 TLS 的加密/解密、证书管理等操作，由负载均衡器进行统一收敛处理。这样的好处是：
 - **减轻后端负载**：后端服务器无需处理加密/解密操作，可以专注于业务逻辑处理。
 - **减少运维负担**：负载均衡器统一管理 SSL 证书的配置和更新，避免每个后端服务器单独管理证书。
-- **提升请求效率**：负载均衡器通常具有强大的硬件加速能力，经过了大量调优，可以快速处理 TLS 连接，从而降低 HTTPS 请求延迟（参考本书第二章 2.5.2 节内容）。
+- **提升请求效率**：负载均衡器通常具有强大的硬件加速能力，经过了大量调优，处理 TLS 连接更有优势（参考本书第二章 2.5.2 节内容）。
 
 ## 4.2.5 安全和 DDoS 防御
 
@@ -41,14 +43,12 @@ TLS 卸载（TLS Termination）指将 TLS 的加密/解密、证书管理等操
 
 ## 4.2.6 可观测性
 
-网络本质上是不可靠的，负载均衡器通常需要导出请求统计、跟踪和日志等信息，以帮助运维人员识别和修复问题。
-
-负载均衡器输出的可观测性数据差异很大，从基本的统计信息（如流量、连接数和错误率）到与微服务架构集成的调用链追踪，功能各异：
+从基本的统计信息（如流量、连接数和错误率）到与微服务架构集成的调用链追踪，不同层次的负载均衡器输出的可观测性数据各异：
 
-- 四层负载均衡器的可观测性数据主要集中在连接、流量、错误、延迟等网络层面的统计。
-- 七层负载均衡器则能够提供更为丰富的应用层数据，包括 HTTP 请求的详细分析、错误码、会话保持、路由分配、用户行为分析等。
+- 四层负载均衡器的观测数据集中在连接、流量、错误、延迟等网络层面的分析。
+- 七层负载均衡器的观测数据集中在 HTTP 请求、错误码、会话保持、路由分配等应用层面的分析。
 
-需要注意的是，支持可观测性并非没有代价，负载均衡器需要进行额外处理来生成这些数据，但所带来的收益远超过由此引起的性能损失。
+需要注意的是，输出可观测性数据并非没有代价，负载均衡器需要进行额外处理来生成这些数据，但所带来的收益远超过那一点性能损失。
 
 ## 4.2.7 负载均衡
 
@@ -70,4 +70,4 @@ TLS 卸载（TLS Termination）指将 TLS 的加密/解密、证书管理等操
 
 考虑各个服务器的处理能力存在差异，负载均衡算法又有了对服务器“**加权**”的补充。
 
-加权负载均衡算法增加了按权值高低分配的机制，权重较高的服务器处理更多的连接，从而保证服务器集群整体处于均衡状态。常用的加权负载均衡算法包括加权轮询（Weighted Round Robin）、加权最小连接（Weighted Least-Connection）和加权随机（Weighted Random）等，这里不再逐一介绍了。
+加权负载均衡算法增加了按权值高低分配的机制，权重较高的服务器处理更多的连接，从而保证服务器集群整体处于均衡状态。常用的加权负载均衡算法包括加权轮询（Weighted Round Robin）、加权最小连接（Weighted Least-Connection）和加权随机（Weighted Random）等等，笔者就不再逐一介绍了。

balance/balance.md

@@ -62,7 +62,7 @@
 
 随着用户规模扩大，四层负载均衡器面临的“阻抗不匹配”问题将变得更加明显。
 
-不过也不要担心，如计算机领域流传颇广的一句俚语：
+不过也不要担心，计算机领域内有一句流传颇广的俚语：
 
 :::tip <a/> 
 
@@ -78,7 +78,7 @@
 
 七层负载均衡器工作在应用层，意味着它只能通过建立新的传输层连接来将请求代理至后端服务器。
 
-七层负载均衡的工作模式如图 4-4 所示。客户端与七层负载均衡器建立了一个 HTTP/2 TCP 连接，七层负载均衡器则分别与两个业务后端建立连接。当客户端发送 HTTP 请求（stream）时：
+七层负载均衡的工作模式如图 4-4 所示。客户端与七层负载均衡器建立了一个 HTTP/2 连接，七层负载均衡器则分别与两个业务后端建立连接。当客户端发送 HTTP 请求（stream）时：
 - 请求 1（stream1）被代理至第一个后端服务器；
 - 请求 2（stream2）被代理至第二个后端服务器。
 
@@ -87,9 +87,14 @@
   图 4-4 七层负载均衡器新建 TCP 连接至后端服务器
 :::
 
-相比于四层负载均衡器仅基于 IP 和端口的简单流量分发，七层负载均衡器工作在应用层，具备检测和处理应用层内容的能力，能够：
-- 根据 URL、请求方法、Cookie 等应用层信息做出更精细的路由决策；
-- 满足业务需求，支持更多高级功能（如内容缓存、压缩、TLS/SSL 卸载等）。
+七层负载均衡器工作在应用层，具备检测和处理应用层内容的能力。应用层内容包括：
+
+- 可选的 TLS（传输层安全性）：尽管 TLS 的归属层次在网络领域尚有争议，为了讨论的便利，本文假设其属于七层。
+- 物理 HTTP 协议：包括 HTTP/1、HTTP/2、HTTP/3。
+- 逻辑 HTTP 协议：涉及请求的头部、主体和尾部数据。
+- 消息协议：如 gRPC、RESTful API、SOAP、AMQP、MQTT 等。
+
+因此，与仅基于 IP 和端口进行简单流量分发的四层负载均衡器相比，七层负载均衡器能够处理更复杂的功能，如根据 URL、请求方法、Cookie 等应用层信息做出更精细的路由决策，并支持内容缓存、压缩、TLS/SSL 卸载等高级功能。
 
 
 

balance/balance7.md

@@ -1,8 +1,6 @@
 # 4.5 七层负载均衡技术
 
-早期的七层负载均衡器（如 Nginx），使用原始的静态配置手段，提供最基本的请求代理功能。
-
-随着微服务、自动扩缩容等技术的崛起，手动配置的方式越来越难以有效运维。且随着系统越来越动态，也需要七层负载均衡器提供更多的功能。本节简要总结部分代表性七层负载均衡器，介绍它们提供的功能供读者参考。
+早期的七层负载均衡器（如 Nginx），使用原始的静态配置手段，提供最基本的请求代理功能。随着微服务和自动扩缩容等技术的发展，负载均衡器对管理配置的手段和功能的要求日益提高。本节将简要概述一些代表性的七层负载均衡器，介绍它们提供的核心功能，以供读者参考。
 
 根据实现语言以及应用场景来说，业界较流行的七层负载均衡器如表 4-1 所示。