更新内容

architecture/ServiceMesh.md

@@ -2,7 +2,7 @@
 
 服务网格（Service Mesh）的概念最早由 Buoyant 公司的创始人 William Morgan 于 2016 年提出。
 
-2017 年 4 月，该公司发布了首个服务网格产品 Linkerd。同年，Morgan 的文章《What’s a service mesh? And why do I need one?》[^1]在互联网中开始广泛流传，这篇文章被认定为服务网格的权威定义。
+2017 年 4 月，该公司发布了首个服务网格产品 Linkerd。同年，Morgan 的文章《What’s a service mesh? And why do I need one?》[^1]在互联网中开始广泛流传，这篇文章内的解读被认定为服务网格的权威定义。
 
 :::tip 服务网格的定义
 
@@ -38,9 +38,9 @@ ServiceMesh 之所以称为服务网格，是因为每台节点同时运行着
 :::
 
 
-值得注意的是，尽管服务网格普遍使用 Sidecar 作为数据平面，但 Sidecar 模式并非服务网格所独有。
+值得注意的是，尽管服务网格的特点是 Sidecar 模式，但 Sidecar 模式并非服务网格专有。
 
-Sidecar 是一种常见的容器设计模式，在 Kubernetes 的工作负载 Pod 中可以运行多个容器，所有业务容器之外的其他容器均可称为 Sidecar 容器，如日志收集 Sidecar、请求代理 Sidecar 和链路追踪 Sidecar 等等。
+Sidecar 是一种常见的容器设计模式，Kubernetes 的工作负载 Pod 内可配置多个容器，业务容器之外的其他所有容器均可称为 Sidecar 容器。如日志收集 Sidecar、请求代理 Sidecar 和链路追踪 Sidecar 等等。
 
 如图 1-25 所示，app-container 是一个主业务容器，logging-agent 是一个日志收集的容器。主业务容器完全感知不到 logging-agent 的存在，它只负责输出日志，无需关心后续日志该怎么处理。你思考这样开发一个高内聚、低耦合的系统是否更加容易？
 

architecture/architect.md

@@ -2,7 +2,7 @@
 
 云原生架构是优雅的、灵活的、弹性的...，但不能否认这些优势的背后是它的学习曲线相当陡峭。
 
-如果你有志投入云原生领域，并希望能构建一个高可用的云原生架构，对能力要求已提升到史无前例的程度。总结来说，云原生实践中除掌握 Docker 和 Kubernetes，如图 1-34 所示，知晓以下几个领域尤佳。
+如果你有志投入云原生领域，希望构建一个高可用（高研发效率、低资源成本，且兼具稳定可靠）的云原生架构，对能力要求已提升到史无前例的程度。总结来说，除了掌握基础的 Docker 和 Kubernetes 知识外，知晓图 1-34 所示的几个领域更佳。
 
 :::center
   ![](../assets/cloud.svg)<br/>
@@ -22,6 +22,6 @@
 10. 可观测：OpenTelemetry。
 10. 机器学习/离在线业务混合部署：Volcano、Koordinator...。
 
-以上方案或相似或不同，适应什么场景、解决了什么问题、方案设计如何权衡，待笔者在本书后续章节一一道来。
+以上方案或相似或不同，适应什么场景、解决了什么问题、如何以最佳的姿势匹配业务，容笔者在本书后续章节一一道来。
 
 

architecture/devops.md

@@ -69,25 +69,27 @@ DevOps（Development 和 Operations 的合成词）是一种重视“软件开
 —— from 维基百科
 :::
 
-2009 年 DevOps 概念引入之时，基于“Development“和“Operations”合成一个新词“DevOps”，强调开发（指交付前的广义上的研发活动，包括测试等）与运维的融合，目的是实现快速交付价值且具有持续改进能力，其核心是用于打破研发和运维之间的隔阂、加快软件交付流程、提高软件质量。
+2009 年 DevOps 概念引入之时，基于“Development“和“Operations”合成一个新词“DevOps”，强调开发（指交付前的广义上的研发活动，包括设计、测试等）与运维融合，目的是打破开发和运维之间的隔阂、加快软件交付流程、提高软件质量。
 
 从存在的意义上说，DevOps 完善了敏捷开发存在的短板，实现了真正的闭环。
 
