在云环境下，技术栈可以是多种多样的。那么如何能够将这些异构的服务组件串联起来，成为了服务治理的一个重大课题。而 Sidecar 模式为服务治理，提供了一种解决方案。
问题背景
大部分应用和服务都需要实现额外的服务治理功能，这些功能可以作为单独的组件或服务而存在。如果将这些功能集成到业务应用中，就会与业务应用运行在同一个进程中，从而可以有效地共享资源。从另一方面来看，这也意味着服务治理组件与业务应用之间的隔离性很弱，一旦其中一个组件出现故障，可能会影响其他组件甚至整个应用程序。除此之外，服务治理组件需要使用与父应用程序相同的技术栈来实现，因此它们之间有密切的相互依赖性。
解决方案
上述问题的解决方案是，将服务治理功能从应用本身剥离出来作为单独进程，与主应用程序共同放在一台主机（Host）中，但会将它们部署在各自的进程或容器中。这种方式也被称为 Sidecar（边车）模式。
下图展示了服务治理功能与主应用程序的部署关系图。
该模式允许我们向应用无侵入添加多种功能，避免了为满足第三方组件需求而向应用添加额外的配置代码。
Sidecar 模式
在软件架构中，Sidecar 附加到主应用，或者叫父应用上，以扩展/增强功能特性，同时 Sidecar 与主应用是松耦合的。这就像是如下图所示的边三轮摩托车那样，将边车（Sidecar）安装在一辆摩托车上，就变成了边三轮摩托车。每辆边三轮摩托车都有自己的边车。类似同样的方式，Sidecar 服务共享其父应用程序的主机。对于应用程序的每个实例，边车的实例被部署并与其一起托管。
使用 Sidecar 模式的好处有很多：
- 通过将服务治理相关功能抽象到不同的层来降低微服务的代码复杂性
- 在运行时环境和编程语言方面，
Sidecar独立于其主要应用程序，不需要为每个微服务编写服务治理功能的代码，减少了微服务架构中的代码重复。 Sidecar可以访问与主应用程序相同的资源。例如，Sidecar可以监视 Sidecar 本身和主应用程序使用的系统资源。- 由于它靠近主应用程序，因此在它们之间进行通信时没有明显的延迟。
- 降低了应用与底层平台的耦合度。
Envoy
Envoy 是为云原生应用设计的代理，可以在服务旁运行，以平台无关的方式提供必要的特性，所有到服务的流量都通过 Envoy 代理，这里 Envoy 扮演的就是 Sidecar 的角色。
总的来说，在从一体化架构向微服务架构的转型让我们可以相对独立、大规模地部署应用，而在容器环境中，Sidecar 模式可以很好地兼容，帮助我们降低微服务架构复杂性，更好地实现服务发现、流量管理、负载均衡、路由。