本文转自：http://philcalcado.com/2017/08/03/pattern_service_mesh.html
SideCar:
SideCar就是与Application一起运行的独立进程（Processor），为Application提供额外的功能；
例如：Kubernetes的Pod中运行一个Log收集器Container，这个Log收集器Container就被称为SideCar。
Service Mesh(服务网格)：
在这样的模型里， 每个服务都会有一个SideCar代理与之匹配，服务间通信都是通过SideCar代理进行的，于是我们就会得到如下的部署图：
Buoyant 的 CEO William Morgan 发现，代理之间的连接形成了一种网格网络。2017 年初，William 对这样的平台做出了定义，并称之为 Service Mesh：
服务网格是一个基础设施层，用于处理服务间通信。
云原生应用有着复杂的服务拓扑，服务网格保证请
求可以在这些拓扑中可靠地穿梭。在实际应用当中，
服务网格通常是由一系列轻量级的网络代理组成的，
它们与应用程序部署在一起，但应用程序不需要知道它们的存在。
这个定义最强有力的部分在于，它 不再把代理看成单独的组件，并强调了这些代理 所形成的网络的重要性：
组织开始将他们的微服务部署到更为复杂的运行时（如 Kubernetes 和 Mesos）上，并开始使用这些平台提供的网格网络工具。
他们正从使用一系列独立运行的代理转向使用集中式的控制面板：
从鸟瞰图中可以看到，服务的实际流量仍然在代理间流转，不过控制面板对每一个代理实例了如指掌，通过控制面板可以实现代理的访问控制和度量指标收集。
最近发布的 Istio就是这类系统最为突出的代表。
我们还无法对 Service Mesh 将给大规模系统带来怎样的影响做出全面的定论，不过我们至少可以看到两个方面的优势。
首先，微服务架构的一些公共组件已经是现成的，很多小公司可以享受到之前只有大公司才能享受的一些特性。
其次，我们或许能够因此使用最好的工具和编程语言，而无需担心不同平台对软件库和模式的支持存在差异。