fix typo

Observability/OpenTelemetry.md

@@ -1,6 +1,6 @@
 # 9.4 可观测标准项目的演进
 
-Dapper 论文发布后，市场上涌现出大量追踪系统，如 Jaeger、Pinpoint、Zipkin 等。这些系统基于 Dapper 论文实现，功能上无本质差异，但由于实现方式和技术栈不同，各自定义了采集标准和 SDK，导致它们难以兼容或协同使用。
+Dapper 论文发布后，市场上涌现出大量追踪系统，如 Jaeger、Pinpoint、Zipkin 等。这些系统都基于 Dapper 论文实现，功能上无本质差异，但实现方式和技术栈不同，导致它们难以兼容或协同使用。
 
 为解决追踪系统各自为政的乱象，一些老牌应用性能监控（APM）厂商（如 Uber、LightStep 和 Red Hat）联合定义了一套跨语言的、平台无关分布式追踪标准协议 —— OpenTracing。
 

Observability/What-is-Observability.md

@@ -9,8 +9,8 @@ Google Cloud 在介绍可观测标准项目 OpenTelemetry 时提到一个概念
 遥测数据（telemetry data）是指采样和汇总有关软件系统性能和行为的数据，这些数据（接口的响应时间、请求错误率、服务资源消耗等）用于监控和了解系统的当前状态。
 :::
 
-虽然“遥测数据”这个词听起来陌生，但在生活中你可能无意间接触过。例如，在观看火箭发射的直播时，你或许听到过类似的指令：“东风光学 USB 雷达跟踪正常，遥测信号正常” 。随着火箭升空，直播画面还会特意切换到一个看起来“高大上”仪表控制台。
+“遥测数据”看起来陌生，但你肯定无意间听过。观看火箭发射的直播时，你应该听到过类似的指令：“东风光学 USB 雷达跟踪正常，遥测信号正常” 。随着火箭升空，直播画面还会特意切换到一个看起来“高大上”仪表控制台。
 
-事实上，软件领域的可观测性与火箭发射系统的遥测概念并无本质区别，皆为**全方位收集系统各方面的运行数据（遥测数据），来了解系统内部的运作情况**。因此，可观测性本质上是一门关于数据收集和分析的科学，帮助人们解决复杂系统中的故障检测、性能优化和风险预警等问题。
+事实上，软件领域的可观测性与火箭发射系统的遥测概念并无本质区别，皆为**全方位收集系统各方面的运行数据（遥测数据），来了解系统内部的运作情况**。因此，可观测性本质上是一门数据收集和分析的科学，帮助人们解决复杂系统中的故障检测、性能优化以及风险预警等问题。
 
 [^1]: 参见 https://cloud.google.com/learn/what-is-opentelemetry

ServiceMesh/conclusion.md

@@ -1,16 +1,9 @@
 # 8.7 小结
 
-本章第二节，我们完整回顾了服务间通信的演变，相信你完全理解了服务网格出现的背景、它到底解决了什么问题。
+本章第二节，我们回顾了服务间通信的演变，从中解释了服务网格出现的背景、它到底解决了什么问题。
 
-服务网格“出圈”的原因，不在于它提供了多少功能，而是把非业务逻辑从应用程序内剥离的设计思想。从最初 TCP/IP 协议的出现，我们看到网络传输相关的逻辑从应用层剥离，下沉至操作系统，成为操作系统的网络层。随着分布式系统的崛起，又带来了特有的分布式通信语义（服务发现、负载均衡、限流、熔断、加密...）。为了降低治理分布式通信的心智负担，一些面向微服务架构的 SDK 框架出现了，但这类框架与业务逻辑耦合在一起，带来门槛高、无法跨语言、升级困难三个本质问题。
+服务网格“出圈”的原因，不在于它提供了多少功能，而是把非业务逻辑从应用程序内剥离的设计思想。从最初 TCP/IP 协议的出现，我们看到网络传输相关的逻辑从应用层剥离，下沉至操作系统，成为操作系统的网络层。分布式系统的崛起，又带来了特有的分布式通信语义（服务发现、负载均衡、限流、熔断、加密...）。为了降低治理分布式通信的心智负担，面向微服务架构的 SDK 框架出现了，但这类框架与业务逻辑耦合在一起，带来门槛高、无法跨语言、升级困难三个固有问题。
 
