修改章节内容

ServiceMesh/The-future-of-ServiceMesh.md

@@ -2,7 +2,7 @@
 
 服务网格的核心是 Sidecar，Sidecar 本质上是一个服务代理，通过劫持发送到应用容器的流量从而实现对流量的控制，随着服务网格落地实践，Sidecar 的缺点也逐渐被暴露：
 
-- **延迟问题**：Sidecar 常规的做法是使用 iptbales 实现请求的拦截。原本是 A->B，现在变成 A->iptables+sidecar->iptables+sidecar->B，调用链增加必然带来性能损耗。尽管从一些产品的 benchmark 结果看，Sidecar 的引入只会增加毫秒级（个位数）延迟，但对性能有极高要求的业务场景来说，延迟损耗就成为了放弃服务网格的最主要原因。
+- **延迟问题**：Sidecar 常规的做法是使用 iptbales 实现请求的拦截。服务之间的通信原本是 A->B，现在变成 A->iptables+sidecar->iptables+sidecar->B，调用链增加必然带来性能损耗。尽管一些产品的 benchmark 表明 Sidecar 的引入只会增加毫秒级（个位数）延迟，但对性能有极高要求的业务场景来说，延迟损耗就成为了放弃服务网格最主要的原因。
 - **资源占用问题**：Sidecar 作为一个独立的容器必然会占用一定的系统资源，对于超大规模集群（例如数万个 Pod）来说，巨大的基数使得 Sidecar 占用资源总量变成了不小的数目。同时，这类集群的网络通信拓扑也更加复杂，配置下发的规模也会让 Sidecar 占用的内存剧烈的增长。
 
 考虑解决以上的问题，社区的开发者开始重新思考是否应该将服务网格和 Sidecar 划上等号，同时继续探索服务网格形态上的其他可能性。
@@ -11,7 +11,7 @@
 
 既然问题是代理，那就把代理去掉，这就是 Proxyless（无代理）模式。
 
-Proxyless 理念是服务间总是要选择一种协议进行通信，就必然要依赖于该协议的类库（SDK）进行编解码工作。既然如此，那么将协议的类库扩展，使其具有流量控制的能力，不就能代替 Sidecar 代理了吗？且 SDK 和应用同属于同一进程，必然有更优秀的性能表现，Sidecar 最为诟病的延迟问题也会迎刃而解。
+Proxyless 理念是服务间总是要选择一种协议进行通信，就必然要依赖于该协议的类库（SDK）进行编解码工作。既然如此，那么将协议的类库扩展，使其具有流量控制的能力，不就能代替 Sidecar 代理了吗？且 SDK 和应用同属于同一进程，必然有更优秀的性能表现，Sidecar 诟病的延迟问题也会迎刃而解。
 
 2021 年 Istio 官方博客发表了一篇基于 gRPC 实现 Proxyless 的文章[^2]，阐述了其工作原理以及如何在 Istio 中使用它。在这种模式中，服务网格核心的流控能力被集成在 gRPC 库中，不再使用代理进行数据面通信。但这种方案仍然需要一个 Agent 进行初始化并与控制平面交互，负责告知 gRPC 库如何连接到 istiod，如何获取证书，并作为 xDS 代理，代表应用与 istiod 进行连接和认证。
 
@@ -22,15 +22,13 @@ Proxyless 理念是服务间总是要选择一种协议进行通信，就必然
 
 相比通过进程外通信的 Sidecar 代理来说，Proxyless 模式具有性能、稳定性、资源消耗低等明显的优势，官方博客给出的数据来看，gRPC Proxyless 模式下的延迟情况接近基准测试，资源消耗也相对较低。
 
-读者可能已经发现，所谓 Proxyless 其实和传统的 SDK 并无二致，只是将流控能力内嵌到负责通信协议的类库中，因此它具有和传统 SDK 服务框架相同的缺点，也正因为如此，业内很多人认为 Proxyless 本质上是一种倒退，是回归到传统的方式去解决服务通信的问题。
+不过，回过头再看，所谓 Proxyless 其实和传统的 SDK 并无二致，只是将流控能力内嵌到负责通信协议的类库中，因此它具有和传统 SDK 服务框架相同的缺点。所以，业内很多人认为 Proxyless 本质上是一种倒退，是回归到传统的方式去解决服务通信的问题。
 
 ## Ambient Mesh 模式
 
 2022 年 9 月 Istio 发布了一个名为 “Ambient Mesh” 的无边车数据平面模型，宣称用户无需使用 Sidecar 代理，就能将网格数据平面集成到其基础设施中，同时还能保持 Istio 零信任安全、遥测和流量治理等特性。
 
