感觉 ServiceMesh 热度逐渐消散了，零零散散一些关于 ServiceMesh 的内容像是云厂商秀实力。

现在来看，ServiceMesh 本身属于技术性创新，对业务而言属于锦上添花，用不用区别不大，所以导致很难在中小型公司普及（甚至在大型公司，我感觉推进也普遍艰难）。

还有一个不能忽视的缺陷是：服务网格的设计理念太抽象了，特别是近几年新出现的 Proxyless、Sidecarless、Cilium ServiceMesh。让服务网格的技术更加复杂。我相信，大部分工程师直面这些概念，脑袋肯定发晕，更别提主动引入到自己的业务线了。

这一节，我总结服务网格发展的一些趋向（解释上面概念是什么意思），有兴趣的可以阅读本文。

服务网格的问题

服务网格的核心 Sidecar 本质上是一个网络代理，通过拦截服务间的请求从而实现对通信的控制。随着服务网格落地实践，Sidecar 的缺点也逐渐被暴露：

网络延迟问题：服务网格使用 iptables 拦截服务间的请求，服务之间的通信原本是 A->B，现在变成 A->iptables+Sidecar->iptables+Sidecar->B，调用链的增加也带来了额外的性能损耗。虽然 Sidecar 的引入只会增加毫秒级（个位数）延迟，但对性能有极高要求的业务来说，延迟损耗成为了放弃服务网格最主要的原因。
资源占用问题：Sidecar 作为一个独立的容器必然会占用一定的系统资源，对于超大规模集群（例如有数万个 Pod）来说，巨大的基数使得 Sidecar 占用资源总量变成了不小的数目。

考虑解决以上的问题，开发者们开始思考：“是否应该将服务网格和 Sidecar 划上等号”，同时也开始探索服务网格形态上的其他可能性。

Proxyless 模式

既然问题是代理，那就把代理去掉，这就是 Proxyless（无代理）模式。

Proxyless 模式的设计理念是，服务间通信总是要选择一种协议进行，那么将协议的类库（SDK）扩展，使其具有流量控制的能力，不就能代替 Sidecar 代理了吗？且 SDK 和应用同属于一个进程，必然有更优秀的性能表现，Sidecar 诟病的延迟问题也将迎刃而解。

2021 年 Istio 官方博客发表了一篇文章《基于 gRPC 的无代理服务网格》，文中介绍了基于 gRPC 实现的一种 Proxyless 模式的服务网格。Proxyless 模式的工作原理如图 8-18 所示，服务之间的流控能力再依赖 Sidecar，而是被集成在 gRPC 库中。但这种方案额外需要一个代理（图中的 Istio Agent）通过 xDS 协议与控制平面交互，负责告知 gRPC 库如何连接到 istiod、如何获取证书、如何配置规则等。

相比 Sidecar 实现的服务间通信治理，Proxyless 模式实现的服务间通信治理具有性能、稳定性、资源消耗低等明显的优势。根据官方博客的性能测试报告来看：gRPC Proxyless 模式下的延迟情况接近基准测试，资源消耗也相对较低。

不过，回过头再看，所谓 Proxyless 其实和传统的 SDK 并无二致，只是将流控能力内嵌到负责通信协议的类库中，因此它具有和传统 SDK 服务框架相同的缺点。

所以，业内很多人认为 Proxyless 模式本质上是一种倒退，是回归到传统的方式去解决服务间通信的问题。