fix typo

Observability/summary.md

@@ -8,11 +8,11 @@ given enough eyeballs, all bugs are shallow.
 —— by Linus Torvalds
 :::
 
-容器、微服务以及服务网格等新技术释放生产力的同时，系统的复杂性变得难以控制。治理这些高度动态化、分布式的云技术，与以往的方法截然不同，超出了绝大部分 IT 团队的管理能力极限，"云深不见底"问题日益凸显。
+随着系统规模扩大、组件复杂化以及服务间依赖关系的增加，系统监控和调试难度超出了绝大部分工程师的能力极限。
 
-复杂性失控问题在工业领域同样出现过。自 19 世纪末，电气工程各个细分领域迅速发展，尤其是 20 世纪 50 年代的航空领域，系统日益复杂，研发效率要求不断提高，系统的运行环境也变得越来越多样化，对系统的稳定性提出了巨大挑战。在这一背景下，匈牙利裔工程师 Rudolf Emil Kálmán 提出了“可观测性”这一概念，其核心理念是“通过系统外部的输出信号，判断工作状态并定位缺陷的根因”。
+复杂性失控问题在工业领域同样出现过。自 19 世纪末，电气工程的细分领域迅速发展，尤其是 20 世纪 50 年代的航空领域，研发效率要求越来越高、运行环境越来越多样化，系统日益复杂对稳定性提出了巨大挑战。在这一背景下，匈牙利裔工程师 Rudolf Emil Kálmán 提出了“可观测性”这一概念，其核心理念是“通过系统外部的输出信号，判断工作状态并定位缺陷的根因”。
 
-随着计算机技术和软件工程的发展，复杂软件系统的工作状态同样需要通过系统外部输出进行度量。通过借鉴电气系统的观测方法，我们可以利用系统输出的各种运行信息来实现软件的可观测性。2018 年，CNCF 率先将“可观测性”概念引入 IT 领域，并强调系统的可观测性是云原生时代的必备能力。从生产所需到概念发声，加之包括 Google 在内的众多大厂一拥而上。“可观测性”逐渐取代“监控”，成为云原生技术领域最热门的话题之一。
+随着软件工程的发展，复杂软件系统的工作状态同样需要对系统外部输出进行度量。借鉴电气系统的观测理论，我们可以利用系统输出的各种运行信息来实现软件的可观测性。2018 年，CNCF 率先将“可观测性”概念引入 IT 领域，强调系统的可观测性是云原生时代的必备能力！从生产所需到概念发声，加之包括 Google 在内的众多大厂一拥而上。“可观测性”逐渐取代“监控”，成为云原生技术领域最热门的话题之一。
 
 :::center
   ![](../assets/observability.png)<br/>

ServiceMesh/What-is-ServiceMesh.md

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

ServiceMesh/overview.md

@@ -15,7 +15,7 @@ Istio 的最大创新在于为微服务系统带来了前所未有的控制力
 Buoyant 公司的第二代服务网格使用 Rust 构建数据平面 linkerd2-proxy ，使用 Go 开发了控制平面 Conduit，主打轻量化，目标是世界上最轻、最简单、最安全的 Kubernetes 专用服务网格。该产品最初以 Conduit 命名，Conduit 加入 CNCF 后不久，宣布与原有的 Linkerd 项目合并，被重新命名为 Linkerd 2[^1]，
 
 Linkerd2 的架构如图 8-13 所示，增加了控制平面，但整体相对简单：
-- 控制层面组件只有 destination（类似 Istio 中的 Pilot 组件）、identity（类似 Istio 中的 Citadel）和 proxy injector（代理注入器，自动将 Linkerd 代理作为 Sidecar 容器注入到匹配的 Pod 中，无需手动修改应用程序的部署配置）。
+- 控制层面组件只有 destination（类似 Istio 中的 Pilot 组件）、identity（类似 Istio 中的 Citadel）和 proxy injector（代理注入器）。
 - 数据平面中 linkerd-init 设置 iptables 规则拦截 Pod 中的 TCP 连接，linkerd-proxy 实现对所有的流量管控（负载均衡、熔断..）。
 
 :::center
@@ -25,11 +25,11 @@ Linkerd2 的架构如图 8-13 所示，增加了控制平面，但整体相对
 
 ## 8.5.2 其他参与者
 
-除了头部的 Linkerd2、Istio 玩家外，明显能影响微服务格局的新兴领域，又怎少得了传统的 Proxy 玩家。
+能明显影响微服务格局的新兴领域，除了头部的 Linkerd2、Istio 玩家外，又怎少得了传统的 Proxy 玩家。
 
-先是远古玩家 Nginx 祭出自己新一代的产品 Nginx ServiceMesh，理念是简化版的服务网格。接着，F5 Networks 公司顺势推出商业化产品 Aspen Mesh，定位企业级服务网格项目。随后，API 网关独角兽 Kong 推出了 Kuma，主打通用型的服务网格。有意思的是，Kong 选择了 Envoy 作为数据平面，而非它自己的核心内核 OpenResty。
+先是远古玩家 Nginx 祭出自己新一代的产品 Nginx ServiceMesh，理念是简化版的服务网格。接着，F5 Networks 公司顺势推出商业化产品 Aspen Mesh，定位企业级服务网格。随后，API 网关独角兽 Kong 推出了 Kuma，主打通用型服务网格。有意思的是，Kong 选择了 Envoy 作为数据平面，而非它自己内核 OpenResty。
 
-与 William Morgan 死磕 Istio 策略不同，绝大部分在 Proxy 领域根基深厚玩家，从一开始就没有想过做一套完整服务网格方案，而是选择实现 xDS 协议或基于 Istio 扩展，作为 Istio 的数据平面出现。
+与 William Morgan 死磕 Istio 策略不同，绝大部分在 Proxy 领域根基深厚玩家，从一开始就没有想过做一套完整服务网格，而是选择实现 xDS 协议或基于 Istio 扩展，作为 Istio 的数据平面出现。
 
 至 2023 年，服务网格经过 8 年的发展，产品生态如图 8-14 所示。虽然有众多的选手，但就社区活跃度而言，Istio 和 Linkerd 还是牢牢占据了头部地位。
 

network/network-namespace.md

@@ -1,10 +1,8 @@
 # 3.5.1 网络命名空间
 
-Linux 内核从 2.4.19 版本起，开始逐步集成多种命名空间技术，以实现对各类资源的隔离。网络命名空间（Network Namespace）是其中最关键的一种，它是各类容器化技术的核心。
+Linux 内核从 2.4.19 版本起，逐步集成多种命名空间技术，以实现对各类资源的隔离。网络命名空间（Network Namespace）是其中最关键的一种，它是容器技术的核心。
 
-有了网络命名空间技术，Linux 系统便能够在一个主机内创建多个独立的网络环境。每个网络命名空间都拥有自己独立的网络资源，包括防火墙规则、网络接口、路由表、ARP 邻居表以及完整的网络协议栈。
-
-当进程运行在一个网络命名空间内，感觉就像独享一台物理主机一样。
+网络命名空间技术能让 Linux 系统一个主机内创建多个独立的网络环境，它们拥有独立的网络资源，比如防火墙规则、网络接口、路由表、ARP 邻居表以及完整的网络协议栈。当进程运行在一个网络命名空间内，就像独享一台物理主机。
 
 :::center
   ![](../assets/linux-namespace.svg)<br/>