Service Mesh是一种基础通信设施，它的出现时为了解决微服务之间复杂的通信问题。我们都知道，使用微服务思想去构建系统之后，会出现很多独立的微服务模块。模块之间的服务发现，负载均衡，失败重传等这些考虑因素，是每个模块都需要重复地去解决的，同时复杂性会随着模块数量增多而变大。
解决模块间通信问题之路
在计算机先驱引入了TCP/IP协议后，保证了链路层通信的可靠性。但是随着系统规模的扩大，引入了分布式，微服务这些概念，使一个系统的模块数量变得越来越多，模块间通信的可靠性就是个问题了，分布式通信需要解决下面几个问题：
-
服务发现。怎么让一个模块感知到其它的模块，硬编码是最简单的方式，但显然不是最好的方式。
-
负载均衡。一个模块有多台机器运行，怎么在多台机器上做负载均衡？除了手动做
IP轮询，需要有更丰富的轮询方式。 -
失败重传&熔断。当一个模块不可用时，需要能够重试，重试几次还不行就需要熔断机制来保证响应速度，避免请求堆积。
-
流量监控。日志，请求监控，链路追踪。这些是一个工业级别系统必须具备的基本能力。
-
流量控制。常见的有访问控制，频率限制，配额控制。
-
模块鉴权。模块之间的鉴权，入口模块需要具备的能力。
另外分布式系统还有应用生命周期管理的需求（发布，灰度，回滚，扩容，缩容等），这是另外一个维度的事情，后续再另写文章讲述。
为了解决这些问题，业界已经做出了很多努力。下面使用三个阶段来划分。
阶段一，自建服务
自建分布式服务是分布式发展的初级阶段，最开始应该是出现在各大互联网公司。随着互联网的普及，请求的量级开始上来，单机无法承载庞大的请求量，萌芽出来分布式处理的需求。各个互联网公司开始自建一些处理分布式的组件，比如负载均衡，流量监控，日志收集等。
该阶段的特点：
-
各个公司基本是自研分布式组件，自给自足
-
没有系统性，都是些比较零散的组件
-
开源的比较少
这个阶段写出来的实用组件为后续开源的标准框架打下了基础。
阶段二，标准框架
随着各大互联网公司在分布式上的积累和实践，渐渐对分布式系统有了些系统性梳理，从而产生出了一些成熟的分布式框架，下面是几个主流的框架。
这个阶段出现的框架，基本具有如下特点：
-
不同程度上解决了分布式通信的问题，各有优劣。具体选择哪种框架建议去详细了解下它们的特点和评价。
-
业务实现语言受框架语言限制。框架都是基于某种语言实现，业务代码基本是跟着框架语言走的。
-
框架对业务代码有侵入性的。因为为了使用框架的某些特性，必须在业务代码中使用框架提供的通信API和其它特性。这种耦合对代码的复用是有影响的。
这些框架虽然一定程度上简化了解决分布式通信问题的难度，但是显然还是不够灵活，业务代码还是需要去关心如何解决分布式通信问题，无法做到只需要关注业务代码。
下一阶段将讲述目前的最新进展，也就是致力于如何使业务代码只用关心业务的实现，不用去关心分布式通信问题。
阶段三，将通信问题协议化
大家都知道，TCP/IP协议栈的出现，是为了屏蔽链路层和物理层通信的各种细节，为广大程序员们提供一个省心稳定的字节流通道。现在在TCP/IP协议通信的基础上，又出现了了新的问题，那就是分布式通信的各种问题考虑，前面已经罗列了大部分。大神们为了解决这个问题，想到的办法就是把分布式通信的实现作为一种基础通信设施，作为协议栈的一部分提供给广大程序猿们，这样大家就不用重复去考虑实现分布式通信了。这个想法就是Service Mesh(服务网格)。
当然Service Mesh目前的实现不是以协议栈的形式提供的，而是以sidecar（边车）的形式提供。sidecar的意思与我们小时候看到的三轮车很类似，就是主驾旁边的那个副驾。
smsh1561600056.jpg
下图是
Service Mesh部署后的示意图，其中蓝色块就代表通信Proxy，通信Proxy就是实现了分布式通信，它作为sidecar与业务Service部署一起。业务Service之间的所有出入通信都会通过Proxy
service-mesh-from-linkerd-to-conduit-cloud-native-taiwan-meetup-18-638.jpg
目前最流行的两款
Service Mesh开源软件是Istio和Linkerd。其中Istio是由Google，IBM和Lyft联合开发的，而Linkerd是CNCF成员，两者都有深厚的背景，而目前Istio比Linkerd用的还是相对广泛一些。
下面是Istio的架构图
istio-arch.png
其中
Proxy还是以sidecar模式提供了可靠的分布式通信实现。其它模块实现了配置和策略检查等功能，后续再另写文章详细介绍。
结语
其实Service Mesh也不是什么高深的概念，说白了就是通过一个专门的agent来代理通信，让业务Service专注于实现业务逻辑，而agent就专注于实现可靠的分布式逻辑。本文通过讲解发展历史的方式来解释了这种思想。
另外文中还没讲到的是目前Service Mesh的应用，大部分都是云原生的，基于容器服务Kubernetes之上实现的。关于容器服务Kubernetes的讲解，可以去参考它的官网资料，或者关注我后期的相关文章。
版权声明：本文为原创文章，版权归 Roper所有，转载请注明出处！
网友评论