fix typo

application-centric/Helm.md

@@ -1,4 +1,4 @@
-# 10.4 Helm 
+# 10.3.2 Helm 
 
 相信读者朋友们知道 Linux 下的包管理工具和封装格式， 如 Debian 系的 apt-get 命令和 dpkg 格式、RHEL 系的 yum 命令和 rpm 格式。在 Linux 系统中，有了包管理工具，我们只要知道应用的名称，就可以很方便地从应用仓库中下载、安装、升级、回滚等，而且包管理工具掌握着应用的依赖信息和版本变更情况，具备完整的自管理能力，每个应用依赖哪些前置的第三方库，在安装时都会一并处理好。
 

application-centric/Kustomize.md

@@ -1,4 +1,4 @@
-# 10.3 Kustomize
+# 10.3.1 Kustomize
 
 最初 Kubernetes 对如何封装应用 的解决方案是用配置文件来配置文件，这并不是绕口令，可以理解为针对 yaml 模版引擎的变体。
 

application-centric/OAM.md

@@ -0,0 +1,30 @@
+# 10.3.5 OAM
+
+前面介绍的 Helm、Kustomize、CRD + Operator 在各自领域很好的承载一个“组件”的概念，但它们都没有解决一个完整的、面向业务场景的“应用”问题。
+
+OAM 的全称为开放应用模型（Open Application Model），由阿里巴巴联合微软共同推出。
+
+- Open，开放与云服务供应商无关。定义的开放标准应该是一套更高级别的抽象，可以跨越本地集群、异构平台、云服务提供商，不会被锁定到任何一个厂商的底座。
+- Application，应用为先。一个应用的交付与部署应该是自包含的，其中的各类操作行为应该作为应用定义的一部分，这些内容与实际的基础设施无关。
+- Model，标准的开放模型。模块化整个应用交付流程，根据个人的需要将这些模块自由组装，达成自己想要的结果。
+
+
+在 OAM 体系中大致分了三个角色，分别为：
+
+基础设施运维人员
+负责开发、安装和维护各种 Kubernetes 级别的功能。具体工作包括但不限于维护大规模的 K8s 集群、实现控制器/Operator，以及开发各种 K8s 插件。在公司内部，我们通常被称为“平台团队（Platform Builder）
+业务研发人员
+以代码形式传递业务价值。大多数业务研发都对基础设施或 K8s 不甚了解，他们与 PaaS 和 CI 流水线交互以管理其应用程序。业务研发人员的生产效率对公司而言价值巨大。
+应用运维人员
+为业务研发人员提供有关集群容量、稳定性和性能的专业知识，帮助业务研发人员大规模配置、部署和运行应用程序（例如，更新、扩展、恢复）。请注意，尽管应用运维人员对 K8s 的 API 和功能具有一定了解，但他们并不直接在 K8s 上工作。在大多数情况下，他们利用 PaaS 系统为业务研发人员提供基础 K8s 功能。在这种情况下，许多应用运维人员实际上也是 PaaS 工程人员。
+
+
+OAM 使用自定义资源将原先 All-in-One 的复杂配置做了一定层次的解耦，开发工程师管理 Component、运维工程师将 Component 组合并绑定 Trait 变成 AppConfig；平台工程师提供 OAM 的解释能力，将上述自定义资源映射到实际的基础设施；不同角色分工协作，整体上简化单个角色关注的内容，使得不同角色可以更聚焦更专业的做好本角色的工作。
+
+:::center
+  ![](../assets/OAM-how-it-works.png)<br/>
+  图 4-0 OAM
+:::
+
+- 组件（Component）：
+- 运维特征（运维特征）：运维特征是可以随时绑定给待部署组件的模块化、可拔插的运维能力，比如：副本数调整、数据持久化、设置网关策略、自动设置 DNS 解析等。用户可以从社区获取成熟的能力，也可以自行定义。

application-centric/Operator.md

@@ -1,4 +1,4 @@
-# 10.5 Operator
+# 10.3.4 Operator
 
 Operator 的概念由 CoreOS 于 2016 年提出，它并非一个具体的工具或系统，而是一种封装、部署和管理 Kubernetes 应用的方法，尤其适合需要特定领域知识的复杂有状态应用，如数据库、分布式缓存和消息队列等。
 
@@ -8,14 +8,6 @@ Operator 的概念由 CoreOS 于 2016 年提出，它并非一个具体的工具
 理解 Operator 所做的工作，需要先弄清楚“无状态应用”和“有状态应用”的含义。
 
 
