云原生时代，你应该了解的Service Mesh

 

导读：本文系 Service Mesh 系列文章的第一篇，一步步带读者了解 Service Mesh 的基础概念和前世此生。

后续还将会为读者带来系列 Service Mesh 文章，内容涵盖 Istio 入门体验、Istio 和 Envoy 源码深度解析、服务网格大规模落地经验、服务网格性能优化等，敬请持续关注。

Service Mesh 做为下一代微服务技术的代名词，初出茅庐却深得人心一举成名，大有一统微服务时代的趋势。

那么到底什么是 Service Mesh ？

一言以蔽之：Service Mesh是微服务时代的TCP协议。

有了这样一个感性的初步认知，咱们再来看到底什么是 Service Mesh 。

提到 Service Mesh ，就不得不提微服务。根据维基百科的定义：

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

目前业界跟微服务相关的开发平台、框架、概念更是不胜枚举：Spring Cloud，Service Fabric ，Linkerd ，Istio ，Envoy ，Consul ，NginMesh ，OSM ...
这些纷繁的产品和 Sevice Mesh 有什么样的关联？哪些属于 Service Mesh 的范畴？

为了理清这些繁复的产品和概念，咱们先来了解下微服务和 Service Mesh 技术的历史发展脉络。
了解清楚了技术的主要脉络，就能清晰的知道上述的各个平台、框架属于技术脉络中的哪一个结点，其间的关系也就一目了然。
Phil Calçado 的文章《 Pattern: Service Mesh 》，详细的介绍了从开发者视角来看，服务开发模式和 Service Mesh 技术的演化过程，我的认为是很是经典的学习 Service Mesh 的资料，感兴趣的读者也能够阅读英文原文。这里借用文章绘图和脉络，结合本身的理解并予以简化，试图说清楚 ServiceMesh 的概念和这项技术诞生的历史必然性，读者也能够将本文做为原文的一个简化中文版原本阅读。

时代0：抽象时代

开发人员想象中，不一样服务间通讯的方式，抽象表示以下：

时代1：原始通讯时代 

然而现实远比想象的复杂，在实际状况中，通讯须要底层可以传输字节码和电子信号的物理层来完成，在TCP协议出现以前，服务须要本身处理网络通讯所面临的丢包、乱序、重试等一系列流控问题，所以服务实现中，除了业务逻辑外，还夹杂着对网络传输问题的处理逻辑。

时代2：TCP时代

为了不每一个服务都须要本身实现一套类似的网络传输处理逻辑，TCP协议出现了，它解决了网络传输中通用的流量控制问题，将技术栈下移，从服务的实现中抽离出来，成为操做系统网络层的一部分。

时代3：第一代微服务

在TCP出现以后，机器之间的网络通讯再也不是一个难题，以 GFS / BigTable / MapReduce 为表明的分布式系统得以蓬勃发展。这时，分布式系统特有的通讯语义又出现了，如熔断限流、负载均衡、服务发现、认证受权、安全加密、trace和监控等等，因而服务根据业务需求来实现一部分所需的通讯语义。

时代4：第二代微服务

为了不每一个服务都须要本身实现一套分布式系统通讯的语义功能，随着技术的发展，一些面向微服务架构的开发框架出现了，如 Twitter 的 Finagle 、 Facebook 的 Proxygen 以及 Spring Cloud 等等，这些框架实现了分布式系统通讯须要的各类通用语义功能：如负载均衡和服务发现等，所以必定程度上屏蔽了这些通讯细节，使得开发人员使用较少的框架代码就能开发出健壮的分布式系统。

时代5：第一代Service Mesh

第二代微服务模式看似完美，但开发人员很快又发现，它也存在一些本质问题：

• 其一，虽然框架自己屏蔽了分布式系统通讯的一些通用功能实现细节，但开发者却要花更多精力去掌握和管理复杂的框架自己，在实际应用中，去追踪和解决框架出现的问题也绝非易事；

