fix typo

Observability/OpenTelemetry.md

@@ -6,9 +6,9 @@ Dapper 发布后，市场上涌现出大量追踪系统，如 Jaeger、Pinpoint
 
 为解决追踪系统各自为政的乱象，一些老牌应用性能监控（APM）厂商（如 Uber、LightStep 和 Red Hat）联合定义了一套跨语言的、平台无关分布式追踪标准协议 —— OpenTracing。
 
-开发者只要根据 OpenTracing 规范实现追踪逻辑接口，可以灵活地替换或组合探针、存储和界面等组件。2016 年，CNCF 正式接纳 OpenTracing 成为其第三个项目，前两个项目分别是鼎鼎大名的 Kubernetes 和 Prometheus。这标志着 OpenTracing 作为分布式系统可观测性领域的标准之一，得到了业界的广泛认可。
+开发者只需按照 OpenTracing 规范实现追踪逻辑接口，便可灵活替换或组合探针、存储和界面等组件。2016 年，CNCF 将 OpenTracing 收录为其第三个项目，前两个分别是大名鼎鼎的 Kubernetes 和 Prometheus。这一举措标志着 OpenTracing 作为分布式系统可观测性领域的标准之一，获得了业界的广泛认可。
 
-OpenTracing 推出不久之后，Google 和微软联合推出了 OpenCensus 项目。OpenCensus 最初是 Google 内部监控工具，开源的目地并不是抢 OpenTracing 的饭碗，而是希望为分布式系统提供一个统一的、跨语言的、开箱即用的可观测性框架，既能够处理链路追踪（trace）、又能够处理指标（metrics）。
+在 OpenTracing 推出后不久，Google 和微软联合推出了 OpenCensus 项目。OpenCensus 起初是 Google 内部的监控工具，开源的目的并非与 OpenTracing 竞争，而是希望为分布式系统提供一个统一、跨语言、开箱即用的可观测性框架。它不仅能够支持链路追踪（tracing），还具备处理指标（metrics）的能力。
 
 虽说 OpenTracing 和 OpenCensus 推动了可观测性系统的发展，但它们作为可观测领域下的协议标准，彼此之间的竞争和分裂不可避免地消耗了大量社区资源。对于普通开发者而言，一边是老牌 APM 厂商，另一边是拥有强大影响力的 Google 和微软。选择困难症发作时，一个新的设想不断被讨论：“能否有一个标准的方案，同时支持指标、追踪和日志等各类遥测数据？”。
 

Observability/profiles.md

@@ -1,8 +1,8 @@
 # 9.3.4 性能剖析 Profiling
 
-熟悉 Golang 的工程师对 pprof 工具一定不陌生。借助 pprof 提供的 CPU 和内存分析功能，工程师能够深入了解 Golang 函数的执行时间、内存使用情况，从而分析、优化软件性能。
+熟悉 Golang 的工程师对 pprof 工具一定不陌生。借助 pprof 提供的 CPU 和内存分析功能，工程师能够深入了解 Golang 函数的执行时间、内存使用情况，从而分析、优化应用性能。
 
-可观测性领域内的性能剖析（Profiling）的目标与 Golang 中的 pprof 类似，两者皆是对运行中应用动态分析、生成详细的运行数据（Profiles），帮助工程师全面了解软件资源使用情况，确定代码和性能瓶颈之间的关联。
+可观测性领域内的性能剖析（Profiling）和 Golang 中的 pprof 目标一致，两者皆是对运行中应用动态分析、生成详细的运行数据（Profiles），帮助工程师全面了解应用资源使用情况，确定代码和性能瓶颈之间的关联。
 
 Profiles 数据通常以火焰图、堆栈图或内存分析图等形式呈现，是从“是什么”到“为什么”这一过程中重要的依据。例如，通过链路追踪识别出延迟（是什么）的位置，然后根据火焰图进一步定位到具体的代码行（为什么）。2021 年，国内某网站崩溃，工程师分析火焰图发现 Lua 代码存在异常，最终成功定位到问题源头[^1]。
 
@@ -24,12 +24,12 @@ Profiles 数据通常以火焰图、堆栈图或内存分析图等形式呈现
 
 Profiles 数据包括多种类型，由不同的分析器（Profiler）生成，常见分析器如下：
 
