Service Meth and SideCar

本文转自：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 将给大规模系统带来怎样的影响做出全面的定论，不过我们至少可以看到两个方面的优势。

首先，微服务架构的一些公共组件已经是现成的，很多小公司可以享受到之前只有大公司才能享受的一些特性。

其次，我们或许能够因此使用最好的工具和编程语言，而无需担心不同平台对软件库和模式的支持存在差异。