-无状态应用（Stateless Applications）在运行时不依赖特定的状态信息，其实例之间没有区别。Kubernetes 使用 Deployment 编排无状态应用，假设所有 Pod 完全相同，没有顺序依赖，也无需关心运行在哪台宿主机上。相反的，有状态应用（Stateful Applications）每个实例都需要维护特定的状态：
-- **拓扑状态**：应用的多个实例之间并非完全对等关系。例如，在“主从”（Master-Slave）架构中，主节点 A 必须先于从节点 B 启动。若 A 和 B 两个 Pod 被删除后重新创建，也需严格遵循这一启动顺序。此外，新创建的 Pod 必须保留与原 Pod 相同的网络标识，以确保现有访问者能够通过原有的访问方式连接到新的 Pod。
-- **存储状态**：应用的多个实例分别绑定了独立的存储数据。对于这些实例而言，Pod A 无论是首次读取数据还是在被重新创建后再次读取，所获取的数据都必须保持一致。最典型的例子，就是一个数据库应用的多个存储实例，每个实例需要持久化数据到本地存储，如果实例迁移到了其他节点，服务就无法正常使用。
-
-Kubernetes v1.9 版本引入 StatefulSet 的核心功能就是用某种方式记录这些状态，当有状态应用的 Pod 重建后，仍然满足上一次运行状态的需求。
-
-通过 StatefulSet，有状态应用实现了安装、启动、停止等基础的运维操作。但对于其他高级运维操作，例如升级、扩容、备份、恢复、监控和故障转移，StatefulSet 并不能提供有效的帮助。其次，通过 StatefulSet 管理有状态应用，要定义相当多的配置，比如部署一套 etcd 集群，要设置节点通信端口、环境变量配置、持久化存储、网络策略、安全证书、健康检查等大量细节。
-
 
 如果使用 Operator，情况就简单得多。Etcd 的 Operator 提供了 EtcdCluster 自定义资源，在它的帮助下，仅用几十行代码，安装、启动、停止等基础的运维操作。但对于其他高级运维操作，例如升级、扩容、备份、恢复、监控和故障转移，如下面代码所示。
 

architecture/Immutable.md

@@ -21,7 +21,7 @@
 
 2013 年 6 月，Chad Fowler 撰写了一篇名为 《Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components》的文章，提出了 Immutable Infrastructure（不可变基础设施）的概念[^1]。这一前瞻性的构想，伴随着 Docker 容器技术的兴起、微服务架构的流行，得到了事实上的检验。
 
-不可变基础设施的核心思想是**任何基础设施的运行实例一旦创建之后就变成只读状态**。如需修改或升级，应该先修改基础设施的配置模版（例如 yaml、Dockerfile 配置），之后再使用新的运行实例替换。例如上面提到的 Nginx 升级案例，应该准备一个新的装有 Nginx 的 Linux 操作系统，而不是在 Linux 操作系统上原地更新。
+不可变基础设施思想的核心是，**任何基础设施的运行实例一旦创建之后就变成只读状态**。如需修改或升级，应该先修改基础设施的配置模版（例如 yaml、Dockerfile 配置），之后再使用新的运行实例替换。例如上面提到的 Nginx 升级案例，应该准备一个新的装有 Nginx 的 Linux 操作系统，而不是在 Linux 操作系统上原地更新。
 
 :::center
   ![](../assets/Immutable.png)<br/>

balance/summary.md

@@ -12,7 +12,7 @@
 
 以集群形式对外提供服务时，外界的请求无论由哪台服务器处理，都应获得一致的结果；另一方面，集群还需对外界保持足够的透明。也就是说，外界与集群交互时仿佛面对一台高性能、高可用的服务器。外界不会察觉到集群内部任何变动，比如增加或删除服务器、某个服务器故障等，也无需对应修改任何配置。
 
-为集群提供统一入口并实现上述职责的组件称为“负载均衡器”（或称代理）。负载均衡器是业内最活跃的领域之一，产品层出不穷（如专用网络设备、基于通用服务器的各类软件等）、部署拓扑多样（如中间代理型、边缘代理、客户端内嵌等）。无论其形式如何，所有负载均衡器的核心职责无外乎 “选择处理外界请求的目标”（即负载均衡算法）和“将外界请求转发至目标”（即负载均衡的工作模式），本章我们围绕这两个核心职责，深入理解负载均衡的工作原理。
+为集群提供访问入口并实现上述职责的组件称为“负载均衡器”（或称代理）。负载均衡器是业内最活跃的领域之一，产品层出不穷（如专用网络设备、基于通用服务器的各类软件等）、部署拓扑多样（如中间代理型、边缘代理、客户端内嵌等）。无论其形式如何，所有负载均衡器的核心职责无外乎 “选择处理外界请求的目标”（即负载均衡算法）和“将外界请求转发至目标”（即负载均衡的工作模式），本章我们围绕这两个核心职责，深入理解负载均衡的工作原理。
 :::center
   ![](../assets/balance-summary.png)<br/>
   图 4-0 本章内容导读

consensus/conclusion.md

