解析rainbond以应用为中心的架构设计原理

目录
  • 前言碎语
  • 一、云计算的发展
  • 二、企业价值与IT
  • 三、服务模式
  • 四、以应用为中心的产品设计
    • 应用的生产阶段
    • 应用运行阶段
    • 应用传播阶段
  • 五、面向未来

前言碎语

今天博主安利一个国产开源的无服务器容器云平台,关注它已经有一年多了,虽然其迭代到现在很多功能还是一直处于测试验证中,但是其设计理念以应用为中心,我觉得这个是未来的趋势。

其实以docker+k8s这种架构也是一种以应用为中心的架构,rainbond底层深度集成k8s,为用户提供云原生应用全生命周期解决方案,构建应用与基础设施、应用与应用、基础设施与基础设施之间互联互通的生态体系,满足支撑业务高速发展所需的敏捷开发、高效运维和精益管理需求。

github:https://github.com/goodrain/rainbond

一、云计算的发展

回顾云计算产业与技术的发展路程,物理计算集群逐步被IaaS层虚拟化取代,国内例如阿里云,腾讯云等IaaS厂商布局多年。IaaS层解决了资源提供者与使用者的耦合问题,对于用户来说只需要选择使用什么操作系统,分配多大资源上限即可,一定层度上降低了用户交付应用价值的难度。

但是,用户依然需要重复得进行操作系统运维,环境与应用运维,技术难度依然很高。近两年,以Docker、Kubernetes为代表的容器与容器编排技术盛行,其实际上是将虚拟化进一步上移,更加面向应用,可以说容器化是对应用的虚拟化。在这样的基础上用户创造和交付大规模业务系统变得更加简单。

我们认为,云计算的发展更多的是让大部分公司和人群只需要关注和创造业务系统,关注业务逻辑,而不是将大量时间和人力投入到复杂的,重复的计算资源维护上,因此只是容器化还不能达到这个层次,我们希望将云计算推向到下个阶段:应用管理阶段,呈现出两个产品,无服务器PaaS和云原生SaaS。

二、企业价值与IT

上文我们提出了应用管理的概念,那么应用管理对于我们大多数企业IT有多大的价值呢?

对于大多数IT企业和互联网企业,企业价值的直接体现在于创造的应用或运营的应用本身,也就是说在业务本身上。然而我们都知道,一个业务系统需要运行,必须得搭建运行环境,考虑网络、存储、配置、负载均衡、安全等等一系列复杂的计算资源管理问题,而且每一次系统搭建都重复得进行,往往在这些问题上花费大量的成本。

我们在应用与计算资源管理这两者之间增加一层应用管理(无服务器PaaS和云原生SaaS),完全以应用为中心进行设计,将应用与计算资源解耦,应用管理之上,开发或使用人员只需要关注业务设计,编码,测试,上线流程环,应用管理平台自动化完成从源码到云端运行的复杂流程。

开发者无需再面对底层计算资源的管理复杂性,也就解除了对传统的运维人员的依赖,同时对于运维人员,只需要在平台自动化资源管理的基础上维护资源池稳定,两者责任清晰,边界清晰,天然的解决了DevOps问题。经过与大量用户沟通实践后我们发现,应用管理成为了提升企业IT能力的关键。

三、服务模式

完整的应用管理方案包括:

  • 北向的应用抽象管理
  • 南向的计算资源管理

Rainbond产品按照这样的设计思路应运而生。在应用管理方面,我们设计了应用抽象模型,面向企业IT系统和基础应用,例如互联网类应用,行业类应用,物理网类应用以及大数据技术类应用等。

针对微服务架构的支持,除了兼容已有的微服务架构以外,原生提供了Service Mesh架构的支持,对上诉多种类型的单体应用,新老应用实现规模化整合,对各类型应用提供标准的、完整的功能支持。

当然,不同的应用在高级需求上是不同的,例如MySQL需要热备份,外网访问应用需要防火墙等等需求我们设计了应用插件体系,对应用功能进行差异化,无侵入式扩展。

在计算资源管理方面,对不同的计算资源进行统一的池化,软件定义,提供标准的计算服务。除了在公有云计算资源之上,目前我们尝试了在地方IDC厂商,企业私有已有的x86-64架构计算资源之上搭建Rainbond数据中心。

我们正朝着资源全自动运维的目标前进。对于用户来说,取需要的任何应用,运行于需要的计算资源之上,按需组合,灵活组合,最终提供了SaaS化得服务。

四、以应用为中心的产品设计

Rainbond基本的设计思想就是 以应用为中心,近年来该理念也被业界同行和更多用户所认同,Rainbond提供了应用完整的生命周期管理:

应用的生产阶段

