fix typo

container/borg-omega-k8s.md

@@ -1,4 +1,4 @@
-# 7.1 从 Borg 到 Kubernetes：容器编排系统的演进
+# 7.1 从 Borg 到 Kubernetes：容器编排系统的演变
 
 近几年，业界对容器技术兴趣越来越大，大量的公司开始逐步将虚拟机替换成容器。
 

container/conclusion.md

@@ -3,7 +3,7 @@
 本章，我们以 Google 内部容器系统演进作为开篇，深入讨论了 Kubernetes 网络、计算、存储、调度等方面的设计原理和应用。希望能让读者在 Kubernetes 这个复杂而庞大的项目中抓到主线，领悟到操作 YAML 文件背后的核心设计理念。
 
 在笔者看来，Kubernetes 的核心设计理念有两点：
-- 其一，从 API 到容器运行时的每一层，都为开发者暴露可供扩展的插件机制。通过 CNI 插件，把网络功能解耦，让外部参与容器网络的实现；通过 CSI 插件机制，建立了一套庞大的存储生态；通过 Device Plugin 把资源的支持扩展到 GPU、FPGA、DPDK、RDMA 等各类异构设备。依托这种开放性的设计，Kubernetes 社区出现了成千上万的插件，**让运维工程师可以轻松构建出功能强大的基础架构平台**。
-- 其二，在开放性的底层之上，Kubernetes 将所有接触的方方面面统一抽象为“资源”。所有的“资源”使用 YAML 文件描述，一个 YAML 文件即可表达出一个复杂基础设施的最终状态，并且自动地对应用进行运维和管理。这种设计**隐藏了底层细节，为业务工程师提供了一种友好、一致且跨平台的管理和部署应用的方式**。让云原生技术产生真正价值，正是 Kubernetes 设计哲学的精髓所在。
+- 其一，从 API 到容器运行时的每一层，都为开发者暴露可供扩展的插件机制。通过 CNI 插件把网络功能解耦，让外部的开发社区、厂商参与容器网络的实现；通过 CSI 插件建立了一套庞大的存储生态；通过 Device Plugin 把物理资源的支持扩展到 GPU、FPGA、DPDK、RDMA 等各类异构设备。依托这种开放性设计，Kubernetes 社区出现了成千上万的插件，**运维工程师可以轻松构建出功能强大的基础架构平台**。
+- 其二，在开放性的底层之上，Kubernetes 将所有接触的方方面面统一抽象为“资源”。所有的“资源”使用 YAML 文件描述，一个 YAML 文件即可表达一个复杂基础设施的最终状态，并且自动地对应用程序进行运维和管理。这种设计**隐藏了底层细节，为业务工程师提供了一种友好、一致且跨平台的管理应用程序的方式**。让云原生技术产生真正价值，正是 Kubernetes 设计哲学的精髓所在。
 
-接下来，笔者将继续介绍基于“容器设计模式”的二次创新，也就是近几年热度极高的服务网格（ServiceMesh）。
+接下来，笔者将继续介绍基于“容器设计模式”的二次创新，也就是近几年热度极高的“服务网格”（ServiceMesh）技术。

container/orchestration.md

@@ -1,8 +1,8 @@
-# 7.2 容器的原理与演进
+# 7.2 容器的原理与演变
 
 字面上，“容器”这个词难以让人形象地理解其真正含义，Kubernetes 中最核心的概念“Pod”也是如此。
 
-仅靠几句简单的解释并不足以让人充分理解这些概念，甚至可能引发误解，如业内常常将容器与轻量级虚拟机混为一谈。如果容器类似虚拟机，那么应该存在一种普适的方法，能够无缝地将虚拟机内的应用迁移至容器中，但现实中并不存在这种方法，都要经过大量适配、改造工作。
+仅靠几句简单的解释并不足以让人充分理解这些概念，甚至可能引发误解，如业内常常将容器与轻量级虚拟机混为一谈。如果容器类似虚拟机，那么应该存在一种普适的方法，能够无缝地将虚拟机内的应用程序迁移至容器中，但现实中并不存在这种方法，还是要经过大量适配、改造工作。
 
 本节，笔者将从最初的文件系统隔离开始，逐步介绍容器在不同历史阶段的作用，深入理解容器技术的演进，以及 Kubernetes 中最核心的概念 Pod 的设计背景和应用。
 

distributed-transaction/conclusion.md

@@ -1,11 +1,10 @@
-# 5.6 小结
+# 5.5 小结
 
 
 本章，我们首先了解事务的 ACID 特性，然后通过 CAP 定理探讨一致性、可用性和分区容错性之间的权衡关系。接着，介绍了在 CAP 定理约束下寻求平衡的弱一致性事务模型，如 BASE、TCC 和 SAGA。同时，补充了实施这些模型时必须考虑的“幂等性”原则，这是确保分布式事务在失败和重试情况下保持数据一致性的关键。
 
 此刻，你是否体会到“分布式事务的思想”。其实啊，其核心思想就是从悲观锁的强一致性事务，变成分阶段的锁的柔性事务。使用 TCC、SAGA 等机制，把事务控制从数据库资源层挪到业务服务层，弱化资源的锁定从而提升系统可用性。
 
-
 最终一致性保证不一致是暂时的，最终会达到一致。但这是一个非常脆弱的保证，它无法告诉我们系统何时收敛。而在收敛之前，读请求可能会返回任何值或者失败。对于应用开发人员而言，最终一致性会带来很大的处理挑战。
 
 最强的一种一致性模型，即线性化（Linearizability，也称原子一致性，最强一致性）。线性化确保分布式系统的操作表现得像是单机系统，也就是客户端无论向哪个节点发起读取请求，读到的数据都将反映最新的写操作结果。我们将在下一章展开讨论如何实现线性化。

network/conclusion.md

@@ -1,4 +1,4 @@
-# 3.7 小结
+# 3.6 小结
 
 本章我们通过 Linux 内核网络框架 netfilter 以及 iptables 、conntrack 等内容，了解了操作系统所设计的最基本的规则。随着虚拟化技术的发展，我们也看到了通过 Veth 实现基本的通信逻辑以及通过 MACVlan 和 IPVlan 子设备提升网密度并保证高效的方式应运而生。