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 将给大规模系统带来怎样的影响做出全面的定论,不过我们至少可以看到两个方面的优势。
首先,微服务架构的一些公共组件已经是现成的,很多小公司可以享受到之前只有大公司才能享受的一些特性。
其次,我们或许能够因此使用最好的工具和编程语言,而无需担心不同平台对软件库和模式的支持存在差异。