-为了避免 Sidecar 种种缺陷，Ambient Mesh 不再为任何 Pod 注入 Sidecar，而是将网格功能的实现进一步下沉到 Istio 的自有组件中。
-
-Ambient 将原本 Envoy 处理的功能分成两个不同的层次：安全覆盖层（ztunnel）和七层处理层（waypoint），如图 1-28 所示。
+为了避免 Sidecar 种种缺陷，Ambient Mesh 不再为任何 Pod 注入 Sidecar，而是将网格功能的实现进一步下沉到 Istio 的自有组件中。Ambient将原本 Envoy 处理的功能分成两个不同的层次：安全覆盖层（ztunnel）和七层处理层（waypoint），如图 1-28 所示。
 
 - ztunnel（Zero Trust Tunnel，零信任隧道）是 Ambient 新引入的组件，以 Daemonset 的方式部署在每个节点上，处于类似 CNI 网格底层 。ztunnel 为网格中的应用通信提供 mTLS、遥测、身份验证和 L4 授权功能，但不执行任何七层协议相关的处理。
 - 七层治理架构中新增了 waypoint 组件，为用户按需启用 L7 功能提供支持，以获得 Istio 的全部功能，例如限速、故障注入、负载均衡、熔断等。

container/orchestration.md

@@ -10,10 +10,10 @@
 
 ## 7.3.1 文件系统隔离
 
-1979年，Unix 系统引入了一个革命性的技术 —— chroot（chang root）。chroot 允许管理员将进程的根目录锁定在指定的位置，从而可以有效的限制该进程访问的文件系统范围。
+1979年，Unix 系统引入了一个革命性的技术 —— chroot（chang root）。chroot 允许管理员将进程的根目录锁定在指定的位置，从而限制该进程访问的文件系统范围。
 
 :::tip <i/>
-chroot 的隔离能力对安全性至关重要，比如创建一个隔离环境，用来安全地运行和监控可疑的代码或者程序，因此 chroot 之后的环境也被形象地称为监狱（jail）。
+chroot 的隔离能力对安全性至关重要，比如创建一个隔离环境，用来安全地运行和监控可疑的代码或者程序，因此 chroot 之后的环境也被形象地称为jail（监狱）。
 :::
 仅需几步，就能创建一个chroot环境。
 
