更新内容

balance/balance-features.md

@@ -5,7 +5,7 @@
 
 ## 4.2.1 服务发现
 
-服务发现是负载均衡器用来识别可用后端的机制。不同的服务发现实现方式差异较大，以下是几种常见的实现方式：
+服务发现是负载均衡器识别有哪些后端服务器的机制。不同的服务发现实现方式差异较大，以下是几种常见的实现方式：
 
 - **静态配置文件**：通过手动维护后端服务器配置实现基础的服务发现。
 - **DNS**：将后端服务器的 IP 地址通过 SRV 记录或 A 记录注册到 DNS 服务器，客户端通过查询 DNS 记录获取后端服务器 IP 地址。
@@ -38,7 +38,7 @@ TLS 卸载（TLS Termination）指将 TLS 的加密/解密、证书管理等操
 
 负载均衡器可以实现 IP 黑/白名单、请求限速和鉴权等功能。根据 IP 的访问流量实现 QoS 控制，保证高优先级请求的响应时间，同时限制低优先级请求的频率，确保系统资源得到合理分配。
 
-此外，通过稍后介绍的边缘代理的拓扑，即不同地理位置部署多个边缘代理，在靠近用户的位置分散流量，不仅能减少延迟，而且对于防御 DDos 攻击尤其有效。
+此外，通过稍后介绍的边缘代理的拓扑，即不同地理位置部署多个边缘代理，在靠近用户的位置分散流量，能减少延迟，对于防御 DDos 攻击尤其有效。
 
 
 ## 4.2.6 可观测性

balance/balance-topology.md

@@ -6,51 +6,55 @@
 下面介绍的每种拓扑都适用于四层和七层负载均衡器。
 :::
 
-第一种类型为中间代理拓扑，如图 4-2 所示。这应该是大家最熟悉的负载均衡方式，负载均衡器位于客户端和后端服务器之间，负责分发流量到多个后端实例（realserver）。
+第一种类型为中间代理型拓扑，如图 4-2 所示。这应该是大家最熟悉负载均衡部署模式，负载均衡器位于客户端和后端服务器之间，将客户端的请求转发至多个后端服务器。
 
-典型的中间代理拓扑的方案有：
+部分明显具有中间代理拓扑特征的负载均衡产品有：
 
 - 硬件设备：Cisco、Juniper、F5 Networks 等公司的产品。
 - 云软件解决方案：阿里云的 SLB（Server Load Balancer），AWS 的 ELB（Elastic Load Balancer）、Azure 的 Load Balancer 和 Google Cloud 的 Cloud Load Balancing 等。
-- 纯软件方案：Nginx、HAProxy、Envoy 等。
+- 纯软件方案：Nginx、HAProxy、Envoy、Traefik 等。
 
-总结中间代理模式的优缺点是：
+总结中间代理型拓扑的优缺点：
  - 优点是，配置简单，**用户只需通过 DNS 连接到负载均衡器，无需关注其他细节**。
- - 缺点是，**中间代理可能存在单点故障风险**，尤其是负载均衡这种集中式的设计，如果负载均衡器出现问题，会导致整个系统的访问中断。
+ - 缺点是，**中间代理存在单点故障风险**，尤其是负载均衡这种集中式的设计，如果负载均衡器出现问题，将导致整个系统的访问中断。
 
 :::center
   ![](../assets/balancer.svg)<br/>
- 图 4-2 中间代理负载均衡拓扑
+ 图 4-2 中间代理型负载均衡拓扑
 :::
 
 
-第二种边缘代理拓扑实际上是中间代理拓扑的一个变种。
+第二种边缘代理型拓扑实际上是中间代理型拓扑变种。
 
-一个具体的边缘代理例子是：本书第二章 2.7 节提到的的动态请求“加速”技术。Aakamai 的服务部署在全球多个数据中心，用户的请求首先到达最近的 Aakamai 边缘节点，Aakamai 边缘节点接收请求后，进行安全性检查（如 DDoS 防护），并根据缓存策略决定是否直接提供缓存内容或将请求转发到源服务器。
+一个具体的边缘代理示例是本书第二章 2.7 节中提到的动态请求“加速”技术。Akamai 的服务部署在全球多个数据中心，用户的请求被路由至距离最近的 Akamai 边缘节点。边缘节点接收请求后，进行安全检查（如 DDoS 防护），根据缓存策略决定是否返回缓存内容，或将请求继续转发至源服务器。
 
-总结边缘代理模式的优缺点是：
+总结边缘代理型拓扑的优缺点：
  - 优点是，将负载均衡逻辑（还有缓存、安全策略等）集中在网络边缘，能够显著减少延迟，提高网站的响应速度，增强安全性（预防 DDos）；
  - 缺点是，虽然边缘代理可以减少单点故障，但如果某个边缘节点出现问题，仍会影响到该节点所服务的用户。
 
 :::center
   ![](../assets/balancer-edge-proxy.svg)<br/>
