Service Mesh详解

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

微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building
Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与 语言无关
(Language-Independent/Language agnostic) 的 API 集相互通信。

Service Mesh是用于处理服务间通信的基础设施层，用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。在实践中，Service Mesh通常是一组与应用一起部署，但对应用透明的轻量级网络代理。Service Mesh基本来说是一组轻量级的服务代理和应用逻辑的服务在一起，同生共死，并且对于应用服务是透明的。

特点：治理能力独立(Sidecar)、应用程序无感知、服务通信的基础设施层

对Service Mesh的权威定义：

“dedicated infrastructure layer”：Service Mesh
不是用来解决业务领域问题的，而是一层专门的基础设施（中间件）。
“service-to-service communication”：Service Mesh 的定位很简单也很清晰，就是用来处理服务与服务之间的通讯。
“reliable delivery of requests”：服务间通讯为什么需要特殊处理？因为网络是不可靠的，Service Mesh
的愿景就是让服务间的请求传递变得可靠。
“cloud native application”：Service Mesh
从一开始就是为现代化的云原生应用而生，瞄准了未来的技术发展趋势。
“network proxies”：具体 Service Mesh
应该怎么实现？典型方式都是通过一组轻量级的网络代理，在应用无感知的情况下偷偷就把这事给干了。
“deployed alongside application code”：这些网络代理一定是跟应用部署在一起，一对一近距离贴心服务（比房产中介专一得多）；否则，如果应用与代理之间也还是远程不靠谱通讯，这事儿就没完了。
Service Mesh 主流实现

Service Mesh 的主流实现包括：

Linkerd：背后公司是Buoyant，开发语使用Scala，2016年115日初次发布，2017年123日加入CNCF，2018年51发布1.4.0版本。
Envoy：背后公司是Lyft，开发语言使用C++
11，2016年9月13日初次发布，2017年914日加CNCF，2018年3月21日发布1.6.0版本。
Istio：背后公司是Google和IBM，开发语言使用Go，2017年5月10日初次发布，2018年331日发布0.7.1版本。
链接：https://blog.csdn.net/Dusttang/article/details/118087424?spm=1001.2014.3001.5501
Conduit：背后公司也是Buoyant，开发语言使用Rust和Go，2017年12月5日初次发布，2018年427日发布0.4.1版本。
在业务规模化和研发效能提升等因素的驱动下，很多企业从单块应用向微服务架构的转型(如下图所示)：

在微服务模式下，企业内部服务少则几个到几十个，多则上百个，每个服务一般都以集群方式部署，这时自然产生两个问题(如下图所示)：

一、服务发现：服务的消费方(Consumer)如何发现服务的提供方(Provider)？
二、负载均衡：服务的消费方如何以某种负载均衡策略访问集群中的服务提供方实例？

服务发现和负载均衡，这些模式的核心其实是代理(Proxy，如下图所以)，以及代理在架构中所处的位置，

这是很多互联网公司比较流行的一种做法，代理(包括服务发现和负载均衡逻辑)以客户库的形式嵌入在应用程序中。这种模式一般需要独立的服务注册中心组件配合，服务启动时自动注册到注册中心并定期报心跳，客户端代理则发现服务并做负载均衡。

Service Mesh的注册发现：

三种服务发现模式的比较
三种服务发现模式各有优劣，没有绝对的好坏，可以认为是三种不同的架构风格，在不同的公司都有成功实践：

所谓的ServiceMesh，其实本质上就是上面提到的模式三~主机独立进程模式，这个模式其实并不新鲜，业界(国外的Airbnb和国内的唯品会等)早有实践，那么为什么现在这个概念又流行起来了呢？我认为主要原因如下：

1、上述模式一和二有一些固有缺陷，模式一相对比较重，有单点问题和性能问题；模式二则有客户端复杂，支持多语言困难，无法集中治理的问题。模式三是模式一和二的折中，弥补了两者的不足，它是纯分布式的，没有单点问题，性能也OK，应用语言栈无关，可以集中治理。

2、微服务化、多语言和容器化发展的趋势，企业迫切需要一种轻量级的服务发现机制，ServiceMesh正是迎合这种趋势诞生，当然这还和一些大厂(如Google/IBM等)的背后推动有关。

(ServiceMesh)也被形象称为边车(Sidecar 见我另一篇博客)模式，在边车模式中，业务代码进程(相当于主驾驶)共享一个代理(相当于边车)，代理除了负责服务发现和负载均衡，还负责动态路由、容错限流、监控度量和安全日志等功能，这些功能是具体业务无关的，属于跨横切面关注点(Cross-Cutting Concerns)范畴。
链接：https://blog.csdn.net/Dusttang/article/details/118208280?spm=1001.2014.3001.5501

在新一代的ServiceMesh架构中(下图上方)，服务的消费方和提供方主机(或者容器)两边都会部署代理SideCar。ServiceMesh比较正式的术语也叫数据面板(DataPlane)，与数据面板对应的还有一个独立部署的控制面板(ControlPlane)，用来集中配置和管理数据面板，也可以对接各种服务发现机制(如K8S服务发现)。术语数据面板和控制面板，估计是偏网络SDN背景的人提出来的。

上图左下角，每个主机上同时居住了业务逻辑代码(绿色表示)和代理(蓝色表示)，服务之间通过代理发现和调用目标服务，形成服务之间的一种网络状依赖关系，控制面板则可以配置这种依赖调用关系，也可以调拨路由流量。如果我们把主机和业务逻辑剥离，就出现一种网格状架构(上图右下角)，服务网格由此得名。

附一链接：https://www.jianshu.com/p/27a742e349f7
————————————————
版权声明：本文为CSDN博主「Dust | 糖」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/Dusttang/article/details/118364269