fix typo

ServiceMesh/The-future-of-ServiceMesh.md

@@ -5,29 +5,29 @@
 - **网络延迟问题**：服务网格通过 iptables 拦截服务间的请求，将原本的 A->B 通信改为 A->（iptables+Sidecar）-> （iptables+Sidecar）->B，调用链的增加导致了额外的性能损耗。尽管 Sidecar 的引入通常只会增加毫秒级（个位数）的延迟，但对于对性能要求极高的业务来说，额外的延迟是放弃服务网格的主要原因。。
 - **资源占用问题**：Sidecar 作为一个独立的容器必然占用一定的系统资源，对于超大规模集群（如有数万个 Pod）来说，巨大的基数使 Sidecar 占用资源总量变得相当可观。
 
-为了解决上述问题，开发者们开始思考：“是否应该将服务网格与Sidecar划等号？”，并开始探索服务网格在形态上的其他可能性。
+为了解决上述问题，开发者们开始思考：“是否应该将服务网格与 Sidecar 划等号？”，并开始探索服务网格形态上的其他可能性。
 
 ## 8.7.1 Proxyless 模式
 
 既然问题出自代理，那就把代理去掉，这就是 Proxyless（无代理）模式。
 
-Proxyless 模式的设计理念是，服务间通信总是要选择一种协议，那么将实现协议的类库（SDK）扩展，增加通信治理能力，不就能代替 Sidecar 了吗？且 SDK 和应用封装在一起，必然有更优秀的性能表现，Sidecar 为人诟病的延迟问题将迎刃而解。
+Proxyless 模式的设计思想是，服务间通信总依赖某种协议，那么将协议的实现（SDK）扩展，增加通信治理能力，不就能代替 Sidecar 了吗？且 SDK 和应用封装在一起，不仅有更优异的性能，还能彻底解决 Sidecar 引发的延迟问题。
 
-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 所示，服务间通信治理不再依赖 Sidecar，而是采用原始的方式在 gRPC SDK 中实现。此外，该模式额外需要一个代理（Istio Agent）与控制平面（Control Plane）交互，告知 gRPC SDK 如何连接到 istiod、如何获取证书、处理流量的策略等。
 
 :::center
   ![](../assets/proxyless.svg)<br/>
  图 8-19 Proxyless 模式
 :::
 
-相比 Sidecar，Proxyless 模式在性能、稳定性、资源消耗低等方面具有明显的优势。根据官方公布的性能测试报告来看，gRPC Proxyless 模式下，延迟情况接近“基准”（baseline）、资源消耗也相对较低。
+相比 Sidecar，Proxyless 模式在性能、稳定性、资源消耗低等方面具有明显的优势。根据官方公布的性能测试报告来看，gRPC Proxyless 模式的延迟接近“基准”（baseline）、资源消耗也相对较低。
 
 :::center
   ![](../assets/latencies_p50.svg)<br/>
  图 8-20 Proxyless 性能测试报告（结果越低越好）
 :::
 
-回过头来看，所谓的 Proxyless 模式其实与传统的 SDK 并无太大区别，只是将通信治理逻辑内嵌至库中，有着与传统 SDK 服务框架的相同缺点。因此，许多人认为 Proxyless 模式本质上是一种倒退，是回归传统方式解决服务间通信问题。
+回过头来看，所谓的 Proxyless 模式与传统 SDK 并无本质区别，只是在库中内嵌了通信治理逻辑，也继承了传统 SDK 服务框架的固有缺陷。因此，许多人认为 Proxyless 模式实际上是一种倒退，是以传统方式重新解决服务间通信的问题。
 
 ## 8.7.2 Sidecarless 模式