fix typo

ServiceMesh/MicroService-history.md

@@ -104,7 +104,7 @@ Linkerd 开创先河的不绑定任何基础架构或某类技术体系，实现
 
 第一代服务网格由一系列独立运行的代理型服务（Sidecar）构成，但并没有思考如何系统化管理这些代理服务。为了提供统一的运维入口，服务网格继续演化出了集中式的控制面板（Control Plane）。
 
-典型的第二代服务网格以 Google、IBM 和 Lyft 联合开发的 Istio 为代表。根据 Istio 的总体架构（见图 8-8），第二代服务网格由两大核心组成部分：一系列与微服务共同部署的边车代理，以及用于管理这些代理的控制器。代理间需要通信以转发程序间的数据包，而代理与控制器之间则通过通信传递路由、熔断策略、服务发现等控制信息。
+典型的第二代服务网格以 Google、IBM 和 Lyft 联合开发的 Istio 为代表。根据 Istio 的总体架构（见图 8-8），第二代服务网格由两大核心组成部分：一系列与微服务共同部署的边车代理（称为数据平面），以及用于管理这些代理的控制器（称为控制平面）。控制器向代理下发路由、熔断策略、服务发现等策略信息，代理根据这些策略处理服务间的请求。
 
 :::center
   ![](../assets/6-b.png)<br/>

ServiceMesh/The-future-of-ServiceMesh.md

@@ -1,26 +1,26 @@
 # 8.6 服务网格的未来
 
-随着服务网格的逐步落地，Sidecar 模式的缺点也逐渐显现：
+随着服务网格的逐步落地，边车代理的缺点也逐渐显现：
 
-- **网络延迟问题**：服务网格通过 iptables 拦截服务间的请求，将原本的 A->B 通信改为 A->（iptables+Sidecar）-> （iptables+Sidecar）->B，调用链的增加导致了额外的性能损耗。尽管 Sidecar 的引入通常只会增加毫秒级（个位数）的延迟，但对于对性能要求极高的业务来说，额外的延迟是放弃服务网格的主要原因。。
-- **资源占用问题**：Sidecar 作为一个独立的容器必然占用一定的系统资源，对于超大规模集群（如有数万个 Pod）来说，巨大的基数使 Sidecar 占用资源总量变得相当可观。
+- **网络延迟问题**：服务网格通过 iptables 拦截服务间的请求，将原本的 A->B 通信改为 A->（iptables+Sidecar）-> （iptables+Sidecar）->B，调用链的增加导致了额外的性能损耗。尽管边车代理通常只会增加毫秒级（个位数）的延迟，但对性能要求极高的业务来说，额外的延迟是放弃服务网格的主要原因；
+- **资源占用问题**：边车代理作为一个独立的容器必然占用一定的系统资源，对于超大规模集群（如有数万个 Pod）来说，巨大的基数使边车代理占用资源总量变得相当可观。
 
-为了解决上述问题，开发者们开始思考：“是否应该将服务网格与 Sidecar 划等号？”，并开始探索服务网格形态上的其他可能性。
+为了解决上述问题，开发者们开始思考：“是否应该将服务网格与边车代理划等号？”，并开始探索服务网格形态上的其他可能性。
 
 ## 8.7.1 Proxyless 模式
 
 既然问题出自代理，那就把代理去掉，这就是 Proxyless（无代理）模式。
 
-Proxyless 模式的设计思想是，服务间通信总依赖某种协议，那么将协议的实现（SDK）扩展，增加通信治理能力，不就能代替 Sidecar 了吗？且 SDK 和应用封装在一起，不仅有更优异的性能，还能彻底解决 Sidecar 引发的延迟问题。
+Proxyless 模式的思想是，服务间通信总依赖某种协议，那么将协议的实现（SDK）扩展，增加通信治理能力，不就能代替边车代理了吗？且 SDK 和应用封装在一起，不仅有更优异的性能，还能彻底解决边车代理引发的延迟问题。
 
