fix typo

Observability/signals.md

@@ -2,15 +2,15 @@
 
 业界将系统输出的数据总结为三种独立的类型，它们的含义与区别如下：
 
-- **指标（metric）**：量化系统性能和状态的“数据点”，每个数据点包含度量对象（如接口请求数）、度量值（如 100 次/秒）和发生的时间，多个时间上连续的数据点便可以分析系统性能的趋势和变化规律。指标是发现问题的起点，例如你半夜收到一条告警：“12 点 22 分，接口请求成功率下降到 10%”，这表明系统出现了问题。接着，你挣扎起床，分析链路追踪和日志数据，找到问题的根本原因并进行修复。
+- **指标**（metric）：量化系统性能和状态的“数据点”，每个数据点包含度量对象（如接口请求数）、度量值（如 100 次/秒）和发生的时间，多个时间上连续的数据点便可以分析系统性能的趋势和变化规律。指标是发现问题的起点，例如你半夜收到一条告警：“12 点 22 分，接口请求成功率下降到 10%”，这表明系统出现了问题。接着，你挣扎起床，分析链路追踪和日志数据，找到问题的根本原因并进行修复。
 
-- **日志（log）**：系统运行过程中，记录离散事件的文本数据。每条日志详细描述了事件操作对象、操作结果、操作时间等信息。例如下面的日志示例，包含时间、日志级别（ERROR）以及事件描述。
+- **日志**（log）：系统运行过程中，记录离散事件的文本数据。每条日志详细描述了事件操作对象、操作结果、操作时间等信息。例如下面的日志示例，包含了时间、日志级别（ERROR）以及事件描述。
 ```bash
 [2024-12-27 14:35:22] ERROR: Failed to connect to database. Retry attempts exceeded.
 ```
 日志为问题诊断提供了精准的上下文信息，与指标形成互补。当系统故障时，“指标”告诉你应用程序出现了问题，“日志”则解释了问题出现的原因。
 
-- **链路追踪（trace）**：记录请求在多个服务之间的“调用链路”（Trace），以“追踪树”（Trace Tree）的形式呈现请求的“调用”（span）、耗时分布等信息。
+- **链路追踪**（trace）：记录请求在多个服务之间的“调用链路”（Trace），以“追踪树”（Trace Tree）的形式呈现请求的“调用”（span）、耗时分布等信息。
 
 ```bash
 // 追踪树
@@ -20,7 +20,7 @@ Trace ID: 12345
         └── Span ID: 3 - Database Service (Duration: 20ms)
 ```
 
-上述 3 类数据各自侧重不同，但并非孤立存在，它们之间有着天然的交集与互补，比如指标监控（告警）帮助发现问题，日志和链路追踪则帮助定位根本原因。这三者之间的关系如图 9-2 的韦恩图所示。
+上述 3 类数据各自侧重不同，但并非孤立存在，它们之间有着天然的交集与互补。比如指标监控（告警）帮助发现问题，日志和链路追踪则帮助定位根本原因。这三者之间的关系如图 9-2 的韦恩图所示。
 
 :::center
   ![](../assets/observability.jpg)<br/>

balance/balance-topology.md

@@ -3,30 +3,33 @@
 前面介绍了负载均衡高层概览、四层负载均衡与七层负载均衡的区别，接下来介绍它们的四种部署拓扑。
 
 ## 4.3.1 中间代理型拓扑
-第一种是中间代理型拓扑，如图 4-5 所示。这是最常见的负载均衡部署模式，负载均衡器位于客户端和后端服务器之间，负责将客户端的请求转发至多个后端服务器。具有中间代理拓扑特征的负载均衡产品包括：
+第一种是中间代理型拓扑，如图 4-5 所示。该模式是最常见的负载均衡部署方式，负载均衡器位于客户端与后端服务器之间，负责将请求转发至多个后端服务器。
 
-- 硬件设备：Cisco、Juniper、F5 Networks 等公司的产品。
-- 纯软件方案：Nginx、HAProxy、Envoy、Traefik 等。
+典型的中间代理型负载均衡产品有：
+
+- 硬件设备：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/>
  图 4-5 中间代理型负载均衡拓扑
 :::
 
 ## 4.3.2 边缘代理型拓扑
+
 第二种边缘代理型拓扑实际上是中间代理型拓扑的一种变种。
 
-一个典型的边缘代理示例是在本书第二章 2.7 节中提到的动态请求“加速”技术。Akamai 在全球多个数据中心部署了多个具有代理功能的边缘节点，用户的请求会被路由至距离最近的边缘节点。边缘节点收到请求后，会执行安全检查（如 DDoS 防护），根据缓存策略决定是否返回缓存内容（CDN 技术），或者将请求继续转发至源服务器（请求加速技术）。
+一个典型的边缘代理示例是本书第二章 2.7 节中提到的动态请求‘加速’技术。Akamai 在全球多个数据中心部署边缘节点，这些节点具备代理功能，用户请求会被路由至最近的节点。收到请求后，边缘节点会执行安全检查（如 DDoS 防护），根据缓存策略决定是返回缓存内容（CDN 技术），或者将请求转发至源服务器（请求加速技术）。
 
 总结边缘代理型拓扑的优缺点：