-DevOps 模式下，开发和运维都不再是“孤立”的团队，两者在软件的整个生命周期内相互协作，在工作中紧密地配合。由此带来的效益，则是更加高效的交付和更有品质的质量。
+DevOps 模式下，开发和运维不再是“孤立”的团队，两者在软件的整个生命周期内相互协作，工作中紧密地配合。由此带来的效益，则是更加高效的交付和更有品质的质量。
 
-如图 1-31 所示，DevOps 的出现打破开发和运维之间的壁垒，两者得以更加通畅的沟通，以清除部门之间的对立。
+如图 1-31 所示，DevOps 的出现打破开发和运维之间的壁垒，两者之间通畅沟通，清除了部门之间的对立。
 
 :::center
   ![](../assets/devops-2.jpg)<br/>
   图 1-31 Devops 打破开发和运维的对立
 :::
 
-不过，话虽如此，要实现这一点却不容易，因为这并非只是一次升级，而是需要在原有的文化和流程上进行大刀阔斧的变革：
+不过，话虽如此，要实现这一点却不容易，因为这并非只是一次升级，而是需要在原有的文化和流程上大刀阔斧的改革：
 
-- 首先是推行协作的文化，开发和运维之间不再是对立的关系，而应该是互相协作、深度交流并且彼此体谅的状态。
-- 开发流程方面，以往开发和运维各搞各的模式也需要改变。运维需要再项目开发的初始阶段就介入，了解开发所使用的系统架构和技术路线，并制定好相关的运维方案。而开发人员也需要参与到后期的系统部署和日常维护中，并提供优化建议。不仅仅是把代码甩给运维了事。
+- 首先是推行协作文化，研发和运维之间不再是对立的关系，应该是互相协作、深度交流并且彼此体谅的状态。
+- 开发流程方面，以往研发和运维各搞各的模式也需要改变：
+  - 运维需要在项目开发的初始阶段提前介入，了解开发所使用的系统架构和技术路线，并制定好相关的运维方案。
+  - 开发人员也需要参与到后期的系统部署和日常维护中，并提供优化建议。不仅仅是把代码甩给运维了事。
 
-DevOps 的成功实践离不开工具上的支持，这其中就包括最重要的自动化 CI/CD 流水线，通过自动化的方式打通软件从构建、测试到部署发布的整个流程。还有包括实时监控、事件管理、配置管理、协作平台等一系列工具的配合，如图 1-32 所示。
+DevOps 的成功实践离不开工具上的支持，这其中包括最重要的自动化 CI/CD 流水线，通过自动化的方式打通软件从构建、测试到部署发布的整个流程。还有实时监控、事件管理、配置管理、协作平台等一系列工具/系统的配合，如图 1-32 所示。
 
 :::center
   ![](../assets/devops.jpeg)<br/>

network/RDMA.md

@@ -2,9 +2,9 @@
 
 近几年，人工智能、分布式训练和分布式数据存储迅猛发展，对网络传输性能提出了更高的要求。
 
-但传统的以太网在网络延迟、吞吐量和CPU 资源消耗方面存在先天不足。此背景下，曾广泛应用于高性能计算领域的 RDMA（Remote Direct Memory Access，远程直接内存访问）技术，因其卓越的性能，逐渐成为满足这些需求的首选解决方案。
+但传统的以太网在网络延迟、吞吐量和 CPU 资源消耗方面存在先天不足。此背景下，广泛应用于高性能计算领域的 RDMA（Remote Direct Memory Access，远程直接内存访问）技术，因其卓越的性能，逐渐成为满足上述需求的首选解决方案。
 
