本文主要是介绍殊途同归,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的便利性&
这篇关于殊途同归,Proxyless Service Mesh在百度的实践与思考的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!