diff --git a/ServiceMesh/The-future-of-ServiceMesh.md b/ServiceMesh/The-future-of-ServiceMesh.md index 47328dac..39ef8eb0 100644 --- a/ServiceMesh/The-future-of-ServiceMesh.md +++ b/ServiceMesh/The-future-of-ServiceMesh.md @@ -2,8 +2,8 @@ 随着服务网格落地实践，Sidecar 模式的缺点逐渐被暴露出来： -- **网络延迟问题**：服务网格使用 iptables 拦截服务间的请求，服务之间的通信原本是 A->B，现在变成 A->iptables+Sidecar->iptables+Sidecar->B，调用链的增加也带来了额外的性能损耗。虽然 Sidecar 的引入只会增加毫秒级（个位数）延迟，但对性能有极高要求的业务来说，延迟损耗成为了放弃服务网格最主要的原因。 -- **资源占用问题**：Sidecar 作为一个独立的容器必然会占用一定的系统资源，对于超大规模集群（例如有数万个 Pod）来说，巨大的基数使得 Sidecar 占用资源总量变成了不小的数目。 +- **网络延迟问题**：服务网格使用 iptables 拦截服务间的请求，服务之间的通信原本是 A->B，现在变成 A->iptables+Sidecar->iptables+Sidecar->B，调用链的增加也带来了额外的性能损耗。虽然 Sidecar 的引入只会增加毫秒级（个位数）延迟，但对性能有极高要求的业务来说，额外的延迟损耗是放弃服务网格最主要的原因。 +- **资源占用问题**：Sidecar 作为一个独立的容器必然占用一定的系统资源，对于超大规模集群（如有数万个 Pod）来说，巨大的基数使 Sidecar 占用资源总量变成了不小的数目。 考虑解决以上的问题，开发者们思考：“是否应该将服务网格和 Sidecar 划上等号？”，开始探索服务网格形态上的其他可能性。 @@ -11,7 +11,7 @@ 既然问题出自代理，那就把代理去掉，这就是 Proxyless（无代理）模式。 -Proxyless 模式的设计理念是，服务间通信总是要选择一种协议进行，那么将协议的类库（SDK）扩展，使其具有流量控制的能力，不就能代替 Sidecar 代理了吗？且 SDK 和应用同属于一个进程，必然有更优秀的性能表现，Sidecar 为人诟病的延迟问题将迎刃而解。 +Proxyless 模式的设计理念是，服务间通信总是要选择一种协议，那么将实现协议的类库（SDK）扩展，增加通信治理能力，不就能代替 Sidecar 了吗？且 SDK 和应用封装在一起，必然有更优秀的性能表现，Sidecar 为人诟病的延迟问题将迎刃而解。 2021 年，Istio 官方博客发表了一篇文章 《基于 gRPC 的无代理服务网格》[^1]，文中介绍了一种基于 gRPC 框架实现的 Proxyless 模式的服务网格。该模式的工作原理如图 8-19 所示，服务间通信治理不再依赖 Sidecar，而是采用原始的方式，也就是在 gRPC 库中实现。此外，该模式需要额外一个代理（图中的 Istio Agent）通过 xDS 协议与控制平面交互，负责告知 gRPC 库如何连接到 istiod、如何获取证书、处理流量的策略等。 @@ -87,7 +87,7 @@ Ambient 分层模式允许你以逐步递进的方式采用 Istio，你可以按 根据官方的博客信息，Istio 一直在推进 Ambient Mesh 的开发，并在 2023 年 2 月将其合并到了 Istio 的主分支。这个动作一定程度上说明了 Ambient Mesh 不是什么实验性质的“玩具”，而是 Istio 的未来发展方向之一。 -无论是 Sidecarless 还是 Ambient Mesh，它们的设计思路本质是：用中心化的代理，替代位于应用容器旁边的 Sidecar 代理。这在一定程度上解决了传统 Sidecar 模式带来的资源消耗、网络延迟问题。但反面是，服务网格的设计理念本来就很抽象，引入 Proxyless、Sidecarless、Ambient Mesh 等模式，使本已复杂的设计更难以理解。 +无论是 Sidecarless 还是 Ambient Mesh，它们的设计思路本质是：用中心化的代理，替代位于应用容器旁边的 Sidecar 代理。这在一定程度上解决了传统 Sidecar 模式带来的资源消耗、网络延迟问题。但反面是，服务网格的设计理念本来就很抽象，引入 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/ diff --git a/architecture/ServiceMesh.md b/architecture/ServiceMesh.md index 2857c4af..bdd8d8f2 100644 --- a/architecture/ServiceMesh.md +++ b/architecture/ServiceMesh.md @@ -19,7 +19,7 @@ ServiceMesh 之所以称为“服务网格”，是因为每台节点同时运 图 1-22 边车示例 ::: -服务网格的关键在于边车（Sidecar）模式，具有通信治理能力的网络代理以边车形式部署，服务之间通过网络代理型边车发现和调用目标服务。如果我们把节点和业务逻辑从视图剥离，网络代理边车之间呈现图 1-23 所示网络状依赖关系，服务网格由此得名。 +具有通信治理能力的网络代理以边车形式部署，服务之间通过边车发现和调用目标服务。如果我们把节点和业务逻辑从视图剥离，边车之间呈现图 1-23 所示网络状依赖关系，服务网格由此得名。 :::center ![](../assets/service-mesh.png)