-2021 年，Istio 发表文章《基于 gRPC 的无代理服务网格》[^1]，介绍了一种基于 gRPC 实现的 Proxyless 模式的服务网格。它的工作原理如图 8-19 所示，服务间通信治理不再依赖 Sidecar，而是采用原始的方式在 gRPC SDK 中实现。此外，该模式额外需要一个代理（Istio Agent）与控制平面（Control Plane）交互，告知 gRPC SDK 如何连接到 istiod、如何获取证书、处理流量的策略等。
+2021 年，Istio 发表文章《基于 gRPC 的无代理服务网格》[^1]，介绍了一种基于 gRPC 实现的 Proxyless 模式的服务网格。它的工作原理如图 8-19 所示，服务间通信治理不再依赖边车代理，而是采用原始的方式在 gRPC SDK 中实现。此外，该模式额外需要一个代理（Istio Agent）与控制平面（Control Plane）交互，告知 gRPC SDK 如何连接到 istiod、如何获取证书、处理流量的策略等。
 
 :::center
   ![](../assets/proxyless.svg)<br/>
- 图 8-19 Proxyless 模式
+ 图 8-19 Proxyless 模式的工作原理
 :::
 
-相比 Sidecar，Proxyless 模式在性能、稳定性、资源消耗低等方面具有明显的优势。根据官方公布的性能测试报告来看，gRPC Proxyless 模式的延迟接近“基准”（baseline）、资源消耗也相对较低。
+相比边车代理模式，Proxyless 模式在性能、稳定性、资源消耗低等方面具有明显的优势。根据官方公布的性能测试报告来看，该模式的延迟接近“基准”（baseline）、资源消耗也相对较低。
 
 :::center
   ![](../assets/latencies_p50.svg)<br/>
@@ -35,59 +35,62 @@ Proxyless 模式的设计思想是，服务间通信总依赖某种协议，那
 
 2022 年 7 月，专注于容器网络领域的开源软件 Cilium 发布了 v1.12 版本。该版本最大的亮点是实现了一种无边车模式的服务网格。
 
-Cilium Sidecarless 模式的服务网格工作原理如图 8-21 所示。首先，Cilium 在节点中运行一个 Enovy 实例，作为所有容器的共享代理，这样每个 Pod 内就不需要放置一个 Sidecar 了。然后，借助 Cilium CNI 底层网络能力，当业务容器的数据包经过内核时，与节点中的共享代理打通，从而构建出一种全新形态的服务网格。
+Cilium 无边车模式的服务网格工作原理如图 8-21 所示。在这种模式下，Cilium 在节点中运行一个共享的 Envoy 实例，作为所有容器的代理，从而避免了每个 Pod 配置独立边车代理的需求。通过 Cilium CNI 提供的底层网络能力，当业务容器的数据包经过内核时，它们与节点中的共享代理进行连接，进而构建出一种全新的服务网格形态。
 
 :::center
   ![](../assets/sidecarless.svg)<br/>
  图 8-21 经过 eBPF 加速的服务网格和传统服务网格的区别
 :::
 
