开发者社区> Barnett> 正文

Rainbond 内置 ServiceMesh架构分析

简介: 在 Cloud Native 架构下,容器的使用给予了异构应用程序的更多可行性,kubernetes 增强的应用的横向扩容能力,用户可以快速的编排出复杂环境、复杂依赖关系的应用程序,同时开发者又无须过分关心应用程序的监控、扩展性、服务发现、负载均衡和分布式追踪这些繁琐的事情而专注于程序开发,赋予开发者更多的创造性。
+关注继续查看

ServiceMesh

一般的字面解释是“服务网格”,作为时下最流行的分布式系统架构微服务的动态链接器,处于服务到服务的通信的专用基础设施层,该层独立于应用程序为服务之间的通信提供轻量级的可靠传递。如果简单的描述的话,可以将它比作是应用程序或者说微服务间的 TCP/IP,负责服务之间的网络调用、限流、熔断和监控,同样使用 ServiceMesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情,比如 Spring Cloud架构,现在只要交给 ServiceMesh 就可以了。ServiceMesh的出现主要是由于应用虚拟化技术的发展,例如Kubernetes, Rainbond等项目,大大降低了应用的部署和运维复杂度。


servicemesh-arch.png

微服务架构对比

servicemesh-compare.png

为何使用ServiceMesh

ServiceMesh 并没有给我们带来新功能,它是用于解决其他工具已经解决过的问题,只不过这是在 Cloud Native 的云原生环境下将过去复杂的人工运维工作有机的自动化管理。

在传统的 MVC 三层 Web 应用程序架构下,服务之间的通讯并不复杂,在应用程序内部自己管理即可,但是在现今的复杂的大型网站情况下,单体应用被分解为众多的微服务,服务之间的依赖和通讯十分复杂,出现了 twitter 开发的 Finagle、Netflix 开发的 Hystrix 和 Google 的 Stubby 这样的 “胖客户端” 库,这些就是早期的 ServiceMesh,但是它们都近适用于特定的环境和特定的开发语言,并不能作为平台级的 ServiceMesh 支持。

在 Cloud Native 架构下,容器的使用给予了异构应用程序的更多可行性,kubernetes 增强的应用的横向扩容能力,用户可以快速的编排出复杂环境、复杂依赖关系的应用程序,同时开发者又无须过分关心应用程序的监控、扩展性、服务发现、负载均衡和分布式追踪这些繁琐的事情而专注于程序开发,赋予开发者更多的创造性。如果你是符合以下场景,推荐选择ServiceMesh架构:

  1. 遗留庞大系统逐步过渡到微服务架构
  2. 业务系统由多种开发语言开发

ServiceMesh相对其他微服务架构优势

  • 最大层度透明

ServiceMesh通过全局控制层控制服务与服务之间的调用关系,服务的治理策略。对于服务本身来说,只需要站在单机的维度考虑上游服务的依赖通信,采用简单的通信协议例如HTTP,gRPC等。Mesh层透明的发现上游目标,进行重试/超时、监控、追踪。为单机服务赋予分布式系统能力。

  • 学习成本低

过去我们要设计搭建一个完整的微服务架构,比如SpringCloud,Dubbo等,免不了需要改变我们传统的编程思想,学习复杂的架构框架,例如SpringCloud,其包含各类组件10余个,基本与服务业务本身没有直接关系。对于大多数业务开发者来说是一个高高的门槛。但是使用ServiceMesh架构,由于其最大化的透明,开发者几乎不需要额外学习与业务无关的框架技术。大大降低了学习成本。

  • 架构灵活

对于不同的团队组成,可能拥有具有掌握不同开发语言的成员,或者具有成熟的已实现业务系统。如果转变到微服务架构支持更大量级用户,如果使用SpringCloud架构,免不了对系统进行重构甚至重写。面对现实与未来,我们需要逐步落地微服务架构,使用合适的开发语言开发合适的服务,甚至融合多种轻量级架构模式,比如Dubbo,SpringBoot和LNMP架构。

ServiceMesh架构性能