Rainbond从设计上就支持从各类型软件源构建生产应用,从各类型编程语言源码,已经打包的容器镜像,更包括定义好的DockerCompose文件等等。Rainbond定义应用的各层面元素,就像一个生产线,输入各种代码,生产出统一的应用。

应用运行阶段

Rainbond软件抽象管理存储,网络、计算等各种计算资源。在此基础之上运行APP-Runtime,为应用运行提供统一得,丰富得服务。让简单的应用组建起高性能的架构。

应用传播阶段

应用是需要被更多的用户使用产生价值的,Rainbond提供得是应用得传播,即一处构建应用,到处生产服务。例如某软件商生产一套微服务架构服务,涉及30个独立应用。云帮将作为其与客户快速交付得桥梁,用户只需一键即可部署完整服务。

五、面向未来

我们的愿景是希望Rainbond的使用者是一个相辅相成的整体,有人创造应用,有人发挥应用的最大价值,有人为应用提供超大资源保障。这一切的连接由Rainbond承载,构建起互联互通的应用管理生态体系。

以上就是解析rainbond以应用为中心的架构设计原理的详细内容,更多关于ainbond应用架构设计的资料请关注我们其它相关文章!

(0)

相关推荐

  • Tomcat核心组件及应用架构详解

    Web 容器是什么? 让我们先来简单回顾一下 Web 技术的发展历史,可以帮助你理解 Web 容器的由来. 早期的 Web 应用主要用于浏览新闻等静态页面,HTTP 服务器(比如 Apache.Nginx)向浏览器返回静态 HTML,浏览器负责解析 HTML,将结果呈现给用户. 随着互联网的发展,我们已经不满足于仅仅浏览静态页面,还希望通过一些交互操作,来获取动态结果,因此也就需要一些扩展机制能够让 HTTP 服务器调用服务端程序. 于是 Sun 公司推出了 Servlet 技术.你可以把 Se

  • Android操作系统的架构设计分析

    之前一直在Android应用层上做工作,最近开始研究Android平台上的东东了,主要是在Android Frameworks层和系统库层进行研究.以下是我自己的理解,领悟,希望与大家一块分享. Android系统架构分为Linux内核驱动.C/C ++框架.Java框架.Java应用程序. Android应用层: Android应用程序需要Java框架支持.主要是针对手机用户的.Android应用层都是由Java代码写的,运行在虚拟机中.虚拟机在Android平台中扮演着很重要的角色.虚拟机在

  • Android应用架构思想分析

    算算日子,工作刚好三年了.这篇开始,鄙人就要向着各种以前想起来就头大的方向努力前进了.作为在Android应用层搬砖多年的民工,首篇我想谈谈自己对架构思想的一些看法.如有不妥,还请拍砖. 盖楼的故事(虚构) 有一块地,两个区域,开发商分别让两个包工头负责开发. 包工头A办事干净利落,甩开膀子就开工了.为了省钱雇了一个全能的工人,他既要去采购盖房的材料,又要用这些材料盖房子.起初底层屋子结构简单,还能应付得来,到了后面复杂的设计需求时,忙的不可开交,经常精疲力尽,阻断了盖房子的进程,使得老板很是不

  • MySQL20个高性能架构设计原则(值得收藏)

    开源数据库架构设计原则 01. 技术选型 选择成熟的平台和技术,同时是最熟悉的,能做到极致的,用好不用坏,用熟不用生.目前业界的MySQL主流分支版本有Oracle官方版本的MySQL.Percona Server.MariaDB. 02. 高可用选择 高可用解决方案探讨的本质上是低宕机时间解决方案,可以理解成高可用的反面是不可用,绝大部分情况下数据库宕机才会导致数据库不可用.随着技术发展,开源数据库方面很多高可用组件(主从复制.半同步.MGR.MHA.Galera Cluster),对应场景,

  • 解析rainbond以应用为中心的架构设计原理

    目录 前言碎语 一.云计算的发展 二.企业价值与IT 三.服务模式 四.以应用为中心的产品设计 应用的生产阶段 应用运行阶段 应用传播阶段 五.面向未来 前言碎语 今天博主安利一个国产开源的无服务器容器云平台,关注它已经有一年多了,虽然其迭代到现在很多功能还是一直处于测试验证中,但是其设计理念以应用为中心,我觉得这个是未来的趋势. 其实以docker+k8s这种架构也是一种以应用为中心的架构,rainbond底层深度集成k8s,为用户提供云原生应用全生命周期解决方案,构建应用与基础设施.应用与应

  • Android开发组件化架构设计原理到实战

    目录 为什么需要组件化 组件化和模块化 模块化架构 组件化架构 组件化带来的优势 组件化需解决的问题 资源冲突解决 AndroidManifest 独立调试 单工程方案 多工程方案 页面跳转 Arouter 实现组件间方法调用 组件化的消息通信方式选择 广播 事件总线 Application生命周期分发 为什么需要组件化 小项目是不需要组件化的.当一个项目有数十个人开发,编译项目要花费10分钟,修改一个bug就可能会影响到其他业务,小小的改动就需要进行回归测试,如果是这种项目,那么我们需要进行组

  • 一条sql详解MYSQL的架构设计详情

    目录 1 前言 2 应用层 2.1 连接线程处理 3 服务层 3.1 SQL 接口 3.2 SQL解析器 3.3 SQL优化器 3.4 执行器 3.5 查询缓存 4 存储引擎层 4.1 概述 4.2 缓冲池(buffer pool) 4.2.1 数据页.缓存页和脏页 4.2.2 元数据 4.2.3 free链表 4.2.4 flush链表 4.2.5 LRU链表 4.2.6 小结 4.3 undo log 4.4 redo log 5 总结 1 前言 对于一个服务端开发来说 MYSQL 可能是他

  • Rainbond云原生部署SpringCloud应用架构实践

    目录 示例项目详情 模块说明: 部署环境说明: 模块构建 部署 Mysql 部署 Redis 部署 pig-ui 依赖与端口梳理 最终成果 示例项目详情 本文档以Pig 快速开发框架为例,演示如何在Rainbond上部署一套完整的Spring Cloud项目. Pig Microservice Architecture V2.1.0: 基于 Spring Cloud Finchley .Spring Security OAuth2 的RBAC权限管理系统 基于数据驱动视图的理念封装 Elemen

  • 解析Tomcat架构原理到架构设计

    目录 一.学习目的 1.1.掌握 Tomcat 架构设计与原理提高内功 1.2.宏观理解一个请求如何与 Spring 联系起来 1.3.提升自己的系统设计能力 二.整体架构设计 2.1.连接器 2.2.封装变与不变 2.3.容器 2.4.请求定位 Servlet 的过程 三.Tomcat 为何打破双亲委派机制 3.1.双亲委派 3.2.Tomcat 热加载 3.3.Tomcat 的类加载器 3.4.Tomcat 类加载器层次 四.整体架构设计解析收获总结 4.1.连接器 4.2.容器 4.3.类

  • java同步器AQS架构AbstractQueuedSynchronizer原理解析下

    目录 引导语 1.释放锁 1.1.释放排它锁release 1.2.释放共享锁releaseShared 2.条件队列的重要方法 2.1.入队列等待await 2.1.1.addConditionWaiter 2.1.2.unlinkCancelledWaiters 2.2.单个唤醒signal 2.3.全部唤醒signalAll 3.总结 引导语 AQS 的内容太多,所以我们分成了两个章节,没有看过 AQS 上半章节的同学可以回首看一下哈,上半章节里面说了很多锁的基本概念,基本属性,如何获得锁

  • java同步器AQS架构AbstractQueuedSynchronizer原理解析

    目录 引导语 1.整体架构 1.1.类注释 1.2.类定义 1.3.基本属性 1.3.1.简单属性 1.3.2.同步队列属性 1.3.3.条件队列的属性 1.3.4.Node 1.3.5.共享锁和排它锁的区别 1.4.Condition 2.同步器的状态 3.获取锁 3.1.acquire排它锁 3.1.1.addWaiter 3.1.2.acquireQueued 3.2.acquireShared获取共享锁 4.总结 引导语 AbstractQueuedSynchronizer 中文翻译叫做

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

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

  • PHP架构及原理知识点详解

    记得我刚开始学习PHP的时候,许多面试官会经常问我PHP是什么,那时的标准回答是PHP是一种弱类型动态脚本编程语言,开源, 免费,是超文本预处理器的缩写. 这只是很浅的解释,PHP对我来说是一个工具,是我手里的一把锤子,虽然这把锤子时常被调侃为两边都是起钉器的锤子. 多进程模型 PHP是以多进程模型设计的,这样的好处是请求之间互不干涉,一个请求失败也不会对其他进程造成影响,作为最开始仅仅用于个人网站的一个工具集这样的设计并没有什么不妥,随着PHP的应用变大,访问量增加这种方式显然是不合适的,因为

  • MySQL 学习总结 之 初步了解 InnoDB 存储引擎的架构设计

    一.存储引擎 上节我们最后说到,SQL 的执行计划是执行器组件调用存储引擎的接口来完成的. 那我们可以理解为:MySQL 这个数据库管理系统是依靠存储引擎与存放数据的磁盘文件进行交互的. 那么 MySQL 有哪些存储引擎呢? 主要有 MyISAM.InnoDB.Memory等等.而现在互联网中,基本都是使用 InnoDB 存储引擎,所以接下来我将简单总结自己关于 InnoDB 存储引擎的学习,比较简单的介绍 InnoDB 存储引擎里面的组件. 二.缓冲池 我们现在都知道了,数据库的数据是存放在磁

随机推荐