fix typo

isno · Jan 29, 2025 · 5f2a692 · 5f2a692
1 parent c42ba68
commit 5f2a692
Show file tree

Hide file tree

Showing 4 changed files with 8 additions and 12 deletions.
diff --git a/ServiceMesh/MicroService-history.md b/ServiceMesh/MicroService-history.md
@@ -52,7 +52,7 @@
   图 8-5 SpringCloud 全家桶
 :::
 
-- **框架无法跨语言**：微服务框架通常只支持一种或几种特定的编程语言，而微服务定义中的关键特性就是和编程语言无关。如果你使用编程语言框架不支持，则很难融入这类微服务的架构体系。因此，微服务架构所提倡的：“因地制宜用多种编程语言实现不同模块”，也就成了空谈。
+- **框架无法跨语言**：微服务框架通常只支持一种或几种特定的编程语言，而微服务的关键特性是和编程语言无关。如果你使用的编程语言框架不支持，则很难融入这类微服务的架构体系。因此，微服务架构所提倡的：“因地制宜用多种编程语言实现不同模块”，也就成了空谈。
 
 - **框架升级困难**：微服务框架以 Lib 库的形式和服务联编，当项目非常复杂时，处理依赖库版本、版本兼容问题将非常棘手。同时，微服务框架的升级也无法对服务透明。服务稳定的情况下，工程师们普遍不愿意升级微服务框架。大部分的情况是，微服务框架某个版本出现 Bug 时，才被迫升级。
 

diff --git a/ServiceMesh/The-future-of-ServiceMesh.md b/ServiceMesh/The-future-of-ServiceMesh.md
@@ -11,7 +11,7 @@
 
 既然问题出自代理，那就把代理去掉，这就是 Proxyless（无代理）模式。
 
-Proxyless 模式的思想是，服务间通信总依赖某种协议，那么将协议的实现（SDK）扩展，增加通信治理能力，不就能代替边车代理了吗？且 SDK 和应用封装在一起，不仅有更优异的性能，还能彻底解决边车代理引发的延迟问题。
+Proxyless 模式的思想是，**服务间通信总依赖某种协议，那么将协议的实现（SDK）扩展，增加通信治理能力，不就能代替边车代理了吗**？且 SDK 和应用封装在一起，不仅有更优异的性能，还能彻底解决边车代理引发的延迟问题。
 
 2021 年，Istio 发表文章《基于 gRPC 的无代理服务网格》[^1]，介绍了一种基于 gRPC 实现的 Proxyless 模式的服务网格。它的工作原理如图 8-19 所示，服务间通信治理不再依赖边车代理，而是采用原始的方式在 gRPC SDK 中实现。此外，该模式额外需要一个代理（Istio Agent）与控制平面（Control Plane）交互，告知 gRPC SDK 如何连接到 istiod、如何获取证书、处理流量的策略等。
 
@@ -42,7 +42,7 @@ Cilium 无边车模式的服务网格工作原理如图 8-21 所示。在这种
  图 8-21 经过 eBPF 加速的服务网格和传统服务网格的区别
 :::
 
-传统的服务网格，如 Linkerd 和 Istio，通常依赖 Linux 内核网络协议栈来处理请求，而 Cilium 的无边车模式则基于 eBPF 技术在内核层面进行扩展，从而实现了天然的网络加速效果。根据图 8-22 所示的性能测试结果，基于 eBPF 加速的 Envoy 在性能上显著优于默认未加速的 Istio。
+传统的服务网格，如 Linkerd 和 Istio，通常依赖 Linux 内核网络协议栈来处理请求，而 **Cilium 的无边车模式则基于 eBPF 技术在内核层面进行扩展，从而实现了天然的网络加速效果**。根据图 8-22 所示的性能测试结果，基于 eBPF 加速的 Envoy 在性能上显著优于默认未加速的 Istio。
 
 :::center
   ![](../assets/cilium-istio-benchmark.webp)<br/>
@@ -71,24 +71,20 @@ Ambient Mesh 的设计理念是，将数据平面分为“安全覆盖层”（z
 - 安全：面向四层的简单授权策略、双向 TLS（即 mTLS）；
 - 观测：TCP 监控指标及日志。
 
-七层用于高级流量处理，特点是功能丰富（当然也需要更多的资源），它的功能包括：
+七层处理层用于高级流量处理，特点是功能丰富（当然也需要更多的资源），它的功能包括：
 - 流量管理： HTTP 路由、负载均衡、熔断、限流、故障容错、重试、超时等；
 - 安全：面向七层的精细化授权策略；
 - 观测：HTTP 监控指标、访问日志、链路追踪；
 
 
