一起走入Service Mesh的世界

一起走入Service Mesh的世界

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

那么到底什么是Service Mesh？

通俗的理解：Service Mesh是微服务时代的TCP协议。

 

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

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

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

目前业界跟微服务相关的开发平台和框架更是不胜枚举：Spring Cloud， Linkerd，Envoy，Istio ...

这些纷繁的产品和Sevice Mesh有什么样的关联？哪些属于Service Mesh的范畴？

 

为了理清这些繁复的产品和概念，我们先来了解下微服务和Service Mesh技术的历史发展脉络。

了解清楚了技术的主要脉络，就能清晰的知道上述的各个平台、框架属于技术脉络中的哪个结点，其间的关系也就一目了然。

这里结合自己的理解并予以简化，试图说清楚ServiceMesh的概念和这项技术诞生的历史必然性。

 

时代1：第一代微服务

 

首先我们来看看我们想做什么，最初的时候呢，我们在做一个业务系统开发的时候，在写一些业务逻辑的时，难免会需要增加一些网络控制相关的逻辑。为什么呢，因为大家都知道我们目前其实绝大部分一定都是分布式系统，或者是微服务系统，它一定会有网络的问题，因为你的服务。都是在不同的进程中运行，比如说你需要有一些过载保护，你需要做一些限流等等一系列的这些服务治理的功能，不得不去加入很多的控制逻辑，但是在最初的时候，我们其实对整个的这些网络流量控制相关的功能。是非常模糊的，没有一个完善的认识，或者说没有把它抽取出来，所以最开始呢，可能我们写代码就是写一段业务逻辑，然后同时加一些网络控制的逻辑，这样就是耦合在一起，比如说你很可能见到这样的代码，就是一个for循环，这里边儿呢，可能是调用一个远端的服务，比如说是一个HTTP调用或者说RPC，如果不出错就跳出，这样的逻辑呢，我们把它叫控制逻辑，他呢，被夹杂在这个业务逻辑中，导致你的业务逻辑是非常混乱，整体维护啊，各方面都是。为了消除这个问题，我们就演变到了第二代微服务的阶段(公共库阶段)

 

时代2：第二代微服务

为了避免每个服务都需要自己实现一套分布式系统通信的语义功能，随着技术的发展，一些面向微服务架构的开发框架出现了，比如Spring Cloud，这些框架实现了分布式系统通信需要的各种通用语义功能：如负载均衡和服务发现，熔断， 服务治理，流量控制等等这些网络控制逻辑都包装在一起，封装成类库或者工具包的方式，供我们具体的应用程序去调用。因此一定程度上屏蔽了这些通信细节，使得开发人员使用较少的框架代码就能开发出健壮的分布式系统，一定程度上与业务系统解耦，做到复用。

时代3：代理模式(SideCar前身)

---

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

• 其一，虽然框架本身屏蔽了分布式系统通信的一些通用功能实现细节，但是他的类库十分的丰富，学习的成本高，开发者却要花更多精力去掌握和管理复杂的框架本身，在实际应用中，去追踪和解决框架出现的问题也绝非易事；

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

• 其三，框架以lib库的形式和服务联编，复杂项目依赖的库版本兼容问题非常棘手，同时，框架库的升级也无法对服务透明，服务会因为和业务无关的lib库升级而被迫升级，部署，维护的人力的成本高；

• 其四：依然需要和业务整合，比如引入配置文件等，编译之后他的这些类库依然会注入到应用程序中，还是有耦合的问题。

 

 

下面说一下代理，代理其实我们用到的场景很多，就像非常著名的webserver，如apache，nginx等等这些，这些都是代理，他们能够帮我们做一些基本的流控，负载均衡，比如nginx配置里面配upstream，设置一些权重，就能做到反向代理。负载均衡，他提供的功能还是比较基础。但是它的思路是正确的。通过代理的方式完全做到了服务的解耦，逻辑代码和代理直接没有任何的关联， 我们可能只需要配置一些dns解析。这为第一代Servicemesh 提供了非常好的方向。

 

 

时代4：第一代Service Mesh

因此以Linkerd，Ngixmesh为代表的代理模式（边车模式）sidecar应运而生，sidecar可以理解为一个单轮的工具附着在摩托车上形成一个三轮的交通工具，抗日神剧日本人骑得摩托车旁边的副驾驶就可以理解为sidecar,放到摩托车上可能就是导航，查看道路信息的作用，放到我们的微服务中来理解。他和我们的代理，公共的类库的作用是一致的，它将分布式服务的通信抽象为单独一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能， 作为一个和服务对等的代理服务，和服务部署在一起，接管服务的流量，通过代理之间的通信间接完成服务之间的通信请求，这样上边所说的几个问题(网络控制，解耦)也迎刃而解。

如果我们从一个全局视角来看，就会得到如下部署图(绿色的是微服务，蓝色的就是sidecar)，一个系统中所有的sidecar组成的网络拓扑就是servicemesh：

如果我们暂时略去服务，只看Service Mesh的单机组件组成的网络：

相信现在，大家已经理解何所谓Service Mesh，也就是服务网格了。它看起来确实就像是一个由若干服务代理所组成的错综复杂的网格。我们刚刚这个产品形态称为第一代的service mesh

 

时代6：第二代Service Mesh

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

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

 

至此，见证了6个时代的变迁，大家一定清楚了ServiceMesh技术到底是什么，以及是如何一步步演化到今天这样一个形态。

下面再来看看服务网格的定义：

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

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

基础设施层+请求在这些拓扑中可靠穿梭：这两个词加起来描述了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应运而生，屏蔽了分布式系统的诸多复杂性，让开发者可以回归业务，聚焦真正的价值。

 

 

下一篇我将关于service mesh选型以及部署实例

 

 

本文参考网上的文章加上自己的理解，如有侵权，请联系我，谢谢