更新负载均衡器

balance/balance-features.md

@@ -1,27 +1,56 @@
 # 4.2 负载均衡器特性
 
 
+现代负载均衡器能做的事情已经远远超出了最初的目标，本节简要介绍负载均衡器能做的事情，以便读者有个总体性的认识。
+
 ## 服务发现
 
-服务发现是负载均衡器判断它有哪些可用后端的过程。服务发现实现的差异很大，以下是几种常见的例子：
+服务发现是负载均衡器判断它有哪些可用后端的机制。不同系统实现服务发现的差异很大，以下是几种常见的实现方式：
 
-- 静态配置文件：通过手动维护后端列表实现简单的服务发现。
-- DNS：利用域名解析系统，动态地将服务请求路由到可用的后端服务器。
-- Zookeeper、Etcd、Consul 等服务注册中心：通过这些分布式协调服务，管理和动态更新后端服务的注册信息。
-- Envoy 的通用数据平面 API：提供一种标准化的数据平面接口，实现跨平台、跨环境的服务发现和负载均衡能力。
+- **静态配置文件**：通过手动维护后端列表实现最初级的服务发现。
+- **DNS**：服务实例通过 SRV 记录或 A 记录注册到 DNS 服务器，客户端查询 DNS 记录获取服务的地址信息。
+- **Zookeeper、Etcd、Consul 等服务注册中心**：服务实例在启动时向这些系统注册服务名称、地址、端口和健康检查信息。客户端通过相应的查询 API 获取服务信息。此类方案一般内置健康检查机制，能够定期检查服务实例的健康状态，并根据检查结果自动更新服务状态。
+- **Envoy 的通用数据平面 API**：提供一种标准化的数据平面接口（xDS 协议），实现跨平台、跨环境的服务发现和负载均衡能力（本书第八章详细介绍）。
 
 ## 健康检查
 
-判断后端是否能够接收请求的过程，主要分为两类：
+健康检查用于判断后端服务器是否能正常处理请求，目的是及时识别不可用的后端并重新分配流量。其机制主要分为主动检查和被动检查两类。
+
+- **主动健康检查**：负载均衡器定期向后端发送健康探测，通过响应状态来判断后端是否健康。如，七层负载均衡器通过发送 HTTP 请求到特定的健康检查路径（如 /health 或 /status），判断 HTTP 状态码是否为 200 或其他预期的状态。
+- **被动健康检查**：被动健康检查不需要负载均衡器主动发送探测请求，而是基于日常数据流监控后端服务器的状态。如，四层负载均衡中，如果在一定时间内发现某个后端出现多次连接失败、超时等异常，则负载均衡器可能标记该后端为不健康。七层负载均衡中，如果某个后端返回的 HTTP 状态码频繁出现错误（如 5xx 系列状态码），负载均衡器会视其为不健康。
+
+## 粘性会话
+
+对于某些特定应用，确保属于同一会话的请求被路由到相同的后端服务器至关重要。会话的定义因应用而异，可能包括 HTTP cookies、客户端连接特性或其他相关属性。大部分的七层负载均衡器，支持配置 HTTP cookies 或 IP 哈希实现粘性会话（sticky session）。
+
+需要注意的是，粘性会话涉及缓存和复杂的临时状态管理，它的设计本质上是脆弱的（赖于特定服务器、无法动态扩展、不可预测的负载分配问题等），一旦处理会话的后端出现故障，整个机制可能会受到影响。因此，设计依赖于该特性的系统时，需要格外谨慎。
+
+## TLS 卸载
+
+TLS 卸载（TLS Termination）指的是 TLS 的解密、证书管理等操作，由负载均衡器进行统一收敛处理。这样的好处是：
+- 减轻后端负载：后端服务器不需要处理解密过程，专注于处理业务逻辑。
+- 减少运维工作：负载均衡器统一处理 SSL 证书的配置和更新，避免在每个后端服务器上单独管理证书。
+- 优化性能：负载均衡器通常具有强大的硬件加速和优化能力，能够快速处理 TLS 连接，减少延迟（参考本书第二章 2.5.2 节内容）。
+
+
+## 安全和 DDoS 防御
+
+负载均衡器可以实现 IP 黑/白名单、请求限速和鉴权等功能。根据 IP 的访问流量实现 QoS 控制，保证高优先级请求的响应时间，同时限制低优先级请求的频率，确保系统资源得到合理分配。
+
+此外，通过稍后介绍的边缘代理的拓扑，即不同地理位置部署多个边缘代理，在靠近用户的位置分散流量，不仅能减少延迟，而且对于防御 DDos 攻击尤其有效。
+
+
+## 可观测性
+
+网络本质上是不可靠的，负载均衡器通常需要导出请求统计、跟踪和日志等信息，以帮助运维人员识别和修复问题。
 
-- 主动健康检查：负载均衡器定期向后端发送健康探测（如向 /healthcheck 发送 HTTP 请求），通过响应状态来判断后端是否健康。
-- 被动健康检查：负载均衡器通过实时数据流监测后端状态。例如，四层负载均衡器可能将三次连接错误视为不健康，七层负载均衡器可能将 503 错误码视为后端不健康的标志。
+负载均衡器输出的可观测性数据差异很大，从基本的统计信息（如流量、连接数和错误率）到与微服务架构集成的调用链追踪，功能各异。需要注意的是，支持可观测性并非没有代价，负载均衡器需要进行额外处理来生成这些数据，但所带来的收益远超过由此引起的性能损失。
 
 ## 负载均衡
 
 负载均衡解决的是：“给到一组健康的后端，选择谁来处理用户请求？”，也就是负载均衡器所采用的调度算法。
 
