fix typo

isno · Jan 26, 2025 · a591b4d · a591b4d
1 parent 6c717dd
commit a591b4d
Show file tree

Hide file tree

Showing 5 changed files with 7 additions and 11 deletions.
diff --git a/Observability/signals.md b/Observability/signals.md
@@ -1,6 +1,6 @@
 # 9.3 遥测数据的分类与处理
 
-业界将系统输出的数据总结为三种独立的类型：指标（metric）、日志（log）和链路追踪（trace），它们的含义与区别如下：
+业界将系统输出的数据总结为三种独立的类型，它们的含义与区别如下：
 
 - **指标（metric）**：量化系统性能和状态的“数据点”，每个数据点包含度量对象（如接口请求数）、度量值（如 100 次/秒）和发生的时间，多个时间上连续的数据点便可以分析系统性能的趋势和变化规律。指标是发现问题的起点，例如你半夜收到一条告警：“12 点 22 分，接口请求成功率下降到 10%”，这表明系统出现了问题。接着，你挣扎起床，分析链路追踪和日志数据，找到问题的根本原因并进行修复。
 

diff --git a/ServiceMesh/MicroService-history.md b/ServiceMesh/MicroService-history.md
@@ -6,7 +6,7 @@
 
 先回到计算机的“远古时代”。
 
-大约 50 年前，初代工程师编写涉及网络的应用程序，需要在业务代码里处理各类网络通信的逻辑。比如要实现可靠连接、超时重传和拥塞控制等功能，这些通信逻辑与业务逻辑毫无关联，但不得不与业务代码混杂在一起实现。
+大约 50 年前，初代工程师编写涉及网络的应用程序，需要在业务代码里处理各类网络通信的逻辑。比如要实现可靠连接、超时重传和拥塞控制等功能，这些功能与业务逻辑毫无关联，但不得不与业务代码混杂在一起实现。
 
 为了解决每个应用程序都要重复实现相似的通信控制逻辑问题，TCP/IP 协议应运而生，它把通信控制逻辑从应用程序中剥离，并将这部分逻辑下沉，成为操作系统网络层的一部分。
 

diff --git a/ServiceMesh/What-is-ServiceMesh.md b/ServiceMesh/What-is-ServiceMesh.md
@@ -1,6 +1,6 @@
 # 8.1 什么是服务网格
 
-2016 年，离开 Twiiter 的工程师 William Morgan 和 Oliver Gould 组建了一个小型技术公司 Buoyant。不久之后，他们在 Github 上发布了创业项目 Linkerd，业界第一款服务网格诞生！
+2016 年，William Morgan 离开 Twiiter，组建了一个小型技术公司 Buoyant。不久之后，他在 Github 上发布了创业项目 Linkerd，业界第一款服务网格诞生！
 
 那么，服务网格到底是什么？服务网格的概念最早由 William Morgan 在其博文《What’s a service mesh? And why do I need one?》中提出。作为服务网格的创造者，引用他的定义无疑是最官方和权威的。
 

diff --git a/container/summary.md b/container/summary.md
@@ -8,11 +8,9 @@
 —— by 计算机科学家 C.A.R. Hoare[^1]
 :::
 
-随着容器化架构大规模应用，手动管理大量容器的方式变得异常艰难。
+随着容器化架构大规模应用，手动管理大量容器的方式变得异常艰难。为了减轻管理容器的心智负担，实现容器调度、扩展、故障恢复等自动化机制，容器编排系统应运而生。
 
-为了减轻管理容器的心智负担，实现容器调度、扩展、故障恢复等自动化机制，容器编排系统应运而生。过去十年间，Kubernetes 发展成为容器编排系统的事实标准，成为大数据分析、机器学习以及在线服务等领域广泛认可的最佳技术底座。
-
-然而，Kubernetes 在解决复杂问题的同时，本身也演变成当今最复杂的软件系统之一。目前，包括官方文档在内的大多数 Kubernetes 资料都聚焦于“怎么做”，鲜有解释“为什么这么做”。自 2015 年起，Google 陆续发布了《Borg, Omega, and Kubernetes》及《Large-scale cluster management at Google with Borg》等论文，分享了 Google 内部开发和运维 Borg、Omega 和 Kubernetes 系统的经验与教训。本章，我们从“Google 内部容器系统演变”展开，讨论容器编排系统关于网络通信、持久化存储、资源模型和编排调度等方面的设计原理和应用。本章内容安排如图 7-0 所示。
+过去十年间，Kubernetes 发展成为容器编排系统的事实标准，也成为大数据分析、机器学习以及在线服务等领域广泛认可的最佳技术底座。然而，Kubernetes 在解决复杂问题的同时，本身也演变成当今最复杂的软件系统之一。目前，包括官方文档在内的大多数 Kubernetes 资料都聚焦于“怎么做”，鲜有解释“为什么这么做”。自 2015 年起，Google 陆续发布了《Borg, Omega, and Kubernetes》及《Large-scale cluster management at Google with Borg》等论文，分享了 Google 内部开发和运维 Borg、Omega 和 Kubernetes 系统的经验与教训。本章，我们从这几篇论文展开，讨论容器编排系统关于网络通信、持久化存储、资源模型和编排调度等方面的设计原理和应用。本章内容安排如图 7-0 所示。
 
 :::center
   ![](../assets/container-summary.png)<br/>

diff --git a/http/congestion-control.md b/http/congestion-control.md
@@ -1,15 +1,13 @@
 # 2.6 网络拥塞控制原理与实践
 
-本节，我们分析互联网不同阶段拥塞控制算法原理，以 Google 发布的 BBR 算法为例，讨论大带宽、高延迟的网络环境下改善“网络吞吐量”（Network Throughput）的设计。
+本节，我们分析互联网不同阶段拥塞控制算法原理，讨论在大带宽、高延迟的网络环境下改善“网络吞吐量”（Network Throughput）的设计。
 
 ## 2.6.1 网络拥塞控制原理
 
-网络吞吐量与 RTT、带宽密切相关：
+网络吞吐量与 RTT、带宽密切相关，图 2-22 展示了这两者的变化对网络吞吐量的影响。可以看出：
 - RTT 越低，数据传输的延迟越低；
 - 带宽越高，网络在单位时间内传输的数据越多。
 
-图 2-22 展示了这两者的变化逻辑，以及对网络吞吐量的影响。
-
 :::center
   ![](../assets/bbr-cc.png)<br/>
  图 2-22 RTT、带宽变化对网络吞吐效率的影响