diff --git a/ServiceMesh/conclusion.md b/ServiceMesh/conclusion.md
index 08c3ff20..d2fe5b9b 100644
--- a/ServiceMesh/conclusion.md
+++ b/ServiceMesh/conclusion.md
@@ -4,6 +4,6 @@
从最初 TCP/IP 协议的出现，我们看到网络传输相关的逻辑从应用层剥离，下沉至操作系统，成为操作系统的网络层。分布式系统的崛起，又带来了特有的分布式通信语义（服务发现、负载均衡、限流、熔断、加密...）。为了降低治理分布式通信的心智负担，面向微服务的 SDK 框架出现了，但这类框架与业务逻辑耦合在一起，带来门槛高、无法跨语言、升级困难三个固有问题。
-而服务网格的出现为分布式通信治理带来了全新的解决思路：通信治理逻辑从应用程序内部剥离至边车代理，下沉至 Kubernetes、下沉至各个云平台，在应用层与基础设施层之间衍生出全新的微服务治理层。沿着上述“分离/下沉”的设计理念，服务网格的形态不再局限于边车代理，开始多元化，出现了 Proxyless、Sidecarless、Ambient Mesh 等多种模式。
+而服务网格的出现为分布式通信治理带来了全新的解决思路：通信治理逻辑从应用程序内部剥离至边车代理，下沉至 Kubernetes、下沉至各个云平台。沿着上述“分离/下沉”的设计理念，服务网格的形态不再局限于边车代理，开始多元化，陆续出现了 Proxyless、Sidecarless、Ambient Mesh 等多种模式。
-无论通信治理逻辑下沉至哪里、服务网格以何种形态存在，核心把非业务逻辑从应用程序中剥离，让业务开发更简单。这正是业内常提到的“以应用为中心”的软件设计核心理念。
\ No newline at end of file
+无论通信治理逻辑下沉至哪里、服务网格以何种形态存在，核心都是把非业务逻辑从应用程序中剥离，让业务开发更简单。这正是业内常提到的“以应用为中心”设计理念的体现。
\ No newline at end of file
diff --git a/consensus/conclusion.md b/consensus/conclusion.md
index 05b4c1e2..84fd2e3b 100644
--- a/consensus/conclusion.md
+++ b/consensus/conclusion.md
@@ -4,7 +4,7 @@
Paxos 基于“少数服从多数”（Quorum 机制）原则，通过“请求阶段”和“批准阶段”在不确定环境下达成一致，解决了单个“提案”的共识问题。通过多次运行 Paxos，可以实现一系列“提案”的共识，这就是 Multi-Paxos 的核心思想。Raft 算法在 Multi-Paxos 的基础上，针对工程实用性进行了优化，在一致性、安全性和可理解性之间找到平衡，成为业界广泛采用的主流选择。
-接下来，再思考一个问题，Raft 算法属于“强领导者”（Strong Leader）模型，领导者负责所有写入操作，它的写瓶颈就是 Raft 集群的写瓶颈。该如何突破 Raft 集群的写瓶颈呢？
+接下来，再思考一个问题，Raft 算法属于“强领导者”模型，领导者负责所有写入操作，它的写瓶颈就是 Raft 集群的写瓶颈。那么，该如何突破 Raft 集群的写瓶颈呢？
一种方法是使用哈希算法将数据划分成多个独立部分。例如，将一个 100TB 规模数据的系统分成 10 部分，每部分只需处理 10TB。这种根据规则（范围或哈希）将数据分散处理的策略，被称为“分片机制”（Sharding）。分片机制广泛应用于 Prometheus、Elasticsearch 、ClickHouse 等大数据系统（详见本书第九章）。理论上，只要机器数量足够，分片机制便能支持几乎无限规模的数据。
diff --git a/container/CRI.md b/container/CRI.md
index bb6f93bb..5d3e54fb 100644
--- a/container/CRI.md
+++ b/container/CRI.md
@@ -1,31 +1,27 @@
# 7.4 容器运行时接口的演变
-Docker 完全没有预料到，在它诞生的十多年后，仍然能够再次成为舆论的焦点。
+Docker 在诞生十多年后，未曾料到仍会重新成为舆论焦点。事件的起因是 Kubernetes 宣布将进入废弃 dockershim 支持的倒计时，随后讹传讹被人误以为 Docker 不能再用了。
-事件的起因是 Kubernetes 宣布进入废弃 dockershim 支持的倒计时，随后讹传讹被人误以为 Docker 不能再用了。虽说此次事件有众多标题党的推波助澜，但也侧面说明了 Kubernetes 与 Docker 的关系十分微妙。
-
-本节，我们把握这两者关系的变化，从中理解 Kubernetes 容器运行时接口的演变。
+虽说此次事件有众多标题党的推波助澜，但也从侧面说明了 Kubernetes 与 Docker 的关系十分微妙。本节，我们把握这两者关系的变化，从中理解 Kubernetes 容器运行时接口的演变。
## 7.4.1 Docker 与 Kubernetes
-早期，Kubernetes 完全依赖并绑定于 Docker。
-
-当时 Docker 太流行了，所以 Kubernetes 没有过多考虑够日后使用其他容器引擎的可能性。当时 kubernetes 通过内部的 DockerManager 组件直接调用 Docker API 来创建和管理容器。
+由于 Docker 太流行了，Kubernetes 没有考虑支持其他容器引擎的可能性，完全依赖并绑定于 Docker。那时，Kubernetes 通过内部的 DockerManager 组件直接调用 Docker API 来创建和管理容器。
:::center
图 7-12 Kubernetes 早期调用 Docker 的链路
:::
-后来，市场上出现了越来越多的容器运行时，比如 CoreOS[^1] 推出的开源容器引擎 Rocket（简称 rkt）。rkt 出现之后，Kubernetes 用类似强绑定 Docker 的方式又实现了对 rkt 容器引擎的支持。随着容器技术的蓬勃发展，如果继续使用与 Docker 类似强绑定的方式，Kubernetes 的工作量将无比庞大。
+随着市场上出现越来越多的容器运行时，例如 CoreOS 推出的开源容器引擎 Rocket（简称 rkt），Kubernetes 在 rkt 发布后采用类似强绑定 Docker 的方式，添加了对 rkt 的支持。随着容器技术的快速发展，如果继续采用这种与 Docker 类似的强绑定方式，Kubernetes 的维护工作将变得无比庞大。
-Kubernetes 需要重新审视与市面上各类容器运行时的适配问题了。
+Kubernetes 需要重新审视与各种容器运行时的适配问题了。
## 7.4.2 容器运行时接口 CRI
-Kubernetes 从 1.5 版本开始，在遵循 OCI 的基础上，将对容器的各类操作抽象为一个个接口。这些接口作为 Kubelet（Kubernetes 中的节点代理）与容器运行时实现对接的桥梁。Kubelet 通过发送接口请求来实现对容器的各类管理。
+从 Kubernetes 1.5 版本开始，Kubernetes 在遵循 OCI 标准的基础上，将容器管理操作抽象为一系列接口。这些接口作为 Kubelet（Kubernetes 节点代理）与容器运行时之间的桥梁，使 Kubelet 能通过发送接口请求来管理容器。
-上述的接口，称为“CRI 接口”（Container Runtime Interface，容器运行时接口）。CRI 接口实现上是一套通过 Protocol Buffer 定义的 API。笔者列举部分容器操作接口供你参考：
+管理容器的接口称为“CRI 接口”（Container Runtime Interface，容器运行时接口）。如下面的代码所示，CRI 接口其实是一套通过 Protocol Buffer 定义的 API。
```protobuf
// RuntimeService 定义了管理容器的 API
@@ -52,18 +48,17 @@ service ImageService {
}
```
-从图 7-13 可以看出，CRI 规范的实现上主要由三个组件协作完成：gRPC Client、gRPC Server 和具体容器运行时实现（container runtime）。其中：
+根据图 7-13，CRI 的实现由三个主要组件协作完成：gRPC Client、gRPC Server 和具体的容器运行时。具体来说：
-- Kubelet 作为 gRPC Client 调用 CRI 接口；
-- CRI shim 作为 gRPC Server 响应 CRI 请求，并负责将 CRI 请求转换为具体的运行时管理操作。
+- Kubelet 充当 gRPC Client，调用 CRI 接口；
+- CRI shim 作为 gRPC Server，响应 CRI 请求，并将其转换为具体的容器运行时管理操作。
:::center
图 7-13 CRI 是通过 gRPC 实现的 API
:::
-因此，市场上的各类容器运行时，只要按照规范实现 CRI 接口，即可接入到 Kubernetes 生态之中。
-
+由此，市场上的各类容器运行时，只需按照规范实现 CRI 接口，就可以无缝接入 Kubernetes 生态。
## 7.4.3 Kubernetes 专用容器运行时
diff --git a/container/summary.md b/container/summary.md
index 59dcfe26..4efc79c0 100644
--- a/container/summary.md
+++ b/container/summary.md
@@ -10,7 +10,9 @@
随着容器化架构大规模应用，手动管理大量容器的方式变得异常艰难。为了减轻管理容器的心智负担，实现容器调度、扩展、故障恢复等自动化机制，容器编排系统应运而生。
-过去十年间，Kubernetes 发展成为容器编排系统的事实标准，也成为大数据分析、机器学习以及在线服务等领域广泛认可的最佳技术底座。然而，Kubernetes 在解决复杂问题的同时，本身也演变成当今最复杂的软件系统之一。目前，包括官方文档在内的大多数 Kubernetes 资料都聚焦于“怎么做”，鲜有解释“为什么这么做”。自 2015 年起，Google 陆续发布了《Borg, Omega, and Kubernetes》及《Large-scale cluster management at Google with Borg》等论文，分享了 Google 内部开发和运维 Borg、Omega 和 Kubernetes 系统的经验与教训。本章，我们从这几篇论文展开，讨论容器编排系统关于网络通信、持久化存储、资源模型和编排调度等方面的设计原理和应用。本章内容安排如图 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
