服务网格(service mesh)

现在最火的后端架构无疑是微服务了，微服务将之前的单体应用拆分成了许多独立的服务应用，每个微服务都是独立的，好处自然很多，但是随着应用的越来越大，微服务暴露出来的问题也就随之而来了，微服务越来越多，管理越来越麻烦，特别是要你部署一套新环境的时候，你就能体会到这种痛苦了，随之而来的服务发现、负载均衡、Trace跟踪、流量管理、安全认证等等问题。如果从头到尾完成过一套微服务框架的话，你就会知道这里面涉及到的东西真的非常多。当然随着微服务的不断发展，微服务的生态也不断完善，最近就发现新一代的微服务开发就悄然兴起了，那就是服务网格/Service Mesh。

1 服务网格(service mesh) 是什么

Service Mesh是一个非常新的名词，最早是2016年由开发Linkerd的 Buoyant 公司提出的，搬随着Linkerd的传入，Service Mesh的概念也慢慢进入国内技术社区。之前 infoQ 的一篇介绍istio的文章将Service Mesh翻译成的服务啮合层，啮合的字面意思是：两个齿轮间的咬合，和Service Mesh表达的意思基本上还是吻合的，但是这个词比较拗口。到现在主流的叫法都叫：服务网格。

服务网格是一个用于处理服务间通信的基础设施层，它负责为构建复杂的云原生应用传递可靠的网络请求。在实践中，服务网格通常实现为一组和应用程序部署在一起的轻量级的网络代理，但对应用程序来说是透明的。

意思就是说，这个服务网格如果我们把他加入到一个微服务当中去的话，这时候我们的微服务只需要关心他自己的一个业务逻辑。包括所谓的服务发现、负载均衡、Trace 跟踪、流量管理、安全认证等问题本身都不属于微服务的一个功能，而是属于我们所运行的一个环境基础设施层应该提供给我们的一个功能。

而服务网格就包含了这些所谓的基础设施层，而我们业务人员开发的微服务呢就比较轻量级，只需要和业务逻辑有关联就可以了

1.1 怎么理解网格

要理解网格的概念，就得从服务的部署模型说起：

1.1.1 单个服务调用，表现为sidecar


如上图：

我们将 host/pod 部署在 K8S 里面是一个完整的 pod ，然后我们的 application 就是 pod 中的一个容器，然后我们其中有一个 sidecar 容器也就是所谓服务网格 linkerd ，当然我们也可以使用其他的 sidecar 比如 istio 。

然后我们的这个 application 程序需要和别的应用程序通讯，这时候并不需要 application 向别的程序发起信号并建立连接，而是将请求发送给 linkerd sidecar ，而 sidecar 之间则是通过 RPC 或者 rustAPI 进行通讯。

然后服务网格基础设施层可以通过服务发现将 application 真正的请求转发给对饮的其他服务，以上就是单个服务调用的这么一个逻辑。

• Service Mesh的部署模型，先看单个的，对于一个简单请求，作为请求发起者的客户端应用实例，会首先用简单方式将请求发送到本地的Service Mesh实例。这是两个独立进程，他们之间是远程调用。
• Service Mesh会完成完整的服务间调用流程，如服务发现负载均衡，最后将请求发送给目标服务。这表现为Sidecar。
• 提到Sidecar，在Kubernetes中部署的POD中也会有一个附加的Sidecar容器。

1.1.2 部署多个服务，表现为通讯层


如上图：

如果有多个服务，那么表现层的形式我们就可以看成是一个通讯层。

也就是说当我们的 service A 需要和 service B 进行通讯，service B 需要和 service C 进行通讯，那么我们就会在每一个 pod 里面新增一个对应的 sidecar 容器，此时多个 service 之间的通讯都无需关注，而是将其托管给了我们的 Linkerd sidecar，这就是 service mesh 接管了整个网络转发的这么一个请求，而这些 service 只管发送和接收处理的请求，service 之间的通讯环节将其忽略。

service 之间的通讯不在处理，而是直接交给了底层微服务设施层的 linkerd sidecar 容器来处理。

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

所以对于开发人员来说我们只需开发服务本身的业务逻辑，无需关心通讯问题。底层通讯问题只需交给 liknkerd 即可。

1.1.3 大量服务，表现为网络


如上图：

上图是一个大量服务间的调用，可以看到绿色的方块为 application 而蓝色的方块则是我们的 sidecar 容器，并且蓝色方块之间都有一条线做链接，也就是说不管我们的业务逻辑应用如何通讯都是基于 sidecar 容器实现。

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

服务网格：

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

1.2 service mesh 定义回顾


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

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

参考资料

https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/