一、什么是Sidecar模式

将应用程序的功能划分为单独的进程，就是Sidecar模式。

Sidecar原意是摩托车的边车，用到软件架构中，就是Sidecar应用是连接到父应用，并为其扩展或增强功能。Sidecar应用于主应用程序松耦合。

Sidecar应用场景举例：假如有6个微服务互相通信，共同完成来确定一个包裹的成本。每个微服务都需要监控、日志记录、配置、断路器等功能，这些功能都是用第三方库在每个微服务中实现的。

但是，每个微服务都实现一遍监控、日志记录、配置、断路器… 功能，这是合理的吗？如果每个应用是不同的语言实现，如何合并哪些特定用于.Net, java, Python等语言的第三方库？

二、使用Sidecar模式的优势

• 通过抽象出于功能相关的共同基础设施到一个不同层，以降低微服务代码的复杂度
• 因为应用不再需要编写相同的第三方组件配置文件和代码，从而降低了微服务架构中代码的复杂度
• 降低了应用程序和底层平台的耦合度

三、Sidecar模式是如何工作的

服务网格层可以存在于与应用程序一起运行的Sidecar容器中，每个应用程序旁边都附有相同的Sidecar副本。

来自单个服务的所有传入和传出网络流量，都流经Sidecar代理。因此，Sidecar能够管理微服务之间的流量，可收集数据并实施相关策略。

从某个角度来说，应用并不需要了解网路外部的系统，只需要知道附加的Sidecar代理，这就是Sidecar模式：Sidecar工作模式的本质：将网络依赖抽象为Sidecar。

在服务网格中，有数据平面和控制平面的概念：

• 数据平面：职责是处理网格内部服务间的通信，并负责服务发现、流量管理、健康检查等功能。
• 控制平面：职责是管理和配置Sidecar代理，以实施策略并收集遥测。

在Kubernates和Istio世界中，可以将Sidecar注入Pod内，Istio使用代用Envoy的Sidecar模型作为代理。

来自Lyft的Envoy是为云原生应用程序设计的最流行的开源代理。Envoy依附着每项服务运行，并以平台无关的方式提供必要的功能，所有的服务流量都通过Envoy代理流动。