云原生技术专题-Service Mesh-到底解决了什么问题（三）

首先来看一下service mesh的定义

这个定义最早是由bouyant的公司的CEO william morgan第一次提出的，在2017年的四月份，随着第一个service mesh产品的发布，他们同时发布了一篇文章，就是什么是service mesh,以及你为什么需要它，这篇文章对service mesh做了一个权威的定义
这段话说的是service mesh是一个基础设施层，用来处理服务与服务之间网络之间的通信，它主要的功能是在云原生的应用，这种复杂的网络拓扑情况下进行可靠的请求分发，一般情况下它会实现为一组轻量化的网络代理，部署在你应用代码的旁边，并且是跟你的应用完全透明，其实这段话的意思我们需要理解它的第一点，你需要知道它的本质，你可以看到它的本质是一个基础设施层，第二点是它的功能，其实很简单，就是请求的分发，第三点，它的产品形态或者是它的部署方式，实际上就是一组网络代理，也就是sidecar,它的特点就是完全和你的应用透明，把上面四个关键点组合在一起就能形成一个简洁的概念，所谓service mesh就是一个用来请求转发的基础设施层，它通常是以sidecar的形式进行部署，并且对你的应用透明。

Service Mesh产品形态是什么样的？

一个service mesh实际是由sidecar组成的一个网络拓扑，可以看到增加了一个网络控制层面，用来管理和控制整个sidecar网络，这就是第二代service mesh技术，从目前来看它的产品形态包括两部分，一部分叫数据平面，也就是所有的sidecar组合，一部分叫控制平面，用来进行总体的控制，这两个形态组合在一起就形成了现在的service mesh的技术形态，也可以用这句话来定义service mesh,service mesh是sidecar网络拓扑的结构模式

Service Mesh主要功能

进行网络控制都需要哪些功能，这些功能就是service mesh的核心功能，
主要概述为以下四个功能
第一个功能就是流量控制，也就是路由,比如我们熟知的蓝绿部署，灰度发布，AB测试，以及流量转移，超时重试，熔断这几个核心，和系统弹性的功能，另外为了进行调试，还引入了故障注入，流量镜像，除了流控这样的功能之外，另外的功能也很重要就是策略，大家家里都有路由器，一般情况下都可以在路由器进行一些流量限制或者黑名单，白名单的操作，这就是最典型的策略，而service mesh也会提供这样的功能，第三块功能就是网络安全相关的，主要是如何进行授权以及身份认证，最后一部分功能是可观测性，如何对整个微服务进行观测，通过指标收集和展示，通过日志的收集，以及分布式追踪，来完整的去观测系统的运行状态。

service mesh与kubernetes的关系

kubernetes主要是解决容器编排与调度问题，而service mesh主要解决服务网络通信问题，他们的目标是不一样的，第二点kubernetes实际上是用来管理应用的生命周期，可以简单的理解为是一个调度器，而service mesh本质是用来解决服务间的通信，可以理解为是一组sidecar代理，第三点service mesh会给k8s提供支持，大家都知道，在k8s pod是最小的调度单元，pod天生支持多容器的部署，这就为我们植入sidecar提供了非常大的便利，因此kubernetes对service mesh部署提供了非常大的支持，反过来讲service mesh对k8s的网络层面功能提供了扩展和延伸，其实k8s当中也有一些网络相关的功能，比如说ingress,比如说最基本的服务发现，而这些功能虽然属于网络控制相关，但是还是比较简单，不完全满足我们的需要，service mesh会把这些功能进行扩展和延伸，以便满足我们对网络控制相关功能更多的需求，从上面这张图我们可以看到k8s是最底层，相当于云原生时代的操作系统，而service mesh是附着在操作系统之上的，可以理解云原生的网络通信层。

Service Mesh和API网关的异同点
现有的API网关已经提供了service mesh的相关功能，比如说复杂均衡，服务发现，以及流量控制

具体的异同点有哪些呢？

这张图也就是我们的部署结构，在我们的代理sidecar,由sidecar完全去接管发送到应用的请求，处理完成之后再发送到另一个微服务

下面这张图显示了API网关它的模型，可以看到API网关实际上是部署在应用边界的，它并没有侵入到应用内部，它主要的功能实际上是对内部的API进行一个聚合和抽象，以方便外部进行调用，所以这是他们一个很大的一个不同点

Service Mesh主要是用来对应用内部的网络细节进行一个描述，而API网关主要附着应用的边界，对流量进行一个抽象，所以他们的异同点如下：

Service Mesh技术标准

目前主要有两个标准，第一个标准叫UDPA就是统一的数据平面API，这个标准的目的就是为不同的数据平面提供一个统一的API，方便你无缝的接入，我们知道不同的数据平面有很多比如说Envoy,比如说Linkerd，这些产品有很多，目前来说他们的接入标准是不一样的，有了UDPA之后就不再续关心它具体实现的细节了，直接用统一的标准接入就可以了，这样方便进行迁移，这个标准主要是由云原生基金会提出的，它背后的公司就是google,以及Envoy的数据平面的开发者Lyft

另外一个标准就是SMI，service mesh interface,这个标准的目标实际跟UDPA是类似的，只不过它侧重的是控制层面，它希望为用户提供一个统一的使用体验，通过这样的一个标准去接入你的控制层面，而不用去关心控制平面的实现细节，标准最初是由微软作为发起人，可以看到图中有很多的service mesh玩家参与到这个标准中，唯独缺失了google和亚马逊两个重量级人物，他们为什么没有参与，是因为他们两家以及对service mesh的竞争