fix typo

ServiceMesh/summary.md

@@ -9,7 +9,7 @@
 
 Kubernetes 的崛起意味着虚拟化的基础设施，开始解决分布式系统软件层面的问题。Kubernetes 最早提供的应用副本管理、服务发现和分布式协同能力，实质上将构建分布式应用的核心需求，利用 Replication Controller、kube-proxy 和 etcd “下沉”到基础设施中。然而，Kubernetes 解决问题的粒度通常局限于容器层面，容器以下的服务间通信治理（如服务发现、负载均衡、限流、熔断和加密等问题）仍需业务工程师手动处理。
 
-在传统分布式系统中，解决上述问题通常依赖于微服务治理框架（如 Spring Cloud 或 Apache Dubbo），这类框架将业务逻辑和技术方案紧密耦合。而在云原生时代，解决这些问题时，在 Pod 内注入辅助功能的边车代理（Sidecar） ，业务对此完全无感知，显然是最“Kubernetes Native”的方式。边车代理将非业务逻辑从应用程序中剥离，服务间的通信治理由此开启了全新的进化，并最终演化出一层全新基础设施层 —— 服务网格（ServiceMesh）。
+在传统分布式系统中，解决上述问题通常依赖于微服务治理框架（如 Spring Cloud 或 Apache Dubbo），这类框架将业务逻辑和技术方案紧密耦合。而在云原生时代，解决这些问题时，在 Pod 内注入代理型边车（Sidecar Proxy） ，业务对此完全无感知，显然是最“Kubernetes Native”的方式。边车代理将非业务逻辑从应用程序中剥离，服务间的通信治理由此开启了全新的进化，并最终演化出一层全新基础设施层 —— 服务网格（ServiceMesh）。
 
 本章，我们将回顾服务间通信的演化历程，从中理解服务网格出现的背景、以及它所解决的问题。然后解读服务网格数据面和控制面的分离设计，了解服务网格领域的产品生态（主要介绍 Linkerd 和 Istio）。最后，我们直面服务网格的缺陷（网络延迟和资源占用问题），讨论如何解决，并展望服务网格的未来。本章内容组织如图 8-0 所示。
 

balance/global-load-balancer.md

@@ -15,7 +15,7 @@
 全局负载均衡器能够实现很多单个负载均衡器无法完成的功能，比如下面这些：
 
 - 某个区域故障或负载过高时，全局负载均衡器自动将流量切换到其他可用区；
-- 利用机器学习、神经网络技术检测并缓解流量异常问题。比如识别治理 DDoS 攻击；
+- 利用机器学习、神经网络技术检测并缓解流量异常问题。比如识别并治理 DDoS 攻击；
 - 收拢边车代理配置，提供全局运维视角，帮助工程师直观理解、维护整个分布式系统。
 
 全局负载均衡器在服务网格领域表现的形式称“控制平面”（Control Plane），控制平面与边车代理协作的关键在于动态配置的实现，笔者将在第 8.7 节阐述这部分内容。

consensus/conclusion.md

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