查看Rainbond的使用场景与技术架构视频

本文我们讲解Rainbond的设计理念,设计来源于问题,并解决问题。

最早期的程序员是痛苦的,为什么呢?做过嵌入式开发的人很清楚,为了完成一个简单的功能,不得不重复得处理各类型硬件设备。导致软件没法快速得复制。因此计算机操作系统诞生了,将各类型硬件架构进行抽象,提供统一的操作接口,这个时候软件可以复制传播到处安装了。伴随着IT产业的快速发展,单一计算已经无法满足社会的需求,“云计算”变成了行业最关注的技术。“云计算”是什么?定义太多了,不属于今天我们讨论的范畴。我们对其进行一个基础的定义,将众多单一物理计算资源统一融合形成构建在网络上的计算资源池,统一完成业务计算任务,我们称为云计算。理想是美好的,我们希望我们的传统服务借助云计算的能力发挥极大的最终价值。这个时候,问题来了,应用的创造者只希望关心其业务的逻辑,然而复杂的计算资源,应用运行环境给大多数应用生产者带来难题。这个时候我们希望出现一种更高级的“云计算操作系统”,帮助应用解决一系列的部署配置,运行生产,标准化传播等等问题。基于此考虑,Rainbond应运而生。

我们提出“以应用为中心,软件定义一切”的理念,将Rainbond打造成为无服务器PaaS平台,基于Rainbond构建应用与应用互联,应用与基础设施解耦,基础设施与基础设施互联的完整应用管理生态体系。

Rainbond设计成能够运行各类复杂的应用架构(传统的SOA架构,盛行的微服务架构等),用户只需要关注应用本身的业务逻辑,系统完成所有的计算资源抽象,运行环境配置,应用服务治理,应用自动化生产和传播等等与应用业务不直接相关但缺一不可工作。我们在初期技术选型时注意到了Kubernetes容器管理方案,我们认为其对软件的抽象跟我们设想是一致得,因此我们从一开始就引入的Kubernetes技术作为我们应用的运行时。此外Rainbond从租户网络,应用存储,负载均衡,应用关系,应用扩展等多方面完善软件定义形成一套APP-Runtime。插件化的设计体系让云帮可以吸收各类优秀的技术。例如应用Ingress负载均衡,我们将负载均衡设计成应用级可选,即不同的应用可使用不同特性的负载均衡插件。类似设计我们在架构一文中详细解读。

近年“以应用为中心”的理念被业界广为接受和应用,越来越多厂商产品在实践此理念。Rainbond显然是走在实践前沿的。

  • 在应用的生产阶段,Rainbond从设计上就支持从各类型软件源构建生产应用,从各类型编程语言源码,已经打包的容器镜像,更包括定义好的DockerCompose文件等等。Rainbond定义应用的各层面元素,就像一个生产线,输入各种代码,生产出统一的应用。
  • 在应用运行阶段,Rainbond定义管理了各种计算资源,物理机,虚拟机,各类云。在此基础之上运行APP-Runtime,为应用运行提供统一得,丰富得服务。让简单的应用组建起高性能的架构。
  • 在应用传播阶段,应用是需要被更多的用户使用产生价值的,Rainbond提供得是应用得传播,即一处构建应用,到处生产服务。例如某软件商生产一套微服务架构服务,涉及30个独立应用。云帮将作为其与客户快速交付得桥梁,用户只需一键即可部署完整服务。

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