- 图 4-3 网络边缘负载均衡拓扑
+ 图 4-3 网络边缘型负载均衡拓扑
 :::
 
-为了解决中间代理拓扑模式的单点故障和扩展问题，出现了一些更复杂的解决方案。如将负载均衡器以 SDK 库的形式嵌入到客户端（如图 4-4 所示）。熟悉微服务开发的读者肯定知晓 Finagle、Eureka、Ribbon 和 Hystrix 等微服务治理方案。虽然这些库特性各异，但还是能总结出它们的共同优缺点：
-- 优点是，将负载均衡器的功能完全下沉至客户端，从而避免了单点故障和扩展问题；
-- 缺点是，必须为项目使用的每种开发语言实现相应的 SDK ，当项目非常复杂时，处理版本依赖等兼容问题时将非常棘手（本书第八章 8.2 节详细阐述了微服务框架的痛点，可阅读本节进一步了解）。
+为解决中间代理型拓扑模式的单点问题，出现了一些更复杂的解决方案。如将负载均衡器以 SDK 库的形式嵌入客户端内部（图 4-4 所示）。SDK 库就是大家熟知的 Finagle、Eureka、Ribbon 和 Hystrix 等微服务治理方案。
+
+虽然这些库功能各异，但还是能总结出它们的共同优缺点：
+- 优点是，将负载均衡器的功能完全下沉至客户端，避免了单点故障问题；
+- 缺点是，每一种编程语言都要实现相应的 SDK 。且当项目非常复杂时，处理版本依赖等兼容问题将非常棘手（本书第八章 8.2 节详细阐述了微服务框架的痛点，可阅读本节进一步了解）。
 
 :::center
   ![](../assets/balancer-sdk.svg)<br/>
  图 4-4 客户端内嵌库实现负载均衡
 :::
 
-客户端内嵌库拓扑的一个变种是**Sidecar 拓扑**。近年来这种拓扑非常流行，被称为服务网格（service mesh）。Sidecar 代理模式背后的思想是：将流量导到另一个进程，牺牲一点（延迟）性能，实现客户端内嵌库模式的所有好处，而无任何语言绑定。当下，最流行的 Sidecar 代理有 Envoy、Linkerd，笔者将第八章详细阐述服务网格的模式的原理。
+客户端内嵌库的一个变种是边车代理（sidecar）型拓扑。
+
+近年来边车型代理拓扑非常流行，被称为服务网格（service mesh）。边车代理模式核心思路是：将流量导到另一个进程，牺牲一点（延迟）性能，实现客户端内嵌库模式的所有好处，而无任何语言绑定。当下，最流行的网络型边车代理有 Envoy、Linkerd 等，笔者将第八章详细阐述服务网格的技术原理。
 
 :::center
   ![](../assets/balancer-sidecar.svg)<br/>
  图 4-5 Sidecar 代理实现负载均衡
 :::
 
-总体上讲，中间代理类型正在演变为功能更为强大的“网关”，所有请求通过唯一的网关进入系统。在这种架构中，负载均衡器不仅需要执行基本的流量分发功能，还需提供额外的“API 网关”功能，如 TLS 卸载、流量限制、身份验证，以及复杂的流量路由等。另一方面，在处理东西向流量（服务间通信）的场景中，Sidecar 模式通过将代理部署在每个服务实例旁边，实现透明的流量管理、监控和安全功能，正逐渐取代其他所有的拓扑类型。
+总体上讲，中间代理型的负载均衡器正在演变成功能更为强大的“网关”，所有请求通过唯一的入口（即网关）进入集群。这种架构中，负载均衡器不仅负责基本的流量分发功能，还需提供额外的“API 网关”功能，如 TLS 卸载、流量限制、身份验证，以及复杂的内容路由等。另一方面，在处理东西向流量（服务间通信）的场景中，边车代理模式将代理部署在服务实例旁边，透明接管服务间通信治理，正逐渐取代其他所有的拓扑类型。

http/dns-ha.md

@@ -1,6 +1,6 @@
 # 2.3.3 Facebook 故障分析与总结
 
-Facebook 史诗级故障事件发生在 2021 年 10 月 4 日，故障绕过了所有的高可用设计，让 Facebook 公司旗下的 Facebook、Instagram、WhatsApp 等众多服务出现了长达接近 7 个小时宕机。这次故障的影响范围极广，差点导产生严重的二次故障，险些搞崩整个互联网。
+Facebook 史诗级故障事件发生在 2021 年 10 月 4 日，故障绕过了所有的高可用设计，让 Facebook 公司旗下的 Facebook、Instagram、WhatsApp 等众多服务出现了长达接近 7 个小时宕机。这次故障的影响范围极广，差点导致严重的二次故障，险些搞崩整个互联网。
 
 如此大规模服务的瘫痪不是 DNS 就是 BGP 出了问题。Facebook 很倒霉，这次故障是因为 DNS 和 BGP 一起出现了问题。