微服务必备知识：Service Mesh

所属技术领域：

微服务

|名词定义|

这个词最早使用由开发 Linkerd 的 Buoyant 公司提出，并在内部使用。2016 年 9 月 29 日第一次公开使用这个术语。2017 年的时候随着 Linkerd 的传入，Service Mesh 进入国内技术社区的视野。最早翻译为“服务啮合层”，这个词比较拗口。用了几个月之后改成了服务网格。后面我会给大家介绍为什么叫网格。

先看一下 Service Mesh 的定义，这个定义是由 Linkerd 的 CEO William 给出来的。Linkerd 是业界第一个 Service Mesh，也是他们创造了 Service Mesh 这个词汇的，所以这个定义比较官方和权威。

我们看一下中文翻译，首先服务网格是一个基础设施层，功能在于处理服务间通信，职责是负责实现请求的可靠传递。在实践中，服务网格通常实现为轻量级网络代理，通常与应用程序部署在一起，但是对应用程序透明。

这个定义直接看文字大家可能会觉得比较空洞，不太容易理解到底是什么。我们来看点具体的东西。

Service Mesh 的部署模型，先看单个的，对于一个简单请求，作为请求发起者的客户端应用实例，会首先用简单方式将请求发送到本地的 Service Mesh 实例。这是两个独立进程，他们之间是远程调用。

Service Mesh 会完成完整的服务间调用流程，如服务发现负载均衡，最后将请求发送给目标服务。这表现为 Sidecar。

Sidecar 这个词中文翻译为边车，或者车斗，也有一个乡土气息浓重的翻译叫做边三轮。Sidecar 这个东西出现的时间挺长的，它在原有的客户端和服务端之间加多了一个代理。

多个服务调用的情况，在这个图上我们可以看到 Service Mesh 在所有的服务的下面，这一层被称之为 服务间通讯专用基础设施层。Service Mesh 会接管整个网络，把所有的请求在服务之间做转发。在这种情况下，我们会看到上面的服务不再负责传递请求的具体逻辑，只负责完成业务处理。服务间通讯的环节就从应用里面剥离出来，呈现出一个抽象层。

如果有大量的服务，就会表现出来网格。图中左边绿色方格是应用，右边蓝色的方框是 Service Mesh，蓝色之间的线条是表示服务之间的调用关系。sidecar 之间的连接就会形成一个网络，这个就是服务网格名字的由来。这个时候代理体现出来的就和前面的 sidecar 不一样了，形成网状。

再来回顾前面给出的定义，大家回头看这四个关键词。首先第一个，服务网格是抽象的，实际上是抽象出了一个基础设施层，在应用之外。其次，功能是实现请求的可靠传递。部署上体现为轻量级的网络代理。最后一个关键词是，对应用程序透明。

大家注意看，上面的图中，网络在这种情况下，可能不是特别明显。但是如果把左边的应用程序去掉，现在只呈现出来 Service Mesh 和他们之间的调用，这个时候关系就会特别清晰，就是一个完整的网络。这是 Service Mesh 定义当中一个非常重要的关键点，和 Sidecar 不相同的地方：不再将代理视为单独的组件，而是强调由这些代理连接而形成的网络。在 Service Mesh 里面非常强调代理连接组成的网络，而不像 sidecar 那样看待个体。

现在我们基本上把 Service Mesh 的定义介绍清楚了，大家应该可以大概了解什么是 Service Mesh 了。

|发展历程|

Service Mesh起源始于2010年左右应用架构三层模型的兴起——一种简单的架构，曾一度为网络上的绝大多数应用提供动力。在这个模型中，请求流量扮演一个角色（有两跳！），但它本质上是非常专业化的。应用程序流量首先由“Web层”处理，然后与“应用层”进行对话，然后与“数据库层”进行对话。Web层中的Web服务器旨在处理大量传入请求非常迅速地将它们交给相对缓慢的应用程序服务器。（Apache，NGINX和其他流行的Web服务器都具有用于处理这种情况的非常复杂的逻辑）。同样，应用层使用数据库库与缓存进行通信。这些库通常以针对此用例进行优化的方式处理缓存、负载平衡、路由、流量控制等。

到目前为止运行良好，但是这种模式在重负载下开始崩溃——特别是在应用层，随着时间的推移可能会变得相当大。谷歌、Facebook、Netflix和Twitter等早期的网络规模公司学会了将整体拆分成许多独立运行的组件，从而促成了微服务的兴起。引入微服务的同时，也引入了东-西的流向。在这个世界上，沟通不再是专门制定的，而是在每一项服务之间都存在。当它出错时，该网站就宕机了。

这些公司都以类似的方式回应：他们写了“胖客户端”库来处理请求流量。这些例如谷歌的Stubby，Netflix的Hysterix，Twitter的Finagle的库——为所有服务提供了统一的运行时操作方式。开发人员或服务所有者可以使用这些库向其他服务发出请求，并且在这些库下，这些库可以执行负载平衡、路由、断路、遥测。通过在应用程序中的每个服务中提供统一的行为，可见性和控制点，这些库形成了表面上是第一个Service Mesh的东西——并没有花哨的名称。

|技术特点|

1、治理功能从应用开发SDK中分离（胖SDK代码对于部署是有感知的，但是在Service Mesh当中把这部分逻辑从源代码中脱离出来，也就是说自己的代码无需管理这些事情。）

2、微服务治理是到基础设施层的（胖SDDK是无法另起容器的，Service Mesh是和Path层打通的，kubernetes或其他Path平台来实现管理）

|现状|

Service Mesh开源和商业产品

1、 Linkerd：开源项目：背后的公司是Bouyant,提供商业化产品和支持

2、 Istio开源项目，由谷歌、IBM、Lyft等主导，各公司厂商皆有自己的商业产品

3、 AWS app mesh：闭源产品，针对AWS提供的服务

4、 HashiCorp Aspen Mesh, solo.io,Rancher, Weaveworks

|资料来源|

阿里云大学-视频网站

CSDN-

https://blog.csdn.net/m2l0zgssvc7r69efdtj/article/details/79395284

博客园-

https://www.cnblogs.com/williamjie/p/9497435.html