顾名思义，边车用大白话来讲就是加装在摩托车旁边，用来达到拓展现有功能的能力，可以让其坐上更多的人或物。边车很像软件工程里的代理模式，对服务进行包装，使其不改变原来的功能，拓展原来的服务。
现在微服务盛行，技术栈五花八门，其中最让人头疼的就是服务治理了，而 Sidecar 模式的出现，正好为服务治理提供了一种解决方案。
本篇文章的重点并不是服务治理，微服务的服务治理太难了，仅仅通过一两篇文章是讲不完了，后续我会专门开个系列来慢慢展开。
今天主要是带大家来开车的，一辆带边的三轮摩托车。。。
在讲 Sidecar 模式之前，不妨先来回顾一下系统架构的演进历程，从一步步的演进历程来看，或许我们对 Sidecar 模式的理解会更加的深刻。
下面主要以 日志收集 和 服务健康检查 这两个附加能力，来举例说明在不同时期 Sidecar 模式的实现方式。
我们早期是从物理服务器，通过虚拟化技术演进为虚拟机的，下面这个图片可以说是 远古时代 的架构。
远古时代
在远古时代的架构里，所有的服务都是以进程的方式逐一部署在 VM 里的，另外两个 Logs Progess 和 Health Check Progress 就相当于 Sidecar 的能力。
大家可以想象一下，异构系统架构在当时的条件下，运维工程师面对众多不同技术栈的 VM B、VM C、 VM D 以及没有尽头的 VM XXX...，他们需要做大量重复的工作，可以想象这种部署方式对于运维工程师来说是多么的奔溃。
通过容器化技术演进为目前的 container，从而进入容器时代。
容器时代