-- 优点：将负载均衡逻辑、缓存、安全策略等集中在网络边缘，能够显著减少延迟，提高响应速度，并增强安全性（如 DDoS 防护）。
-- 缺点：尽管边缘代理能够减少单点故障问题，但若某个边缘节点发生故障，仍会影响到该节点所服务的用户。
+- 优点：通过将负载均衡、缓存和安全策略集中在网络边缘，边缘代理显著降低延迟、提高响应速度，并增强安全性（如 DDoS 防护）；
+- 缺点：虽然边缘代理减少了单点故障的风险，但若某个边缘节点发生故障，仍会影响到该节点服务的用户。
 
 :::center
   ![](../assets/balancer-edge-proxy.svg)<br/>
@@ -35,10 +38,10 @@
 
 ## 4.3.3 客户端内嵌
 
-为了解决中间代理型拓扑模式的单点故障问题，出现了更为复杂的解决方案，其中之一是将负载均衡器以 SDK 库的形式嵌入客户端（如图 4-7 所示）。这些 SDK 库包括常见的微服务治理方案，如 Finagle、Eureka、Ribbon 和 Hystrix 等。尽管这些库的功能各有不同，但仍可以总结出它们的共同优缺点：
+为解决中间代理型拓扑的单点故障问题，出现了更为复杂的解决方案，其中之一是将负载均衡器以 SDK 库形式嵌入客户端（如图 4-7 所示）。这些 SDK 库包括常见的微服务治理方案，如 Finagle、Eureka、Ribbon 和 Hystrix 等。尽管功能各异，这些库有一些共同的优缺点：
 
-- 优点：将负载均衡器的功能完全下沉至客户端，避免了单点故障问题。
-- 缺点：每种编程语言都需要实现相应的 SDK，而且在项目复杂时，处理版本依赖和兼容性问题将变得非常棘手（微服务框架的相关痛点将在本书第八章 8.2 节中详细讨论，读者可参考本节进一步了解）。
+- 优点：将负载均衡器功能“转移”至客户端，避免了单点故障问题；
+- 缺点：需要为每种编程语言实现相应的 SDK，且在项目复杂时，处理版本依赖和兼容性问题变得棘手（微服务框架的相关问题将在本书第八章 8.2 节中详细讨论，读者可参考进一步了解）。
 
 :::center
   ![](../assets/balancer-sdk.svg)<br/>
@@ -47,13 +50,13 @@
 
 ## 4.3.4 边车代理型拓扑
 
-客户端内嵌的一个变种是“边车代理”（sidecar）型拓扑。近年来这一拓扑在微服务架构中变得非常流行，并被称为“服务网格”（service mesh）。
+客户端内嵌的一个变种是“边车代理”（SideCar）型拓扑。这种拓扑近年来在微服务架构中变得非常流行，并被称为“服务网格”（ServiceMesh）。
 
-边车代理的核心思想是将流量转发到另一个进程，通过牺牲少量性能（如延迟），实现客户端内嵌库模式的所有优势，同时避免了语言绑定的问题。目前，像 Envoy、Linkerd 等网络型边车代理广泛应用。有关服务网格的技术原理，笔者将在第八章进行详细介绍。
+边车代理的基本原理是，将请求转发到另一个进程，通过牺牲少量性能来实现客户端内嵌库模式的优势，同时避免编程语言绑定的问题。目前，像 Envoy、Linkerd 等网络型边车代理在业内广泛应用。关于服务网格的技术原理，笔者将在第八章详细介绍。
 
 :::center
   ![](../assets/balancer-sidecar.svg)<br/>
- 图 4-8 Sidecar 代理实现负载均衡
+ 图 4-8 边车代理实现负载均衡
 :::
 
-总体上讲，中间代理型的负载均衡器正在演变成功能更为强大的“网关”，所有请求通过唯一的入口（即网关）进入集群。这种架构中，作为网关的负载均衡器不仅负责基本的请求转发功能，还负责更高层次的请求管理与安全控制，如 TLS 卸载、请求限制、身份验证，以及复杂的内容路由等。另一方面，针对东西向流量（即服务间通信）的场景，边车代理模式通过将代理部署在服务实例旁边，透明地接管服务间的通信治理，正逐渐取代其他所有的拓扑类型。
+总体而言，中间代理型负载均衡器正在演变为功能更强大的‘网关’，所有请求通过唯一入口（即网关）进入集群。在这种架构中，负载均衡器作为网关，不仅负责基本的请求转发，还承担更高层次的请求管理与安全控制，如 TLS 卸载、请求限制、身份验证和复杂内容路由等。另一方面，针对东西向流量（服务间通信），边车代理模式将代理部署在服务实例旁边，透明地接管服务间通信治理，正逐渐取代其他拓扑类型。

http/latency.md

@@ -43,7 +43,7 @@ $ cat curl-format.txt
 表 2-2 curl 支持的与请求延迟有关的变量
 :::
 
-| 变量名称 | 变量释义 |
+| 变量名称 | 说明 |
 |:--|:--|
 | time_namelookup | 从请求开始到域名解析完成的耗时 |
 | time_connect | 从请求开始到 TCP 三次握手完成的耗时 |