• 其二，开发框架一般只支持一种或几种特定的语言，回过头来看文章最开始对微服务的定义，一个重要的特性就是语言无关，但那些没有框架支持的语言编写的服务，很难融入面向微服务的架构体系，想因地制宜的用多种语言实现架构体系中的不一样模块也很难作到；

• 其三，框架以 lib 库的形式和服务联编，复杂项目依赖时的库版本兼容问题很是棘手，同时，框架库的升级也没法对服务透明，服务会由于和业务无关的 lib 库升级而被迫升级。

所以以 Linkerd ，Envoy ，Ngixmesh 为表明的代理模式（边车模式）应运而生，这就是第一代 Service Mesh ，它将分布式服务的通讯抽象为单独一层，在这一层中实现负载均衡、服务发现、认证受权、监控追踪、流量控制等等分布式系统所须要的功能，做为一个和服务对等的代理服务，和服务部署在一块儿，接管服务的流量，经过代理之间的通讯间接完成服务之间的通讯请求，这样上边所说的三个问题也迎刃而解。

若是咱们从一个全局视角来看，就会获得以下部署图：

     

若是咱们暂时略去服务，只看Service Mesh的单机组件组成的网络：

相信如今，你们已经理解何所谓Service Mesh，也就是服务网格了。它看起来确实就像是一个由若干服务代理所组成的错综复杂的网格。

时代6：第二代Service Mesh

第一代 Service Mesh 由一系列独立运行的单机代理服务构成，为了提供统一的上层运维入口，演化出了集中式的控制面板，全部的单机代理组件经过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。
这就是以 Istio 为表明的第二代 Service Mesh 。

只看单机代理组件（数据面板）和控制面板的Service Mesh全局部署视图：

至此，见证了6个时代的变迁，你们必定清楚了Service Mesh技术究竟是什么，以及是如何一步步演化到今天这样一个形态。

如今，咱们再回过头来看 Buoyant 的 CEO William Morgan ，也就是 Service Mesh 这个词的发明人，对 Service Mesh 的定义：

服务网格是一个基础设施层，用于处理服务间通讯。云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭。在实际应用当中，服务网格一般是由一系列轻量级的网络代理组成的，它们与应用程序部署在一块儿，但对应用程序透明。

这个定义中，有四个关键词：

• 基础设施层+请求在这些拓扑中可靠穿梭：这两个词加起来描述了 Service Mesh 的定位和功能，是否是似曾相识？没错，你必定想到了 TCP ；

• 网络代理：这描述了 Service Mesh 的实现形态；

• 对应用透明：这描述了 Service Mesh 的关键特色，正是因为这个特色， Service Mesh 可以解决以 Spring Cloud 为表明的第二代微服务框架所面临的三个本质问题。

总结一下，Service Mesh 具备以下优势：

• 屏蔽分布式系统通讯的复杂性(负载均衡、服务发现、认证受权、监控追踪、流量控制等等)，服务只用关注业务逻辑；

• 真正的语言无关，服务能够用任何语言编写，只需和Service Mesh 通讯便可；

• 对应用透明，Service Mesh 组件能够单独升级，解耦架构和业务团队。

固然，Service Mesh 目前也面临一些挑战：

• Service Mesh 组件以代理模式计算并转发请求，必定程度上会下降通讯系统性能，并增长系统资源开销；

• Service Mesh 组件接管了网络流量，所以服务的总体稳定性依赖于 Service Mesh ，同时额外引入的大量 Service Mesh 服务实例的运维和管理也是一个挑战。

历史老是惊人的类似。为了解决端到端的字节码通讯问题，TCP 协议诞生，让多机通讯变得简单可靠；微服务时代，Service Mesh 应运而生，屏蔽了分布式系统的诸多复杂性，让开发者能够回归业务，聚焦真正的价值。

 

---

做者：陈鹏

了解更多微服务、云原生技术的相关信息！