什么是ServiceMesh
一般的字面解释是“服务网格”，作为时下最流行的分布式系统架构微服务的动态链接器，处于服务到服务的通信的专用基础设施层，该层独立于应用程序为服务之间的通信提供轻量级的可靠传递。如果简单的描述的话，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控，同样使用 ServiceMesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 ServiceMesh 就可以了。ServiceMesh的出现主要是由于应用虚拟化技术的发展，例如Kubernetes,Rainbond等项目，大大降低了应用的部署和运维复杂度。
mesh.png1282x778 54.5 KB
为何使用ServiceMesh
ServiceMesh 并没有给我们带来新功能，它是用于解决其他工具已经解决过的问题，只不过这次是在 Cloud Native 的 kubernetes 环境下的实现。
在传统的 MVC 三层 Web 应用程序架构下，服务之间的通讯并不复杂，在应用程序内部自己管理即可，但是在现今的复杂的大型网站情况下，单体应用被分解为众多的微服务，服务之间的依赖和通讯十分复杂，出现了 twitter 开发的 Finagle、Netflix 开发的 Hystrix 和 Google 的 Stubby 这样的 “胖客户端” 库，这些就是早期的 ServiceMesh，但是它们都近适用于特定的环境和特定的开发语言，并不能作为平台级的 ServiceMesh 支持。
在 Cloud Native 架构下，容器的使用给予了异构应用程序的更多可行性，kubernetes 增强的应用的横向扩容能力，用户可以快速的编排出复杂环境、复杂依赖关系的应用程序，同时开发者又无须过分关心应用程序的监控、扩展性、服务发现和分布式追踪这些繁琐的事情而专注于程序开发，赋予开发者更多的创造性。
image.png2314x1178 481 KB
ServiceMesh相对其他微服务架构优势
最大层度透明
ServiceMesh通过全局控制层控制服务与服务之间的调用关系，服务的治理策略。对于服务本身来说，只需要站在单机的维度考虑上游服务的依赖通信，采用简单的通信协议例如HTTP，gRPC等。Mesh层透明的发现上游目标，进行重试/超时、监控、追踪。为单机服务赋予分布式系统能力。
学习成本低
过去我们要设计搭建一个完整的微服务架构，比如SpringCloud,Dubbo等，免不了需要改变我们传统的编程思想，学习复杂的架构框架，例如SpringCloud,其包含各类组件10余个，基本与服务业务本身没有直接关系。对于大多数业务开发者来说是一个高高的门槛。但是使用ServiceMesh架构，由于其最大化的透明，开发者几乎不需要额外学习与业务无关的框架技术。大大降低了学习成本。
架构灵活
对于不同的团队组成，可能拥有具有掌握不同开发语言的成员，或者具有成熟的已实现业务系统。如果转变到微服务架构支持更大量级用户，如果使用SpringCloud架构，免不了对系统进行重构甚至重写。面对现实与未来，我们需要逐步落地微服务架构，使用合适的开发语言开发合适的服务，甚至融合多种轻量级架构模式，比如Dubbo,SpringBoot和LNMP架构。
性能思考
有人说，在服务与服务之间增加代理对性能会产生较大影响。对于性能问题，我们应该放眼全局。
首先，ServiceMesh的网络代理层一般采用轻量级的高效率的代理实现，其本身性能非常优越。为了提供更好的功能支持，通信模型一般处在应用层，比如处理（http,grpc,mongo,mysql）等协议。如果对性能要求比较高，也可以直接使用4层网络模型。
最后，ServiceMesh一般面向中大型分布式系统，分布式系统直接本身就会有通信消耗，例如自身通过http/1.1协议通信，mesh层还可以通过http/2协议优化性能。
image.png2308x1138 368 KB
ServiceMesh只处理网络么？
ServiceMesh架构框架主要通过治理网络通信提供一系列服务治理功能，对于Rainbond的设计来说，ServiceMesh不仅仅提供网络治理，也包括信息安全、日志处理、数据备份等开箱即用的插件功能。