-- **CPU 分析器**：用于分析哪些函数或方法在运行时消耗了最多的 CPU 时间。例如，通过 CPU Profiler，我们可以确定某个算法的优化是否减少了 CPU 使用率。
-- **堆分析器（Heap Profiler）**：用于监测程序的内存使用情况，帮助发现内存泄漏或不必要的内存分配。例如，在 Java 应用中，Heap Profiler 可以帮助找到导致内存溢出的具体对象或数据结构。
-- **GPU 分析器**：用于分析图形处理单元（GPU）的利用情况，常用于游戏开发或图形密集型应用。
-- **互斥锁分析器**：用于检测互斥锁的竞争情况，帮助优化多线程程序的并发性能。
-- **I/O 分析器**：分析 I/O 操作的性能，如用来分析文件读写操作的延迟或网络请求的耗时，从而优化数据传输效率。
-- **特定编程语言的分析器**：如 JVM Profiler，专门分析运行在 Java 虚拟机上的应用程序。
+- **CPU 分析器**：跟踪程序中每个函数或代码块的运行时间，记录函数调用的堆栈信息，生成调用图，显示函数之间的调用关系和时间分布。工程师利用调用图，可以找出 CPU 使用率最高的代码段，集中优化这些“热点”部分。
+- **堆分析器（Heap Profiler）**：监控程序的内存使用情况，帮助定位内存泄漏或不必要的内存分配。例如，在 Java 应用中，使用 Heap Profiler 定位导致内存溢出的具体对象。
+- **GPU 分析器**：分析 GPU 的使用情况，常见于游戏开发或其他图形密集型应用场景，用于优化渲染性能。
+- **互斥锁分析器**：检测程序中互斥锁的竞争情况，帮助优化线程间的并发性能，减少因锁争用导致的性能瓶颈。
+- **I/O 分析器**：评估 I/O 操作的性能，包括文件读写延迟和网络请求耗时，帮助识别数据传输瓶颈并提升效率。
+- **特定编程语言的分析器**：例如 JVM Profiler，专门分析运行在 Java 虚拟机上的应用程序，挖掘与语言特性相关的性能问题。
 
 过去，由于分析器资源消耗较高，工程师通常仅在紧急情况下临时启用它们。随着低开销分析技术的兴起，如编程语言层面的 Java Flight Recorder 和 Async Profiler 技术、操作系统层面的 systemTap 和 eBPF 技术，让生产环境中的“持续性能分析”（Continuous Profiling）逐渐成为现实，捕获“疑难杂症”的现场快照也变得更加容易。
 

ServiceMesh/The-future-of-ServiceMesh.md

@@ -1,6 +1,6 @@
-# 8.7 服务网格的未来
+# 8.6 服务网格的未来
 
-随着服务网格的逐步落地，Sidecar模式的缺点也逐渐显现：
+随着服务网格的逐步落地，Sidecar 模式的缺点也逐渐显现：
 
 - **网络延迟问题**：服务网格通过 iptables 拦截服务间的请求，将原本的 A->B 通信改为 A->（iptables+Sidecar）-> （iptables+Sidecar）->B，调用链的增加导致了额外的性能损耗。尽管 Sidecar 的引入通常只会增加毫秒级（个位数）的延迟，但对于对性能要求极高的业务来说，额外的延迟是放弃服务网格的主要原因。。
 - **资源占用问题**：Sidecar 作为一个独立的容器必然占用一定的系统资源，对于超大规模集群（如有数万个 Pod）来说，巨大的基数使 Sidecar 占用资源总量变得相当可观。
@@ -13,14 +13,14 @@
 
 Proxyless 模式的设计理念是，服务间通信总是要选择一种协议，那么将实现协议的类库（SDK）扩展，增加通信治理能力，不就能代替 Sidecar 了吗？且 SDK 和应用封装在一起，必然有更优秀的性能表现，Sidecar 为人诟病的延迟问题将迎刃而解。
 
-2021 年，Istio 官方博客发表文章 《基于 gRPC 的无代理服务网格》[^1]，文中介绍了一种基于 gRPC 框架实现的 Proxyless 模式的服务网格。它的工作原理如图 8-19 所示，服务间通信治理不再依赖 Sidecar，而是采用原始的方式，也就是在 gRPC 库中实现。此外，该模式需要额外一个代理（图中的 Istio Agent）通过 xDS 协议与控制平面交互，负责告知 gRPC 库如何连接到 istiod、如何获取证书、处理流量的策略等。
+2021 年，Istio 发表文章《基于 gRPC 的无代理服务网格》[^1]，介绍了一种基于 gRPC 实现的 Proxyless 模式的服务网格。它的工作原理如图 8-19 所示，服务间通信治理不再依赖 Sidecar，而是采用原始的方式在 gRPC SDK 中实现。此外，该模式还额外需要一个代理（Istio Agent）与控制平面（Control Plane）交互，告知 gRPC SDK 如何连接到 istiod、如何获取证书、处理流量的策略等。
 
 :::center
   ![](../assets/proxyless.svg)<br/>
  图 8-19 Proxyless 模式
 :::
 
-相比 Sidecar，Proxyless 模式在性能、稳定性、资源消耗低等方面具有明显的优势。根据官方博客的性能测试报告来看，gRPC Proxyless 模式下的延迟情况接近“基准”（baseline），资源消耗也相对较低。
+相比 Sidecar，Proxyless 模式在性能、稳定性、资源消耗低等方面具有明显的优势。根据官方公布的性能测试报告来看，gRPC Proxyless 模式下，延迟情况接近“基准”（baseline）、资源消耗也相对较低。
 
 :::center
   ![](../assets/latencies_p50.svg)<br/>

network/iptables.md

@@ -6,7 +6,7 @@ Netfilter 的钩子回调固然强大，但得通过程序编码才能使用，
 
 ## 1. iptables 表和链
 
-Netfilter 中的钩子，在 iptables 中称作“链”（chain）。
+Netfilter 中的钩子在 iptables 中的对应称作“链”（chain）。
 
 iptables 默认有五条链：PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTING。从名字上看，它们分别对应了 Netfilter 的 5 个钩子。