@@ -24,7 +24,7 @@ $ cp /lib64/{ld-linux-x86-64.so*,libc.so*,libdl.so.2,libreadline.so*,libtinfo.so
 $ sudo chroot new-root
 ```
 
-这个 jail 用处不大，只有 bash 以及一些内置的函数，但也足以说明它的作用：运行在此 jail 下的进程的文件系统与宿主机隔离了。
+这个 jail 用处不大，只有 bash 以及一些内置的函数，但也足以说明它的作用：运行在此 jail 下进程的文件系统与宿主机隔离了。
 
 ```shell
 bash-4.2# cd bin 
@@ -34,9 +34,7 @@ bash-4.2# pwd
 
 :::tip 额外知识
 
-除了 /bin 之外，如果我们把程序依赖的 /etc，/proc 等等都打包进去，实际上就得到了一个 rootfs 文件。**由于 rootfs 里打包的不只是应用，而是整个操作系统的文件和目录，也就意味着，应用以及它运行所需要的所有依赖，都被封装在了一起**。
-
-正是由于 rootfs 的存在，容器才有了一个被反复宣传至今的重要特性：一致性。
+除了 /bin 之外，如果我们把程序依赖的 /etc，/proc 等等都打包进去，实际上就得到了一个 rootfs 文件。**由于 rootfs 里打包的不只是应用，而是整个操作系统的文件和目录，也就意味着，应用以及它运行所需要的所有依赖，都被封装在了一起**，这就是容器被反复宣传至今一致性的由来。
 :::
 
 我们再运行一个 docker，看看两者之间的区别。
@@ -48,13 +46,13 @@ root@028f46a5b7db:/# cd bin
 root@028f46a5b7db:/bin# pwd
 /bin
 ```
-看起来跟 chroot 差不多，也是一个与宿主机隔离的文件系统环境，那这是否意味着 chroot 就是容器了呢？肯定不是：**chroot 只是改变了根目录，而非创建了真正的独立隔离、安全的环境**，chroot 后的进程通过几行代码就能从当前的 jail 中逃逸，而且文件系统、网络、设备等等都没有被隔离。
+看起来跟 chroot 差不多，也是一个与宿主机隔离的文件系统环境，那这是否意味着 chroot 就是容器了呢？并不是，**chroot 只是改变了根目录，而非创建了真正的独立隔离、安全的环境**，chroot 后的进程通过几行代码就能从当前的 jail 中逃逸，而且文件系统、网络、设备等等都没有被隔离。
 
 ## 7.3.2 资源全方位隔离
 
 Chroot 最初的目的是为了实现文件的隔离，并非为了容器而设计。后来 Linux 吸收了Chroot的理念，先是在 2.4.19 引入了 Mount 命名空间，这样就可以隔离挂载文件系统。后来又想到进程间通信也需要隔离，就有了 IPC 命名空间。同时，容器还需要一个独立的主机名以便在网络中标识自己，有了网络，自然还要有独立的 IP、端口、路由等...。从 Linux 内核 2.6.19 起，又陆续添加了 UTS、IPC、PID、Network、User 等命名空间。
 
-至 Linux 内核 3.8 版本，Linux 已经完成容器所需的 6 项最基本资源隔离。
+至 Linux 内核 3.8 版本，Linux 已经完成容器所需的6项最基本资源隔离。
 
 表 7-1 Linux 目前支持的八类名称空间
 

distributed-transaction/summary.md

@@ -11,7 +11,7 @@
 
 提及事务，最早是指涉及操作多个资源的数据库事务问题，不过随着 SOA、微服务架构逐渐流行之后，分布式事务的概念也被泛化，事务的处理已经不再局限在数据库范围内，所有需要保证数据一致性的应用场景，包括但不限于缓存、消息队列、分布式存储、微服务架构之下的业务一致性处理等等都需要用到事务进行处理。
 
-**当事务的影响只局限在本地，如何实现事务仅是个编码问题，但如果涉及了多个服务，保证分布式系统下整体的原子性与一致性便成了架构设计问题**。2000 年以前，人们曾经希望 XA[^2] 的事务机制在分布式环境下也能良好的应用，但这个愿望被 CAP 定理彻底粉碎，分布式事务的篇章我们就从 ACID 与 CAP 的矛盾说起。
+**当事务的影响只局限在本地，如何实现事务仅是个编码问题，但如果涉及了多个服务，保证分布式系统下整体的原子性与一致性便成了架构设计问题**。2000 年以前，人们曾经希望 XA[^2] 的事务机制在分布式环境下也能良好的应用，但这个愿望被 CAP 定理粉碎，分布式事务的篇章我们就从 ACID 与 CAP 的矛盾说起。
 
 <div  align="center">
 	<img src="../assets/distributed-transaction-summary.png" width = "550"  align=center />

http/dns-ha.md

@@ -40,7 +40,7 @@ Facebook 官方在故障后续发布原因总结是：**运维人员修改 BGP 
 - 运维人员发布了错误的 BGP 路由公告。
 - 恰巧 Facebook 的权威解析服务器的 IP 包含在这部分路由中。
 
-这就导致域名解析请求无法路由到 Facebook 内部网络中。由于 DNS 出现问题，运维人员很难再通过远程的方式修复，修复团队只能是紧急跑到数据中心修复（道听途说是打了飞的过去），这就是此次故障影响巨大的原因。
+这就导致域名解析请求无法路由到 Facebook 内部网络中。由于 DNS 出现问题，运维人员很难再通过远程的方式修复，修复团队只能是紧急跑到数据中心修复（道听途说打了飞的过去）。
 
 Facebook 这次故障带给我们以下几点关于 DNS 系统设计的思考：
 

network/vxlan.md

@@ -29,9 +29,9 @@ VLAN 是一种早期的网络虚拟化技术，由于二层网络本身特性决
 
 ## VXLAN
 
-为了解决 VLAN 的设计缺陷，IETF 又重新定义了 VXLAN 规范，这是三层虚拟化网络（Network Virtualization over Layer 3，NVO3）的标准技术规范之一，是一种典型的 overlay 网络。
+为了解决 VLAN 的设计缺陷，IETF 又重新定义了 VXLAN 规范，这是三层虚拟化网络（Network Virtualization over Layer 3，NVO3）的标准技术规范之一。
 
-虽然从名字上看，VXLAN 是 VLAN 的一种扩展协议，但 VXLAN 内在已经与 VLAN 迥然不同，VXLAN 本质上是一种隧道封装技术，它使用 TCP/IP 协议栈的惯用手法「封装/解封装技术」，将 L2 的以太网帧（Ethernet frames）封装成 L4 的 UDP 数据报，然后在 L3 的网络中传输，效果就像 L2 的以太网帧在一个广播域中传输一样，不再受数据中心传输的限制。
+虽然从名字上看，VXLAN 是 VLAN 的一种扩展协议，但 VXLAN 内在已经与 VLAN 迥然不同，VXLAN 本质上是一种隧道封装技术，属于典型的 overlay 网络，它使用 TCP/IP 协议栈的惯用手法「封装/解封装技术」，将 L2 的以太网帧（Ethernet frames）封装成 L4 的 UDP 数据报，然后在 L3 的网络中传输，效果就像 L2 的以太网帧在一个广播域中传输一样，不再受数据中心传输的限制。
 
 <div  align="center">
 	<img src="../assets/vxlan-data.png" width = "300"  align=center />