-传统的服务网格 Linkerd、Istio 等几乎都是借助 Linux 内核网络协议栈处理请求，而 Cilium Sidecarless 模式基于 eBPF 技术在内核层面扩展，因此有着天然的网络加速效果。根据图 8-22 所示的性能测试来看，基于 eBPF 加速的 Envoy，比默认没有任何加速 Istio 要好很多。
+传统的服务网格，如 Linkerd 和 Istio，通常依赖 Linux 内核网络协议栈来处理请求，而 Cilium 的无边车模式则基于 eBPF 技术在内核层面进行扩展，从而实现了天然的网络加速效果。根据图 8-22 所示的性能测试结果，基于 eBPF 加速的 Envoy 在性能上显著优于默认未加速的 Istio。
 
 :::center
   ![](../assets/cilium-istio-benchmark.webp)<br/>
  图 8-22 Cilium Sidecarless 模式与 Istio Sidecar 模式的性能测试（结果越低越好） [图片来源](https://isovalent.com/blog/post/2022-05-03-servicemesh-security/)
 :::
 
-回过头看，Cilium Sidecarless 模式设计思路上其实和 Proxyless 如出一辙。即用一种非 Sidecar 的方式实现流量控制能力。两者的区别是：
-- 一个基于通信协议类库；
-- 另外一个基于共享代理，通过 eBPF 的 Linux 内核扩展技术实现。
+
+回过头来看，Cilium Sidecarless 模式的设计思路与 Proxyless 模式非常相似，都是通过非边车代理的方式实现流量控制。两者的区别在于：
+
+- Proxyless 基于通信协议库；
+- Cilium Sidecarless 则通过共享代理，利用 eBPF 技术在 Linux 内核层面实现。
 
 但同样，软件领域没有银弹，eBPF 不是万能钥匙，它存在 Linux 内核版本要求高、代码编写难度大和容易造成系统安全隐患等问题。
 
 ## 8.7.3 Ambient Mesh 模式
 
 2022 年 9 月，服务网格 Istio 发布了一种全新的数据平面模式 “Ambient Mesh”[^2]。
 
-以往 Istio 的设计中，Sidecar 实现了从基本加密到高级 L7 策略所有数据平面功能。实践中，这使得 Sidecar 成为一个 0 和 1 的命题（要么全有，要么全无），即使服务对传输安全性要求不高，工程师们仍然需要付出部署和维护 Sidecar 的额外成本。
+在以往的 Istio 设计中，边车代理实现了从基本加密到高级 L7 策略的所有数据平面功能。这种设计使得边车代理成为一个“全有或全无”的方案，即使服务对传输安全性要求较低，工程师仍需承担部署和维护完整边车代理的额外成本。
 
-Ambient Mesh 的设计理念是：将数据平面分层，分为“安全覆盖层”（ztunnel）和七层处理层（waypoint 代理）。
+Ambient Mesh 的设计理念是，将数据平面分为“安全覆盖层”（ztunnel）和七层处理层（waypoint 代理）。
 
-四层用于基础处理，特点是低资源、高效率。它的功能包括：
+安全覆盖层用于基础处理，特点是低资源、高效率。它的功能包括：
 
-- 流量管理：TCP 路由
-- 安全：面向四层的简单授权策略、双向 TLS（即 mTLS）
-- 可观测性：TCP 监控指标及日志
+- 流量管理：TCP 路由；
+- 安全：面向四层的简单授权策略、双向 TLS（即 mTLS）；
+- 观测：TCP 监控指标及日志。
 
 七层用于高级流量处理，特点是功能丰富（当然也需要更多的资源），它的功能包括：
-- 流量管理： HTTP 路由、负载均衡、熔断、限流、故障容错、重试、超时等
-- 安全：面向七层的精细化授权策略
-- 可观测：HTTP 监控指标、访问日志、链路追踪
+- 流量管理： HTTP 路由、负载均衡、熔断、限流、故障容错、重试、超时等；
+- 安全：面向七层的精细化授权策略；
+- 观测：HTTP 监控指标、访问日志、链路追踪；
+
 
-在数据平面在分层解耦的模式下，安全覆盖层的能力下移至 CNI 组件中，ztunnel 在 Kubernetes 集群以 DaemonSet 的形式运行在每个节点中。这意味着，它为节点内所有的 Pod 提供服务的基础共享组件。
+在数据平面分层解耦的模式下，安全覆盖层的功能被转移至 ztunnel 组件，它以 DaemonSet 形式运行在 Kubernetes 集群的每个节点上。这意味着，ztunnel 是为节点内所有 Pod 提供服务的基础共享组件。
 
-另一方面，七层处理层不再以 Sidecar 模式存在，而是解耦出来，成为按需为命名空间创建的七层代理 Pod。Waypoint 组件在 Kubernetes 集群中以 Deployment 的形式部署，从 Kubernetes 的角度来看，Waypoint 只是个普通的 Pod，可以根据负载动态伸缩。业务 Pod 不再需要在 Sidecar 中运行代理才能参与网格，因此 Ambient 模式通常也被称为“无 Sidecar 网格”。
+另一方面，七层处理层不再以边车模式存在，而是按需为命名空间创建的 Waypoint 组件。Waypoint 组件以 Deployment 形式部署在 Kubernetes 集群中，从 Kubernetes 的角度来看，Waypoint 只是一个普通的 Pod，可以根据负载动态伸缩。业务 Pod 不再需要额外的边车容器即可参与网格，因此 Ambient 模式也被称为“无边车网格”。
 
 :::center
   ![](../assets/Ambient-Mesh.svg)<br/>
-  图 8-23 Ambient-Mesh
+  图 8-23 Ambient-Mesh 的工作原理
 :::
 
 Ambient 分层模式允许你以逐步递进的方式采用 Istio，你可以按需从无网格平滑过渡到安全的 L4 覆盖，再到完整的 L7 处理和策略。
 
 根据 Istio 公开的信息，Istio 一直在推进 Ambient Mesh 的开发，并在 2023 年 2 月将其合并到了 Istio 的主分支。这个举措在一定程度上表明，Ambient Mesh 并非实验性质的“玩具”，而是 Istio 未来发展的重要方向之一
 
-无论是 Sidecarless 还是 Ambient Mesh，它们的设计思路本质是：用中心化的代理，替代位于应用容器旁边的 Sidecar 代理。这在一定程度上解决了传统 Sidecar 模式带来的资源消耗、网络延迟问题。但反面是，服务网格的设计理念本来就很抽象，引入 Proxyless、Sidecarless、Ambient Mesh 等模式，让原本抽象的设计更加难以理解。
+最后，无论是 Sidecarless 还是 Ambient Mesh，它们的设计本质上都是通过中心化代理替代位于应用容器旁边的代理容器。这在一定程度上解决了传统边车代理模式带来的资源消耗、网络延迟问题。但它们的缺陷也无法回避，服务网格的设计理念本来就很抽象，引入 Proxyless、Sidecarless、Ambient Mesh 等模式，进一步加大了服务网格的复杂性和理解难度。
 
 [^1]: 参见 https://istio.io/latest/zh/blog/2021/proxyless-grpc/
 [^2]: 参见 https://istio.io/latest/zh/blog/2023/ambient-merged-istio-main/

ServiceMesh/conclusion.md

@@ -1,6 +1,6 @@
 # 8.7 小结
 
-在本章第二节，我们回顾了服务间通信的演变，并阐述了服务网格出现的背景。相信你已经理解，服务网格之所以受到青睐，关键不在于它提供了多少功能（这些功能传统 SDK 框架也有），而在于其将非业务逻辑从应用程序中剥离的设计思想。
+在本章第二节，我们回顾了服务间通信的演变，并阐述了服务网格出现的背景。相信你已经理解，服务网格之所以备受推崇，关键不在于它提供了多少功能（这些功能传统 SDK 框架也有），而在于其将非业务逻辑从应用程序中剥离的设计思想。
 
 从最初 TCP/IP 协议的出现，我们看到网络传输相关的逻辑从应用层剥离，下沉至操作系统，成为操作系统的网络层。分布式系统的崛起，又带来了特有的分布式通信语义（服务发现、负载均衡、限流、熔断、加密...）。为了降低治理分布式通信的心智负担，面向微服务的 SDK 框架出现了，但这类框架与业务逻辑耦合在一起，带来门槛高、无法跨语言、升级困难三个固有问题。
 

ServiceMesh/control-plane.md

@@ -4,32 +4,32 @@
 
 Istio 自发布首个版本以来，有着一套“堪称优雅”的架构设计，它的架构由数据面和控制面两部分组成，前者通过代理组件 Envoy 负责流量处理；后者根据功能职责不同，由多个微服务（如 Pilot、Galley、Citadel、Mixer）组成。 Istio 控制面组件的拆分设计看似充分体现了微服务架构的优点，如职责分离、独立部署和伸缩能力，但在实际场景中，并未实现预期的效果。
 
-:::tip 服务网格控制面的问题
+:::tip Isito 控制平面的问题
 当业务调用出现异常时，由于接入了服务网格，工程师首先需要排查控制面内各个组件的健康状态：首先检查 Pilot 是否正常工作，配置是否正确下发至 Sidecar；然后检查 Galley 是否正常同步服务实例信息；同时，还需要确认 Sidecar 是否成功注入。
 
 一方面，控制面组件的数量越多，排查问题时需要检查的故障点也就越多。另一方面，过多的组件设计也会增加部署、维护的复杂性。
 :::
 
 服务网格被誉为下一代微服务架构，用来解决微服务间的运维管理问题。但在服务网格的设计过程中，又引入了一套新的微服务架构。这岂不是“用一种微服务架构设计的系统来解决另一种微服务架构的治理问题”？那么，谁来解决 Istio 系统本身的微服务架构问题呢？
 
-在 Istio 推出三年后，即 Istio 1.5 版本，开发团队对控制面架构进行了重大调整，摒弃了之前的设计，转而采用了“复古”的单体架构。新的统一组件 istiod 整合了 Pilot、Citadel 和 Galley 的功能，并以单个二进制文件的形式进行部署，承担起之前各个组件的所有职责：
+在 Istio 推出三年后，即 Istio 1.5 版本，开发团队对控制面架构进行了重大调整，摒弃了之前的设计，转而采用了“复古”的单体架构。组件 istiod 整合了 Pilot、Citadel 和 Galley 的功能，以单个二进制文件的形式部署，承担起之前组件的所有职责：
 
-- **服务发现与配置分发**：从 Kubernetes 等平台获取服务信息，将路由规则和策略转换为 xDS 协议下发至 Envoy 代理。
-- **流量管理**：管理流量路由规则，包括负载均衡、分流、镜像、熔断、超时与重试等功能。
-- **安全管理**：生成、分发和轮换服务间的身份认证证书，确保双向 TLS 加密通信；基于角色的访问控制（RBAC）和细粒度的授权策略，限制服务间的访问权限。
-- **可观测性支持**：协助 Envoy 采集运行时指标（如延迟、错误率、请求流量等），并将数据发送到外部监控系统（如 Prometheus）；支持分布式追踪系统（如 Jaeger、Zipkin 和 OpenTelemetry），帮助分析跨服务调用链路；提供访问日志和事件日志的采集功能。
-- **配置验证与管理**：验证用户提交的网格配置，并将其分发到数据平面，确保一致性和正确性。
+- **服务发现与配置分发**：从 Kubernetes 等平台获取服务信息，将路由规则和策略转换为 xDS 协议下发至 Envoy 代理；
+- **流量管理**：管理流量路由规则，包括负载均衡、分流、镜像、熔断、超时与重试等功能；
+- **安全管理**：生成、分发和轮换服务间的身份认证证书，确保双向 TLS 加密通信、基于角色的访问控制（RBAC）和细粒度的授权策略，限制服务间的访问权限；
+- **可观测性支持**：协助 Envoy 采集系统输出的遥测数据（日志、指标、追踪），并将数据发送到外部监控系统（如 Prometheus、Jaeger、OpenTelemetry 等）；
+- **配置验证与管理**：验证用户提交的网格配置，并将其分发到数据平面，确保一致性和正确性；
 
 :::center
   ![](../assets/service-mesh-arc.svg)<br/>
   图 8-12 Istio 架构及各个组件
 :::
 
-Istio 1.5 版本的架构变化，实际上是将原有的多进程设计转换为单进程模式，以最小的成本实现最高的运维收益。
+Istio 1.5 版本的架构变化，实际上是将原有的多进程设计转换为单进程模式，以最小的成本实现最高的运维收益：
 
 - 运维配置变得更加简单，用户只需要部署或升级一个单独的服务组件；
 - 更加容易排查错误，因为不需要再横跨多个组件去排查各种错误；
 - 更加利于做灰度发布，因为是单一组件，可以非常灵活切换至不同的控制面；
-- 避免了组件间的网络开销，因为组件内部可直接共享缓存、配置等，也会降低资源开销；
+- 避免了组件间的网络开销，因为组件内部可直接共享缓存、配置等，也会降低资源开销。
 
-通过以上分析，你是否对 Istio 控制平面的拆分架构有了新的理解？看似优雅的架构设计，落地过程中往往给运维和开发人员带来意料之外的困难。正如一句老话，没有完美的架构，只有最合适的架构！
+通过以上分析，你是否对 Istio 控制平面的拆分架构有了新的理解？看似优雅的架构设计，落地过程中往往给工程师带来意料之外的困难。正如一句老话，没有完美的架构，只有最合适的架构！