-在数据平面分层解耦的模式下，安全覆盖层的功能被转移至 ztunnel 组件，它以 DaemonSet 形式运行在 Kubernetes 集群的每个节点上。这意味着，ztunnel 是为节点内所有 Pod 提供服务的基础共享组件。
-
-另一方面，七层处理层不再以边车模式存在，而是按需为命名空间创建的 Waypoint 组件。Waypoint 组件以 Deployment 形式部署在 Kubernetes 集群中，从 Kubernetes 的角度来看，Waypoint 只是一个普通的 Pod，可以根据负载动态伸缩。业务 Pod 不再需要额外的边车容器即可参与网格，因此 Ambient 模式也被称为“无边车网格”。
+在数据平面分层解耦的模式下，安全覆盖层的功能被转移至 ztunnel 组件，它以 DaemonSet 形式运行在 Kubernetes 集群的每个节点上。这意味着，ztunnel 是为节点内所有 Pod 提供服务的基础共享组件。另一方面，七层处理层不再以边车模式存在，而是按需为命名空间创建的 Waypoint 组件。Waypoint 组件以 Deployment 形式部署在 Kubernetes 集群中，从 Kubernetes 的角度来看，Waypoint 只是一个普通的 Pod，可以根据负载动态伸缩。业务 Pod 不再需要额外的边车容器即可参与网格，因此 Ambient 模式也被称为“无边车网格”。
 
 :::center
   ![](../assets/Ambient-Mesh.svg)<br/>
   图 8-23 Ambient-Mesh 的工作原理
 :::
 
-Ambient 分层模式允许你以逐步递进的方式采用 Istio，你可以按需从无网格平滑过渡到安全的 L4 覆盖，再到完整的 L7 处理和策略。
-
-根据 Istio 公开的信息，Istio 一直在推进 Ambient Mesh 的开发，并在 2023 年 2 月将其合并到了 Istio 的主分支。这个举措在一定程度上表明，Ambient Mesh 并非实验性质的“玩具”，而是 Istio 未来发展的重要方向之一
+Ambient 分层模式允许你以逐步递进的方式采用 Istio，你可以按需从无网格平滑过渡到安全的 L4 覆盖，再到完整的 L7 处理和策略。根据 Istio 公开的信息，Istio 一直在推进 Ambient Mesh 的开发，并在 2023 年 2 月将其合并到了 Istio 的主分支。这个举措在一定程度上表明，**Ambient Mesh 并非实验性质的“玩具”，而是 Istio 未来发展的重要方向之一**。
 
 最后，无论是 Sidecarless 还是 Ambient Mesh，它们的设计本质上都是通过中心化代理替代位于应用容器旁边的代理容器。这在一定程度上解决了传统边车代理模式带来的资源消耗、网络延迟问题。但它们的缺陷也无法回避，服务网格的设计理念本来就很抽象，引入 Proxyless、Sidecarless、Ambient Mesh 等模式，进一步加大了服务网格的复杂性和理解难度。
 

diff --git a/ServiceMesh/conclusion.md b/ServiceMesh/conclusion.md
@@ -4,6 +4,6 @@
 
 从最初 TCP/IP 协议的出现，我们看到网络传输相关的逻辑从应用层剥离，下沉至操作系统，成为操作系统的网络层。分布式系统的崛起，又带来了特有的分布式通信语义（服务发现、负载均衡、限流、熔断、加密...）。为了降低治理分布式通信的心智负担，面向微服务的 SDK 框架出现了，但这类框架与业务逻辑耦合在一起，带来门槛高、无法跨语言、升级困难三个固有问题。
 
-而服务网格为分布式通信治理带来了全新的解决思路：通信治理逻辑从应用程序内部剥离至边车代理，下沉至 Kubernetes、下沉至各个云平台，在应用层与基础设施层之间衍生出全新的微服务治理层。沿着上述“分离/下沉”的设计理念，服务网格的形态不再局限于 Sidecar，开始多元化，出现了 Proxyless、Sidecarless、Ambient Mesh 等多种模式。
+而服务网格的出现为分布式通信治理带来了全新的解决思路：通信治理逻辑从应用程序内部剥离至边车代理，下沉至 Kubernetes、下沉至各个云平台，在应用层与基础设施层之间衍生出全新的微服务治理层。沿着上述“分离/下沉”的设计理念，服务网格的形态不再局限于边车代理，开始多元化，出现了 Proxyless、Sidecarless、Ambient Mesh 等多种模式。
 
 无论通信治理逻辑下沉至哪里、服务网格以何种形态存在，核心把非业务逻辑从应用程序中剥离，让业务开发更简单。这正是业内常提到的“以应用为中心”的软件设计核心理念。
diff --git a/ServiceMesh/control-plane.md b/ServiceMesh/control-plane.md
@@ -10,7 +10,7 @@ Istio 自发布首个版本以来，有着一套“堪称优雅”的架构设
 一方面，控制面组件的数量越多，排查问题时需要检查的故障点也就越多。另一方面，过多的组件设计也会增加部署、维护的复杂性。
 :::
 
-服务网格被誉为下一代微服务架构，用来解决微服务间的运维管理问题。但在服务网格的设计过程中，又引入了一套新的微服务架构。这岂不是“用一种微服务架构设计的系统来解决另一种微服务架构的治理问题”？那么，谁来解决 Istio 系统本身的微服务架构问题呢？
+服务网格被誉为下一代微服务架构，用来解决微服务间的运维管理问题。但在服务网格的设计过程中，又引入了一套新的微服务架构。这岂不是“**用一种微服务架构设计的系统来解决另一种微服务架构的治理问题**”？那么，谁来解决 Istio 系统本身的微服务架构问题呢？
 
 在 Istio 推出三年后，即 Istio 1.5 版本，开发团队对控制面架构进行了重大调整，摒弃了之前的设计，转而采用了“复古”的单体架构。组件 istiod 整合了 Pilot、Citadel 和 Galley 的功能，以单个二进制文件的形式部署，承担起之前组件的所有职责：