-服务网格的出现为分布式通信治理带来了全新的思路：通信治理逻辑从应用程序内部剥离至边车代理，下沉至 Kubernetes、下沉至各个云平台，在应用层与基础设施层之间衍生出全新的微服务治理层。沿着上述“分离/下沉”的设计思想，服务网格的形态开始多元化，出现了 Proxyless、Sidecarless、Ambient Mesh 等多种模式。
+服务网格为分布式通信治理带来了全新的思路：通信治理逻辑从应用程序内部剥离至边车代理，下沉至 Kubernetes、下沉至各个云平台，在应用层与基础设施层之间衍生出全新的微服务治理层。沿着上述“分离/下沉”的设计思想，服务网格的形态不再与 Sidecar 挂钩，开始多元化，出现了 Proxyless、Sidecarless、Ambient Mesh 等多种模式。
 
-无论服务网格下沉至哪里、产品以何种形态存在，核心都是将非业务逻辑从应用程序中剥离，让业务开发更简单。这正是业内常提到的“以应用为中心”的软件设计核心理念。
-
-参考文档：
-- 《William Morgan 的服务网格之战》，https://softwareengineeringdaily.com/2019/05/31/service-mesh-wars-with-william-morgan/
-- 《Pattern: Service Mesh》，https://philcalcado.com/2017/08/03/pattern_service_mesh.html
-- 图书《云原生服务网格Istio：原理、实践、架构与源码解析》
-- https://blog.container-solutions.com/wtf-is-cilium
-- https://isovalent.com/blog/post/cilium-service-mesh/
+无论通信治理逻辑下沉至哪里、服务网格以何种形态存在，核心把非业务逻辑从应用程序中剥离，让业务开发更简单。这正是业内常提到的“以应用为中心”的软件设计核心理念。

consensus/conclusion.md

@@ -2,10 +2,10 @@
 
 尽管 Paxos 是几十年前提出的算法，但它开创了分布式共识研究的先河。
 
-Paxos 基于“少数服从多数”（Quorum 机制）原则，通过“请求阶段”、“批准阶段”在不确定环境下协商达成一致决策，解决了单个“提案”的共识问题。运行多次 Paxos 便可实现一系列“提案”共识，这正是 Multi-Paxos 思想的核心。Raft 在 Multi-Paxos 思想之上，以工程实用性为目标，在一致性、安全性和可理解性之间找到平衡，成为分布式系统关键组件实现一致性的主流选择。
+Paxos 基于“少数服从多数”（Quorum 机制）原则，通过“请求阶段”、“批准阶段”在不确定环境下协商达成一致决策，解决了单个“提案”的共识问题。运行多次 Paxos 便可实现一系列“提案”共识，这正是 Multi-Paxos 思想的核心。Raft 在 Multi-Paxos 思想之上，以工程实用性为目标，在一致性、安全性和可理解性之间找到平衡，成为分布式系统实现一致性的主流选择。
 
 最后，再让我们思考一个问题，Raft 算法属于“强领导者”（Strong Leader）模型，领导者负责所有写入操作必限制整个 Raft 集群的写入性能，那如何突破 Raft 集群的写性能瓶颈呢？
 
-一种方法是使用一致性哈希算法将数据划分为多个独立部分。例如，一个拥有 100TB 数据的系统，可以将数据分成 10 个部分，每部分只需处理 10TB。这种通过规则（如范围或哈希）将数据分散到不同部分进行处理的策略，被称为“分区机制”（Partitioning）。分区机制广泛应用于 Prometheus、Elasticsearch 、ClickHouse 等大数据系统（详见本书第九章）。理论上，只要机器数量足够，分区机制便能够支持几乎无限规模的数据处理。
+一种方法是使用一致性哈希算法将数据划分为多个独立部分。例如，一个拥有 100TB 数据的系统，可以将数据分成 10 个部分，每部分只需处理 10TB。这种通过规则（如范围或哈希）将数据分散到不同部分进行处理的策略，被称为“分区机制”（Partitioning）。分区机制广泛应用于 Prometheus、Elasticsearch 、ClickHouse 等大数据系统（详见本书第九章）。理论上，只要机器数量足够，分区机制便能够支持几乎无限规模的数据。
 
-解决了数据规模的问题，接下来的课题是“将请求均匀地分摊至各个分区”，这部分内容我们在下一章《负载均衡》展开讨论。
+解决了数据规模的问题，接下来的课题是“将请求均匀地分摊至各个分区”，笔者将在下一章《负载均衡》展开讨论。