@@ -2,7 +2,7 @@
 
 尽管 Paxos 是几十年前提出的算法，但它开创了分布式共识研究的先河。
 
-Paxos 基于“少数服从多数”（Quorum 机制）原则，通过“请求阶段”、“批准阶段”在不确定环境下协商达成一致决策，解决了单个“提案”的共识问题。运行多次 Paxos 便可实现一系列“提案”共识，这正是 Multi-Paxos 的核心思想。Raft 在 Multi-Paxos 思想之上，以工程实用性为目标，在一致性、安全性和可理解性之间找到平衡，成为分布式系统关键组件实现一致性的主流选择。
+Paxos 基于“少数服从多数”（Quorum 机制）原则，通过“请求阶段”、“批准阶段”在不确定环境下协商达成一致决策，解决了单个“提案”的共识问题。运行多次 Paxos 便可实现一系列“提案”共识，这正是 Multi-Paxos 思想的核心。Raft 在 Multi-Paxos 思想之上，以工程实用性为目标，在一致性、安全性和可理解性之间找到平衡，成为分布式系统关键组件实现一致性的主流选择。
 
 最后，再让我们思考一个问题，Raft 算法属于“强领导者”（Strong Leader）模型，领导者负责所有写入操作必限制整个 Raft 集群的写入性能，那如何突破 Raft 集群的写性能瓶颈呢？
 

distributed-transaction/idempotent.md

@@ -8,7 +8,7 @@
 
 ## 5.4.1 全局唯一 ID 方案
 
-全局唯一 ID 方案的核心思想是，为每个操作生成一个独一无二的标识符，以此判断是否已经执行过该操作。
+全局唯一 ID 方案思想的核心是，为每个操作生成一个独一无二的标识符，以此判断是否已经执行过该操作。
 
 全局唯一 ID 方案的操作步骤如下：
 

http/dns.md

@@ -6,11 +6,11 @@ DNS（Domain Name System，域名系统）是互联网中最重要的基础设
 - 7 月22 日，技术服务商 Aakamai 的 Edge DNS 服务故障，造成 PlayStation Network、HBO、UPS、Airbnb、Salesforce 等众多知名网站宕机[^1]；
 - 不久之后的 10 月 4 日，社交网络平台 Facebook 及旗下服务 Messenger、Instagram、WhatsApp、Mapillary 与 Oculus 发生全球性宕机[^2]。
 
-接下来，我们将了解域名解析的基本原理，学习在域名解析故障时如何排查问题。
+接下来，我们将分析域名解析的原理，掌握排查域名解析故障的手段。
 
 ## 2.3.1 域名解析的原理
 
-分析域名解析的过程之前，我们先了解域名的组成结构。
+分析域名解析原理之前，我们得先弄清楚解域名的结构。
 
 如图 2-2 所示，域名是一种树状结构，最顶层的域名是根域名（注意是一个点“.”，它是 .root 的含义，不过现在“.root”已经默认被隐藏），然后是顶级域名（Top Level Domain，简写 TLD，例如 .com），再是二级域名（例如 google.com）。
 
@@ -40,7 +40,7 @@ DNS（Domain Name System，域名系统）是互联网中最重要的基础设
 
 下面我们继续看看如果 DNS 解析出现故障了该如何排查。
 
-## 2.3.2 域名解析故障时排查
+## 2.3.2 排查域名解析故障
 
 如果请求一个 HTTPS 接口，出现服务不可用、Unknown host 等错误时，除了用 ping 测试连通性外，我们可以用 nslookup 或者 dig 命令确认域名解析是否出现问题。
 

network/vxlan.md

@@ -4,7 +4,7 @@
 
 从上述看出，基于物理设备实现的网络拓扑结构是相对固定的，很难跟得上云原生时代下系统频繁变动的频率。例如，容器的动态扩缩容、集群跨数据中心迁移等等，都要求网络拓扑随时做出调整。正因为如此，软件定义网络（Software Defined Networking，SDN）的需求变得前所未有的迫切。
 
-SDN 的核心思想是，在现有的物理网络之上新增一层虚拟网络，将控制平面（操作系统和各类网络控制软件等）和数据平面（底层通信的物理设备，以及各类通信协议等）解耦，将网络服务从底层硬件设备中抽象出来，由代码直接编程控制。
+SDN 思想的核心是，在现有的物理网络之上新增一层虚拟网络，将控制平面（操作系统和各类网络控制软件等）和数据平面（底层通信的物理设备，以及各类通信协议等）解耦，将网络服务从底层硬件设备中抽象出来，由代码直接编程控制。
 
 SDN 网络模型如图 3-16 所示：
 - 位于下层的网络称 Underlay 网络，它是由路由器、交换机等硬件设备互联而成的物理网络，负责网络之间的数据传输；