早期微服务架构存在问题
一些通用逻辑会被多个服务所需要，比如日志采集、配置、流量控制、权限认证等等，如图
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方式无法满足
