概述

Service Mesh 公认的定义，是用以处理服务与服务之间通信的专用基础设施层。更本质的理解，它是服务治理平台，是业务逻辑解耦的必然产物，是数字经济背景下企业对研发效能提升的选择。

服务端架构从单体模块化架构，到 SOA（面向服务架构），到经典微服务架构（服务间采用 RPC 通信），到最新的 Service Mesh，就是一个不断强调解耦和复用的演进历程。

• 单体模块化架构强调业务逻辑按模块划分
• SOA 强调业务逻辑在应用粒度的复用（水平拆分）
• 经典微服务架构强调业务逻辑在应用粒度的解耦（垂直拆分）
• Service Mesh 则强调业务逻辑与服务治理逻辑的分层及解耦
  

Service Mesh 是所有架构模式中解耦和复用最彻底的，它不仅仅强调业务逻辑的解耦和复用，更强调基础设施的解耦和复用。

传统通过 Spring Cloud 实现服务治理的方式，服务治理与业务逻辑耦合在一起，部署、运维都耦合了微服务本身的操作。比如一个 RPC 框架的 bugfix 会引发所有微服务旷日长久的升级发布，同时带来业务开发人员开发、测试、回归、发布的巨大重复工作量。而 Service Mesh 通过将与业务逻辑无关的服务治理逻辑下沉，让业务开发人员与基础技术开发人员关注点分离，各司其职，大大提升了研发效能。

微服务架构对比

Rainbond与ServiceMesh

ServiceMesh架构框架是工作在网络通信层面提供一系列服务治理功能，包括：

服务发现和负载均衡
高级路由
通信监控和分析
通信安全
对于Rainbond的架构设计来说还通过插件扩展的方式增加以下方面功能：

日志处理
数据备份和恢复
服务运维和监控
服务运行环境保障

Rainbond原生提供全量的ServiceMesh治理功能方案，同时提供了插件化得扩展策略，用户除了使用默认方案以外也可以自定义插件实现。Rainbond与Istio的实现有共同点，也有天然的不同。

相同点是都实现了基于XDS规范实现全局控制层，支持envoy和istio-proxy。

不同点是Istio需要依赖Kubernetes等平台工作，微服务架构的支持需要从底层存储与通信到上层的应用层配置全盘考虑，大型的微服务架构是离开不了自动化管理应用的PaaS平台的。Rainbond从硬件层，通信层，平台层实现不同的控制逻辑，既兼容已有的微服务架构，同时提供了完整的ServiceMesh微服务架构实践。包容的架构形式让已有的应用服务化变得可落地。

Rainbond提供给用户的体验是最大化的透明，即用户将服务运行于Rainbond即已经构成了微服务架构，而无需先学习微服务架构知识，再考虑自己的服务如何改造，最后再落地。
如下图可知，Rainbond的网络治理插件通过Sidecar的方式在应用的同一个网络命名空间，同一个存储空间，同一个环境变量空间内动态启动第三方插件服务，例如envoy服务，通过与Rainbond应用运行时通信完成从应用空间到平台空间的数据交换，实现平台对应用通信的控制。

来源

ServiceMesh微服务架构简介
Service Mesh 深度集成 service mesh 架构
到底什么是 Service Mesh ？如何评价 Service Mesh ？