-RDMA 是一种允许主机之间直接访问彼此内存的技术，其设计灵感来源于 DMA（Direct Memory Access，直接内存访问）。DMA 技术中，主机内部的设备（如硬盘或网卡）能够直接与内存交换数据，无需 CPU 参与；RDMA 的工作原理如图 3-10 所示，可以看出，应用程序通过专用的接口（RDMA Verbs API）绕过主机操作系统和 TCP/IP 协议栈，达到了直接访问远程主机内存的效果。
+RDMA 设计灵感来源于 DMA（Direct Memory Access，直接内存访问），是一种允许主机之间直接访问彼此内存的技术。DMA 技术中，无需 CPU 参与，主机内部的设备（如硬盘或网卡）能够直接与内存交换数据；RDMA 的工作原理如图 3-10 所示，应用程序通过专用的接口（RDMA Verbs API）绕过主机操作系统和 TCP/IP 协议栈，达到了直接访问远程主机内存的效果。
 
 :::center
   ![](../assets/RDMA.png)<br/>

network/conntrack.md

@@ -2,12 +2,12 @@
 
 conntrack 是 connection track（连接跟踪）的缩写。
 
-顾名思义，Linux 内核中的 conntrack 模块是用来跟踪“连接”的。需要注意的是，conntrack 中的“连接”指的是通信双方之间的数据传输连接，不仅可以跟踪 TCP 连接，还可以跟踪 UDP、ICMP 这样的“连接”。
+顾名思义，Linux 内核中的 conntrack 模块是用来跟踪“连接”的。需要注意的是，conntrack 中的“连接”指的是通信双方之间的数据传输连接，不仅跟踪 TCP 连接，还可以跟踪 UDP、ICMP 这样的“连接”。
 
-当 Linux 系统收到数据包时，内核中的 conntrack 模块为每个经过网络协议栈的数据包生成一个连接记录（或称连接条目），并标识其连接状态（如 NEW、ESTABLISHED 等）。用 TCP 三次握手的例子说明：
-- 首先，客户端向服务器发送一个 TCP SYN 包以请求建立连接。
-- Linux 系统收到 TCP SYN 包时，内核中的 conntrack 模块为其创建一个新的连接记录，并将状态标记为 NEW。
-- 随后，服务器回复一个 SYN-ACK，等待客户端的 ACK 报文。一旦 TCP 握手完成，连接记录中的状态将变为 ESTABLISHED。
+当 Linux 系统收到数据包时，内核中的 conntrack 模块为其新建一个（或标识属于某个）连接记录（或称连接条目），并根据数据包类型更新连接状态（如 NEW、ESTABLISHED 等）。用 TCP 三次握手的例子说明：
+- 首先，客户端向服务器发送一个 TCP SYN 包请求建立连接。
+- Linux 系统收到 TCP SYN 包时，内核中的 conntrack 模块为其创建一个新的连接记录，并将状态标记成 NEW。
+- 随后，服务器回复一个 SYN-ACK，等待客户端的 ACK 报文。一旦 TCP 握手完成，连接记录中的状态变成 ESTABLISHED。
 
 通过命令 cat /proc/net/nf_conntrack 查看连接记录，输出了一个连接类型为 TCP，连接状态为 ESTABLISHED 的连接记录。
 
@@ -38,5 +38,5 @@ conntrack 模块维护的连接记录包含了从客户端到 Pod 的 DNAT 映
   图 3-5 请求和响应不在一个“频道”上，双方通信失败
 :::
 
-针对上述问题，Linux 内核提供了 bridge-nf-call-iptables 配置，决定 Linux 网桥中的数据包是否触发 iptables 规则匹配。也就是处理 NAT 保证 conntrack 连接记录的完整性。这也解释了为什么部署 Kubernetes 集群时，务必开启 Linux 系统配置 bridge-nf-call-iptables（设置为 1）的原因。
+针对上述问题，Linux 内核开放了 bridge-nf-call-iptables 配置，决定 Linux 网桥中的数据包是否触发 iptables 匹配规则。也就是处理 NAT 保证 conntrack 连接记录的完整性。这也解释了为什么部署 Kubernetes 集群时，务必开启 Linux 系统配置 bridge-nf-call-iptables（设置为 1）的原因。