殊途同归，Proxyless Service Mesh在百度的实践与思考

【百度云原生导读】Service Mesh已经在云原生界火了很多年，大家的探索热情依然不减。而最近一段时间Proxyless Service Mesh也开始进入大家的视野，比如

• Istio官宣支持gRPC Proxyless Service Mesh

• Dubbo 3.0引入Proxyless Service Mesh架构

那么，什么是Proxyless Service Mesh？它和原来的Proxy Service Mesh有什么区别和优缺点？落地场景又有哪些呢？本文将结合Proxyless Service Mesh在百度的落地实践，带你一探究竟。

什么是Proxyless Service Mesh

先来看下Proxy Service Mesh，也就是最常见的Service Mesh架构，一般如下所示：

• 每个App的Pod里面，有一个独立的Sidecar进程，App之间的通信都通过Sidecar进程转发。

• 有一个全局的控制平面（最常见的实现是Istio），下发配置到每个Sidecar，控制具体请求的转发策略。

而Proxyless Service Mesh则是如下的架构：

• 由联编到App进程的rpc框架负责服务之间的通信。

• 控制平面下发配置到每个rpc框架，rpc框架按照配置进行具体请求的转发。（以上架构图是经过简化的，以目前主流的Proxyless实现，比如gRPC和Istio之间的通信是由Istio Agent来代理的，但这不影响后面的讨论）

Proxyless Service Mesh的优缺点

如果简单对比上述架构，不难得出Proxyless和Proxy模式的优缺点：

以上仅是一些直观的分析，但当真正落地Proxyless Service Mesh的时候，会发现情况并不是我们想的那么简单。

百度的Proxyless Service Mesh实践

Proxyless第一阶段

百度从2018年开始引入Service Mesh，一开始是Proxy模式。到了2020年，我们在落地一些业务线的时候，发现Proxy模式很难在整个业务线全面铺开：

• 业务其实能够接受Proxy带来的额外资源开销，毕竟我们已经做了很多优化，比如将社区Both Side模式改成Client Side模式（即一次请求只过Client端的代理，不经过Server端的代理）；比如将Envoy的流量转发内核替换成bRPC。我们能做到Sidecar占业务进程的cpu消耗在5%以内，有的业务甚至不到1%。

• 但业务无法接受Proxy带来的延迟增长，即使我们已经把Proxy单次转发增加的延迟优化到0.2毫秒以内，但由于整个业务系统包含了很大的一个调用拓扑，每条边上增加一点点的延迟就能导致流量入口模块增加较大的延迟，进而对业务KPI造成影响。

因此我们开始引入如下的Proxyless Service Mesh模式：

• Envoy从Istio拿到流量转发配置，并转化成bRPC能识别的配置

• bRPC通过http接口从Envoy中拿到流量转发配置，并且按照该配置去调用其它服务

这种方式的好处是：

• 业务接入Mesh，不会带来延迟增长，也不会增加明显的资源开销。 （这里的Envoy仅处理配置，资源开销极小）

• 业务可以享受Mesh的便利性ÿ