-负载均衡调度算法是一个相对活跃的研究领域，从简单的随机选择，到更复杂的考虑各种延迟和后端负载状态的算法，笔者无法逐一展开，所以仅从功能和应用的角度简要介绍一些常见的负载均衡算法。
+负载均衡调度算法是一个相对活跃的研究领域，从简单的随机选择，到更复杂的考虑各种延迟和后端负载状态的算法，笔者无法逐一展开，这里仅从功能和应用的角度简要介绍一些常见的负载均衡算法。
 
 - **轮询均衡算法**（Round-Robin）：按依次循环的方式将请求调度到不同的服务器上，该算法最大的特点是实现简单。轮询算法假设所有的服务器处理请求的能力都一样，调度器会将所有的请求平均分配给每个真实服务器。
 

balance/balance-topology.md

@@ -2,7 +2,7 @@
 
 前面介绍了负载均衡高层概览、四层负载均衡与七层负载均衡的区别，接下来介绍它们的分布式部署拓扑，建立对负载均衡的全局性的认识。
 
-:::tip <a/>
+:::tip 注意
 下面介绍的每种拓扑都适用于四层和七层负载均衡器。
 :::
 

balance/balance.md

@@ -2,9 +2,9 @@
 
 业内讨论网络负载均衡器的时候，负载均衡器（load balancer）和代理（proxy）两个术语经常无差别混用。本文继续沿用这种惯例，认为二者整体上是对等的。
 
-:::tip <a/>
+:::tip 注意
 
-严格来讲，不是所有代理都是负载均衡器， 但绝大部分代理的核心功能都包括负载均衡
+严格来讲，不是所有代理都是负载均衡器， 但绝大部分代理的核心功能都包括负载均衡。
 :::
 
 图 4-1 展示了负载均衡的高层架构，客户端（Client）通过负载均衡器（Load Balancer）访问后端服务器（RealServer）。从整体架构来看，中间的负载均衡器承担下述职责：

balance/balance7.md

@@ -26,7 +26,7 @@ OpenResty| 基于 Nginx 和 LuaJIT 的高性能 Web 平台。通过 LuaJIT 引
 	- 控制平面（负责响应式控制）：集中配置和管理数据平面的行为，提供一个统一的接口来定义和修改流量管理策略。
 
 - **流量治理**：在分布式架构中，服务间的通信治理是必不可少的环节，包括超时、重试、限速、熔断、流量镜像和缓存等机制。作为集群的入口，负载均衡器提供统一的收敛处理，从而最大程度降低业务系统的运维成本。
-- **可观测性**：在介绍通用负载均衡器的特性时提到：随着系统的动态性增强，调试难度也随之增加。现代七层负载均衡器最重要的功能之一是提供健全的协议级可观测性。如今，指标、链路追踪和日志等功能几乎已成为七层负载均衡解决方案的标配，如上面提到的 Envoy，支持集成 Prometheus、Grafana、Jaeger 等监控和追踪工具。需要强调的是，支持可观测性并非没有代价，负载均衡器必须进行额外处理才能生成这些数据（但所带来的收益远远超过那点性能损失）。
+- **可观测性**：在介绍通用负载均衡器的特性时提到：随着系统的动态性增强，调试难度也随之增加。现代七层负载均衡器最重要的功能之一是提供健全的协议级可观测性。如今，指标、链路追踪和日志等功能几乎已成为七层负载均衡解决方案的标配，如上面提到的 Envoy，支持集成 Prometheus、Grafana、Jaeger 等监控和追踪工具。
 
 - **可扩展性**：现代七层负载均衡器通常是支持插件化的架构，允许开发者根据需求加载特定的插件或模块。例如 OpenResty，通过 Lua 脚本和第三方插件实现数据缓存、认证授权、安全保护、日志监控等各类自定义功能。
 

network/linux-bridge.md

@@ -1,10 +1,8 @@
 # 3.5.4 虚拟交换机 Linux bridge
 
-在物理网络中，通常通过交换机连接多台主机，组成小型局域网。而在 Linux 网络虚拟化技术中，也提供了交换机的虚拟实现，即 Linux 网桥（Linux bridge）。
+在物理网络中，通常使用交换机连接多台主机，组成小型局域网。在 Linux 网络虚拟化技术中，也提供了物理交换机的虚拟实现，即 Linux 网桥（Linux bridge）。
 
-Linux bridge 作为虚拟交换机，具备与物理交换机相似的功能。当一个或多个网络接口（如物理网卡 eth0、虚拟接口 veth、tap 等）加入到 Linux bridge 后，这些接口的通信方式将与物理交换机的转发行为保持一致。
-
-当一个数据帧进入 Linux bridge 时，它根据数据帧的类型和目的地 MAC 地址，按照如下规则理：
+Linux bridge 作为虚拟交换机，具备与物理交换机相似的功能。当一个或多个网络接口（如物理网卡 eth0、虚拟接口 veth、tap 等）加入到 Linux bridge 后，这些接口的通信方式将与物理交换机的转发行为保持一致。当一个数据帧进入 Linux bridge 时，它根据数据帧的类型和目的地 MAC 地址，按照如下规则处理：
 
 - 如果是广播帧，转发给所有桥接到该 Linux bridge 的设备。
 - 如果是单播帧，查看 FDB（地址转发表）中 MAC 地址与网络设备接口的映射：