有人提出,在服务与服务之间增加两层代理对性能会产生较大影响,对于性能问题,我们应该放眼全局,从以下几个方面分析:

  1. 对于增加代理响应性能问题在所有的微服务架构中都存在。
  2. ServiceMesh的网络代理层一般采用轻量级的高效率的代理实现,其本身性能通常较为优越。
  3. ServiceMesh为了提供更好的治理功能支持,通信模型一般处在应用层,比如处理(http,grpc,mongo,mysql)等协议。如果对性能要求比较高,也可以直接使用4层网络模型。
  4. ServiceMesh一般面向中大型分布式系统,分布式系统直接本身就会有通信消耗,Mesh层相反可以使用更高效的通信协议比如http/2 来优化通过http/1.1协议通信的服务通信过程。

ServiceMesh只对网络进行治理么?

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

  • 服务发现和负载均衡
  • 高级路由
  • 通信监控和分析
  • 通信安全

对于Rainbond的架构设计来说还通过插件扩展的方式增加以下方面功能:

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

Rainbond与ServiceMesh

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

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

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

Rainbond提供给用户的体验是最大化的透明,即用户将服务运行于Rainbond即已经构成了微服务架构,而无需先学习微服务架构知识,再考虑自己的服务如何改造,最后再落地。


sm-arh.png

如下图可知,Rainbond的网络治理插件通过Sidecar的方式在应用的同一个网络命名空间,同一个存储空间,同一个环境变量空间内动态启动第三方插件服务,例如envoy服务,通过与Rainbond应用运行时通信完成从应用空间到平台空间的数据交换,实现平台对应用通信的控制。


servicemesh-sidecar.png

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
darwin Stream Server源码分析
摘要 ​所谓的流式媒体简单的讲就是指人们通过网络实时的收看多媒体信息:如音频流、视频流等。与流式媒体对应的传统工作方式是下载+播放模式,即用户首先下载多媒体文件,然后再在本地播放,这种方法的一个主要缺点是启动延迟较大,例如一个30分钟长的MPEG-I文件(相当于VCD质量),即使使用1.5Mbps的速率下载,也需要半个小时才能完成,这样一个漫长的等待时间实在是无法忍受。
1223 0
【Android 事件分发】事件分发源码分析 ( 驱动层通过中断传递事件 | WindowManagerService 向 View 层传递事件 )
【Android 事件分发】事件分发源码分析 ( 驱动层通过中断传递事件 | WindowManagerService 向 View 层传递事件 )
64 0
Darwin Streaming Server 核心代码分析
基本概念首先,我针对的代码是Darwin Streaming Server 6.0.3未经任何改动的版本。Darwin Streaming Server从设计模式上看,采用了Reactor的并发服务器设计模式,如果对Reactor有一定的了解会有助于对Darwin Streaming Server核心代码的理解。
1171 0
Memcached命令执行漏洞(CVE-2016-8704、CVE-2016-8705、CVE-2016-8706)原理和对阿里云Memcache影响分析
Memcached是一个广泛使用的高速缓存系统,近期研究者发现小于1.4.33的版本存在3个整数溢出漏洞,通过这几个漏洞攻击者可以触发堆溢出导致crash,这里对漏洞做了分析和验证。尔后验证了阿里云ApsaraDB for Memcache不受漏洞影响,并分析了原因。
7184 0
【转】Darwin Streaming Server 核心代码分析
无意中看到了dqzhangp的一篇博客,分析了DSS的核心架构,读完顿时感觉豁然开朗,茅塞顿开,写得非常的鞭辟入里,言简意赅,我想没有相当的功力是写不出这样的文章的,情不自禁转到自己空间来,生怕弄丢了。
1450 0
DaemonSet 案例分析 - 每天5分钟玩转 Docker 容器技术(130)
本节详细分析两个 k8s 自己的 DaemonSet:kube-flannel-ds 和 kube-proxy 。
6289 0
【Android 进程保活】应用进程拉活 ( 系统 Service 机制拉活 | Service 组件 onStartCommand 方法分析 | 源码资源 )(一)
【Android 进程保活】应用进程拉活 ( 系统 Service 机制拉活 | Service 组件 onStartCommand 方法分析 | 源码资源 )(一)
22 0
【Android 进程保活】应用进程拉活 ( 系统 Service 机制拉活 | Service 组件 onStartCommand 方法分析 | 源码资源 )(二)
【Android 进程保活】应用进程拉活 ( 系统 Service 机制拉活 | Service 组件 onStartCommand 方法分析 | 源码资源 )(二)
21 0
+关注
22
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
JS零基础入门教程(上册)
立即下载
性能优化方法论
立即下载
手把手学习日志服务SLS,云启实验室实战指南
立即下载