美文网首页
微服务架构:sidecar模式

微服务架构:sidecar模式

作者: 米兰的小铁匠xxm | 来源:发表于2022-11-26 21:49 被阅读0次

早期微服务架构存在问题

一些通用逻辑会被多个服务所需要,比如日志采集、配置、流量控制、权限认证等等,如图 image.png

像这种情况我们可能需要在业务逻辑中添加很多代码才能实现,维护成本比较高。

传统解决方式

sdk方式

为解决上述问题通常会选择提供sdk的方式,屏蔽复杂实现逻辑,对外提供代码库供调用方快速接入。 image.png

但是一般sdk需要跟调用方使用的编程语言保持一致,当调用方使用多种编程语言时,sdk必须提供多语言版本,这会带来比较高的维护成本。且多版本之前要保持一致迭代周期,增加开发和测试成本,sdk之间逻辑不一致也会增加上线的风险。

proxy模式

为解决sdk存在的问题,将sdk逻辑抽象中独立api对外提供服务,这样解决了sdk多语言维护成本高的问题。但是这种中心化部署的方式使得各业务之间的流量难以隔离,相互影响(虽然可以通过多集群方式解决,但是无法一劳永逸,增加运维成本)。另外api方式增加了网络调用,进而增加了服务延迟。

sidecar模式

中文也叫边车模式,由图可看出,在主驾旁边增加副驾,提升载人能力,但又不会影响主驾。


image.png
也就是说,我们可以在pod中独立与主容器之外再部署一个sidecar容器,由这个容器来对应的操作,使用sidecar模式后,整体架构如下: image.png
sidecar能获取到与主容器相同的资源,因此可以通过容器之间的资源共享,如路径挂载,进程间通信,来做功能上的增强,不需要对现有业务逻辑做大的改动。

容器本质上是一个进程,因此容器间通信等同于进程间通信。如UDS,共享内存。
Unix Domain Socket 或者 IPC Socket 是一种终端,可以使同一台操作系统上的两个或多个进程进行数据通信。 Unix Domain Socket 使用系统文件的地址来作为自己的身份。它可以被系统进程引用。所以两个进程可以同时打开一个 Unix Domain Sockets来进行通信。不过这种通信方式是发生在系统内核里而不会在网络里传播,时延较低。

优点

  • 由于主进程和sidecar为1对1模式,流量上涨主进程扩容时,sidecar随之扩容
  • 相较于proxy,得益于进程间通信,延迟较低基本可忽略
  • 相较于sdk,不依赖业务语言,sidecar用一种语言实现即可,降级维护成本
  • 可独立部署和升级

什么情况下使用sidecar

合适原则:合适优于业界领先

  • 业务由多语言开发,编程语言单一用sdk即可
  • 功能与业务无关,比如服务发现、限流、权限控制等
  • 有业务隔离的需要,proxy方式无法满足时
  • 业务对延迟要求较高,proxy方式无法满足

相关文章

网友评论

      本文标题:微服务架构:sidecar模式

      本文链接:https://www.haomeiwen.com/subject/ljocfdtx.html