fix typo

ServiceMesh/data-plane.md

@@ -118,10 +118,10 @@ Chain ISTIO_REDIRECT (2 references)
 
 传统的代理（如 HAProxy 或 Nginx）依赖静态配置文件来定义资源和数据转发规则，而 Envoy 则几乎所有配置都可以动态获取。Envoy 将代理转发行为的配置抽象为三类资源：Listener、Cluster 和 Router，并基于这些资源定义了一系列标准数据面 API，用于发现和操作这些资源。这套标准数据面 API 被称为 xDS。
 
-xDS 的全称是 "x Discovery Service"，这里的 "x" 代指表 8-1 中的协议族。
+xDS 的全称是“x Discovery Service”，这里的 “x” 指的是表 8-1 中的协议族。
 
 :::center
-表 9-1 xDS v3.0 协议族
+表 8-1 xDS v3.0 协议族
 :::
 | 简写 |                全称                |        描述        |
 | :--: | :--------------------------------: | :----------------: |
@@ -140,8 +140,7 @@ xDS 的全称是 "x Discovery Service"，这里的 "x" 代指表 8-1 中的协
 | ECDS | Extension Config Discovery Service |  扩展配置发现服务  |
 | xDS  |        X Discovery Service         | 以上诸多API的统称  |
 
-具体到每个 xDS 协议都包含大量的内容，笔者无法一一详述。但通过这些协议操作的资源，再结合图 8-11，可大致说清楚它们的工作原理。
-
+具体到每个 xDS 协议都包含大量的内容，笔者无法一一详述。但通过这些协议操作的资源，再结合图 8-11 理解，可大致说清楚它们的工作原理。
 
 
 - **Listener**：Listener 可以理解为 Envoy 打开的一个监听端口，用于接收来自 Downstream（下游服务，即客户端）连接。每个 Listener 配置中核心包括监听地址、插件（Filter）等。Envoy 支持多个 Listener，不同 Listener 之间几乎所有的配置都是隔离的。

application-centric/Controller.md

@@ -25,7 +25,7 @@ Kubernetes 与其他基础设施的最大不同是，它是基于声明式管理
 
 IaD 思想主张，基础设施的管理应该脱离特定的编程语言或配置方式，而采用纯粹、格式化、系统可读的数据，描述用户期望的系统状态。这种思想的优势在于，对基础设施的所有操作本质上等同于对数据的“增、删、改、查”。更重要的是，这些操作的实现方式与基础设施本身无关，不依赖于特定编程语言、协议或 SDK，只要生成符合格式要求的“数据”，便可以“随心所欲”地采用任何你偏好的方式管理基础设施。
 
-IaD 思想在 Kubernetes 上的体现，就是执行任何操作，只需要提交一个 YAML 文件，然后对 YAML 文件增、删、查、改即可，而不是必须使用 Kubernetes SDK 或者 Restful API。这个 YAML 文件其实就对应了 IaD 中的 Data。从这个角度来看，Kubernetes 暴露出来的各种 API 对象，本质是一张张预先定义好 Schema 的“表”（table）。唯一跟传统数据库不太一样的是，Kubernetes 并不以持久化这些数据为目标，而是监控数据变化驱动“控制器”执行相应操作。
+IaD 思想在 Kubernetes 上的体现，就是执行任何操作，只需要提交一个 YAML 文件，然后对 YAML 文件增、删、查、改即可，而不是必须使用 Kubernetes SDK 或者 Restful API。这个 YAML 文件其实就对应了 IaD 中的 Data。从这个角度来看，Kubernetes 暴露出来的各种 API 对象，本质是一张张预先定义好 Schema 的“表”（table）（见表 10-1 ）。唯一跟传统数据库不太一样的是，Kubernetes 并不以持久化这些数据为目标，而是监控数据变化驱动“控制器”执行相应操作。
 
 :::center
 表 10-1 Kubernetes 是个“数据库”

application-centric/application-centric.md

@@ -8,6 +8,6 @@
 
 不过，基础设施能力的演进，也伴随着云计算和开源社区的发展，带来了全新的升级。这个变化，正是从云原生技术改变中间件格局开始。更确切地说，原先通过中间件提供和封装的能力，现在全部被 kubernetes 从应用层拽到基础设施层。比如，Kubernetes 最早提供的应用副本管理、服务发现和分布式协同能力，其实把构建分布式应用最迫切的需求，利用 Replication Controller、kube-proxy 和 etcd “下沉”到基础设施中，也就是 kubernetes 中。
 
-值得注意的是，kubernetes 不直接提供这些能力，它的角色定位是通过声明式 API 和控制器模式对用户暴露更底层基础设施的能力。从这个角度来看，Kubernetes 设计的重点在于“如何标准化地接入底层资源，无论是容器、虚拟机、负载均衡等，并通过声明式 API 将这些能力暴露给用户”。所以说，Kubernetes 的核心价值不在于容器编排或资源调度，而在于声明式 API。声明式 API 的最大优势是将“简单的交给用户，将复杂的留给系统”。通过声明式 API，Kubernetes 用户只需关心应用的最终状态，而无需关注底层基础设施的配置和实现细节。
+值得注意的是，kubernetes 不直接提供这些能力，它的角色定位是通过声明式 API 和控制器模式对用户暴露更底层基础设施的能力。从这个角度来看，Kubernetes 设计的重点在于“如何标准化地接入底层资源，无论是容器、虚拟机、负载均衡等，并通过声明式 API 将这些能力暴露给用户”。所以说，Kubernetes 的核心价值不在于容器编排或资源调度，而在于声明式 API。声明式 API 的最大优势是将“简单的交给用户，将复杂的留给系统”。通过声明式 API，Kubernetes 用户只需关心应用的最终状态，无需关注底层基础设施的配置和实现细节。
 
 这种设计理念，以一言蔽之，就是以应用中心。正是因为以应用为中心，整个云原生技术体系无限强调基础设施更好地服务于应用，以更高效的方式为应用提供基础设施能力，而不是反其道行之。而相应的，Kubernetes 也好、Docker 也好、Istio 也好，这些在云原生生态中起到了关键作用的开源项目，就是让这种思想落地的技术手段。

container/Resource-scheduling.md

@@ -1,5 +1,5 @@
 # 7.7 资源模型及编排调度
 
-过去，许多集群管理平台（如 Yarn、Mesos、Swarm）主要通过特定规则将容器调度到最佳节点上，这一功能称为“调度”。而 Kubernetes 擅长的，是根据系统规则和用户需求，自动化地处理好容器间的各种关系，这个功能就是我们常听到的 “编排”。
+过去的集群管理平台（如 Yarn、Mesos、Swarm）擅长的是，通过特定规则将容器调度到最佳节点上，这一功能称为“调度”。而 Kubernetes 擅长的，是根据系统规则和用户需求，自动化地处理好容器间的各种关系，这个功能就是我们常听到的 “编排”。
 
 接下来，笔者将围绕 Kubernetes 资源模型、异构资源扩展以及默认调度器（kube-scheduler），深入讨论  Kubernetes 的容器编排功能。

intro.md

@@ -79,7 +79,7 @@
 - 想了解业界的技术发展趋向和动态。
 - 需要对系统架构做出权衡、洞察出各类设计陷阱。
 - 需要构建高可用和健壮运行的系统。
-- 对请求/响应式系统整体如何运行有着天然的兴趣和探索精神。
+- 对互联网系统整体如何运行有着天然的兴趣和探索精神。
 
 ## 如何阅读本书