详解Rainbond内置ServiceMesh微服务架构

目录
  • ServiceMesh
  • 微服务架构对比
  • 为何使用ServiceMesh
  • ServiceMesh相对其他微服务架构优势
    • 最大层度透明
    • 学习成本低
    • 架构灵活
  • ServiceMesh架构性能
  • ServiceMesh只对网络进行治理么？
  • Rainbond与ServiceMesh

ServiceMesh

一般的字面解释是“服务网格”，作为时下最流行的分布式系统架构微服务的动态链接器，处于服务到服务的通信的专用基础设施层，该层独立于应用程序为服务之间的通信提供轻量级的可靠传递。

如果简单的描述的话，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控，同样使用 ServiceMesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud架构，现在只要交给 ServiceMesh 就可以了。

ServiceMesh的出现主要是由于应用虚拟化技术的发展，例如Kubernetes, Rainbond等项目，大大降低了应用的部署和运维复杂度。

微服务架构对比

为何使用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架构性能

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

对于增加代理响应性能问题在所有的微服务架构中都存在。

ServiceMesh的网络代理层一般采用轻量级的高效率的代理实现，其本身性能通常较为优越。

ServiceMesh为了提供更好的治理功能支持，通信模型一般处在应用层，比如处理（http,grpc,mongo,mysql）等协议。如果对性能要求比较高，也可以直接使用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即已经构成了微服务架构，而无需先学习微服务架构知识，再考虑自己的服务如何改造，最后再落地。

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

以上就是详解Rainbond内置ServiceMesh微服务架构的详细内容，更多关于Rainbond内置ServiceMesh微服务的资料请关注我们其它相关文章！

赞 (0)

