【架构】Service Mesh

概述

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 ？

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。