另一方面，Sidecar模式是指，通过将APP的功能分成单独的进程，来进行Sidecar模式。

Sidecar原本的意思是摩托车的侧车，用于软件架构。 这意味着sidecar APP应用程序连接到父APP应用程序以扩展或增强其功能。 Sidecar应用于主APP应用程序松散耦合。

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

但是，为每个微服务器实现一次监视、日志记录、配置、断路器…的功能合理吗？ 如果每个APP应用程序都使用不同的语言实现，如何合并特定于语言(如. Net、java和Python )的第三方库？

二、使用Sidecar模式的优点是通过从功能相关的公共基础设施抽象到一个不同的层来降低微服务代码的复杂度。 降低微服务架构中的代码复杂性，减少APP应用与底层平台的耦合度，因为APP应用不需要编写相同的第三方组件配置文件和代码。 第三、Sidecar模式如何工作的服务网格层可驻留在与APP应用一起工作的Sidecar容器中

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

在某种意义上，APP应用程序不需要知道网络外部的系统，只需要知道附加的Sidecar代理。 这就是Sidecar模式： Sidecar动作模式的本质。 将网络依赖抽象为Sidecar。

服务网格有数据平面和控制平面的概念。

数据平面：负责处理网格中服务之间的通信，负责服务发现、流量管理、体检等功能。 控制面：负责管理和配置Sidecar代理，以实施策略和收集遥测。 在Kubernates和Istio的世界中，可以将Sidecar注入Pod内，Istio使用代用Envoy的Sidecar模型作为代理。

来自Lyft的Envoy是最受欢迎的开源代理，专门为云本机APP应用设计。 Envoy依赖于每个服务运行，以平台无关的方式提供所需的功能，所有服务流量都通过Envoy代理流动。