相关推荐

  • Rainbond配置组件自动构建部署官方文档讲解

    Rainbond配置组件自动构建部署官方文档讲解

    目录 前言 前提条件 基于源代码操作流程 1.开启组件 Git-Webhook 2.配置代码仓库 基于镜像仓库操作流程 1.开启镜像仓库 Webhook 自动构建 2.Tag 触发自动修改策略 3.配置镜像仓库 API 触发自动构建 前言 通过自动构建的功能,可以实现代码或镜像提交后组件自动触发构建和部署,Rainbond 提供了基于代码仓库 Webhooks.镜像仓库 Webhooks 和自定义 API 三种方式触发组件自动部署.自动构建的功能可以辅助开发者便捷的实现敏捷开发. 前提条件 组件

  • Rainbond使用Dockerfile构建便捷应用运行流程

    Rainbond使用Dockerfile构建便捷应用运行流程

    目录 Dockerfile构建运行镜像 Dockerfile构建运行镜像 Rainbond平台支持直接通过Dockerfile**构建并运行镜像,操作流程简单,方便进行持续迭代. 操作流程分为以下几步: 在Github上创建Dockerfile项目,Demo项目 Dockerfile内容 ARG VERSION=1.15.0 FROM nginx:${VERSION}-alpine COPY index.html /usr/share/nginx/html/ VOLUME /data EXPOS

  • Rainbond调用Vue React项目的后端接口

    Rainbond调用Vue React项目的后端接口

    目录 前言 解决跨域对于不同的场景有以下几种方法: 接口没有统一 接口统一 源码部署后端 Dockerfile源码构建部署Mysql Docker镜像部署Redis Java源码构建部署 SpringBoot Rainbond中怎么部署 Vue .React 项目请参考 Rainbond部署Vue.React项目 前言 以往我们在部署前端项目后,调用后端接口有以下几种场景: 后端接口没有统一,比较分散,例如:/system/user,/tool/gen . 通常我们会在项目的全局配置文件.env

  • Rainbond的ServiceMesh架构组件端口冲突处理解决

    Rainbond的ServiceMesh架构组件端口冲突处理解决

    目录 组件间的通讯问题 方式一:通过HTTP 7层网络治理进行端口复用 方式二:动态变更组件的监听端口 方式三:使用 Kubernetes 原生 Service 治理模式 方式四:使用 Istio 网络治理模式 组件间的通讯问题 在我们部署具有多个服务的分布式业务时,必须要考虑的一点就是如何处理服务之间的通信问题,那么当我们将业务部署到Rainbond 上时,又是如何去处理的呢? Rainbond 开箱即用的ServiceMesh架构默认通过 Sidecar 代理的方式,为我们透明的解决了分布式

  • Rainbond对前端项目Vue及React的持续部署

    Rainbond对前端项目Vue及React的持续部署

    目录 前言: 部署前检查 1.1 添加 nodestatic.json 文件 1.2 添加 web.conf 文件 1.3 源码部署Vue项目 常见问题 前言: 以往我们在部署 Vue.React 前端项目有几种方法: 项目打包好之后生成dist目录,将其放入nginx中,并进行相应的访问配置. 将项目打包好放入tomcat中. 将项目打包好的dist目录中的static和index.html文件放入springboot项目的resources目录下 直接运行一个前端server,类似本地开发那

  • Rainbond网络治理插件ServiceMesh官方文档说明

    Rainbond网络治理插件ServiceMesh官方文档说明

    目录 ServiceMesh网络治理插件 插件实践​ 综合网络治理插件​ 入站方向​ 出站方向​ 出站网络治理插件​ ServiceMesh网络治理插件 5.1.5版本后,Rainbond默认提供了综合网络治理插件(同时处理入站和出站网络)和出站网络治理插件两个插件可用. 网络治理插件工作在与业务容器同一个网络空间之中,可以监听一个分配端口,拦截入站的业务流量进行限流.断路等处理再将流量负载到业务服务的实际监听端口之上. 同时也可以工作在出站方向,业务服务需要访问上游服务时,通过访问本地出站治理

  • 详解Rainbond内置ServiceMesh微服务架构

    详解Rainbond内置ServiceMesh微服务架构

    目录 ServiceMesh 微服务架构对比 为何使用ServiceMesh ServiceMesh相对其他微服务架构优势 最大层度透明 学习成本低 架构灵活 ServiceMesh架构性能 ServiceMesh只对网络进行治理么? Rainbond与ServiceMesh ServiceMesh 一般的字面解释是“服务网格”,作为时下最流行的分布式系统架构微服务的动态链接器,处于服务到服务的通信的专用基础设施层,该层独立于应用程序为服务之间的通信提供轻量级的可靠传递. 如果简单的描述的话,可

  • 详解Typescript 内置的模块导入兼容方式

    一.前言 前端的模块化规范包括 commonJS.AMD.CMD 和 ES6.其中 AMD 和 CMD 可以说是过渡期的产物,目前较为常见的是commonJS 和 ES6.在 TS 中这两种模块化方案的混用,往往会出现一些意想不到的问题. 二.import * as 考虑到兼容性,我们一般会将代码编译为 es5 标准,于是 tsconfig.json 会有以下配置: { "compilerOptions": { "module": "commonjs&qu

  • 详解scrapy内置中间件的顺序

    1. 内置下载器中间件顺序 {'scrapy.downloadermiddlewares.ajaxcrawl.AjaxCrawlMiddleware': 560, 'scrapy.downloadermiddlewares.cookies.CookiesMiddleware': 700, 'scrapy.downloadermiddlewares.defaultheaders.DefaultHeadersMiddleware': 400, 'scrapy.downloadermiddleware

  • 详解JSP 内置对象request常见用法

    详解JSP 内置对象request常见用法

    request 对象是 HttpServletRequestWrapper 类的实例.它的继承体系如下: _request 对象继承层次结构图.png ServletRequest 接口的唯一子接口是 HttpServletRequest ,HttpServletRequest 接口的唯一实现类 HttpServletRequestWrapper ,单从 request 对象一脉单传的类继承体系可以看出,javaweb 标准类库只支持了 http 协议. Servlet/JSP 中大量使用了接口

  • 详解PHP内置访问资源的超时时间 time_out file_get_contents read_file

    提问我循环用file_get_contents抓取一堆url,但总是会在不到第100个URL的时候停下,提示我:"Warning: file_get_contents(URL) [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.0 500 Read timed outin D:\website\extra.php on line 65"我在程序的开始已经有set_time_l

  • 详解IDEA启动多个微服务的配置方法

    使用IDEA开发微服务项目,需要启动多个微服务,可以开启IDEA的Run DashBoard窗口,需要对IDEA中指定工程的父工程进行配置进行修改. 首先找到.idea文件下的workspace.xml,并找到RunDashboard 加入如下配置: <option name="configurationTypes"> <set> <option value="SpringBootApplicationConfigurationType"

  • 详解python内置常用高阶函数(列出了5个常用的)

    高阶函数是在Python中一个非常有用的功能函数,所谓高阶函数就是一个函数可以用来接收另一个函数作为参数,这样的函数叫做高阶函数. python内置常用高阶函数: 一.函数式编程 •函数本身可以赋值给变量,赋值后变量为函数: •允许将函数本身作为参数传入另一个函数: •允许返回一个函数. 1.map()函数 是 Python 内置的高阶函数,它接收一个函数 f 和一个 list, 并通过把函数 f 依次作用在 list 的每个元素上,得到一个新的 list 并返回 def add(x): ret

  • 微服务架构之服务注册与发现实践示例详解

    微服务架构之服务注册与发现实践示例详解

    目录 1 服务注册中心 4种注册中心技术对比 2 Spring Cloud 框架下实现 2.1 Spring Cloud Eureka 2.1.1 创建注册中心 2.1.2 创建客户端 2.2 Spring Cloud Consul 2.2.1 Consul 的优势 2.2.2 Consul的特性 2.2.3 安装Consul注册中心 2.2.4 创建服务提供者 3 总结 微服务系列前篇 详解微服务架构及其演进史 微服务全景架构全面瓦解 微服务架构拆分策略详解 微服务架构之服务注册与发现功能详解

  • 微服务架构拆分策略详解

    微服务架构拆分策略详解

    目录 1 微服务迁移准备 2 微服务颗粒的拆分策略 2.1 基于业务逻辑拆分 2.1.1 领域模型拆分 2.1.2 用户群体拆分 2.2 基于可扩展拆分 2.3 基于可靠性拆分 2.3.1 核心模块拆分 2.3.2 主次链路拆分 2.4 基于性能需求拆分 3 总结拆分原则 微服务架构及其演进史 微服务全景架构全面瓦解 前面我们学习了微服务的全景架构,了解到相对于传统单体架构,微服务的优势,以及系统服务化的发展趋势. 对于新启动的项目,我们在权衡之后可以大方的使用微服务架构.但其实大部分情况下,我

  • 详解Java 微服务架构

    详解Java 微服务架构

    一.传统的整体式架构 传统的整体式架构都是模块化的设计逻辑,如展示(Views).应用程序逻辑(Controller).业务逻辑(Service)和数据访问对象(Dao),程序在编写完成后被打包部署为一个具体的应用.如图所示: 系统的水平扩展 如果要对系统进行水平扩展,通常情况下,只需要增加服务器的数量,并将打包好的应用拷贝到不同的服务器,然后通过负载均衡器(Nginx)就可以轻松实现应用的水平扩展. 整体式架构的缺点 应用复杂度增加,更新.维护困难. 易造成系统资源浪费. 影响开发效率. 应用

随机推荐