生成式AI领域的最新成果都在这里!抢 QCon 展区门票 了解详情
写点什么

Rainbond:国内首个开源的无服务器 PaaS

  • 2017-12-11
  • 本文字数:3427 字

    阅读完需:约 11 分钟

好雨核心项目 Rainbond 近日宣布开源,这是国内首个开源的无服务器 PaaS,主要用来为云原生应用的整个交付流程提供生产级支持,包括基础设施管理、容器化改造、微服务架构转型、DevOps 支持等。

Rainbond 源代码目前托管在 Github 上,采用 GPLv3 协议。项目地址

什么是无服务器PaaS?

PaaS 在云计算典型层级中介于应用和基础设施之间,提供运算平台和解决方案堆栈,像我们经常提到的 Google App Engine、Cloud Foundry 等平台均属于 PaaS。这些早期的 PaaS 在一定程度上为开发者带来了效率的提升和成本的降低,但也存在着支持语言有限、支持场景有限、学习成本太高的问题。

不过随着近年来容器和软件定义系列技术的成熟,以上阻碍 PaaS 发展的问题有机会得到解决,PaaS 可以变得更灵活,形成支持各种语言和架构场景且简单易用的平台——无服务器 PaaS(Serverless PaaS),可以从应用角度支持各类复杂技术架构和业务交付流程,让用户专注业务开发和管理,而不需要关注底层服务器相关的复杂技术。

Rainbond 的设计思路

“无服务器”是表现,背后的设计思路则是“以应用为中心,软件定义一切”,具体来说有以下三点:

1. 以应用粒度包装底层复杂技术和基础设施

直接面对基础设施的开发和运维,不可避免地需要学习和管理很多技术,例如服务器、网络、存储、安全、负载均衡等,想要支持大用户,还必须在此之上考虑分布式架构和性能优化的问题。

但如果将基础设施通过软件定义系列技术对接管理,梳理清楚技术点之间的内在联系,用开发和运维的最佳实践,配合 Kubernetes 等技术,就可以将以上技术以应用的粒度简化包装,让最终用户通过简单的使用方式专注在业务交付之上。同时应用粒度还能继续兼容现有技术架构,不影响架构灵活性。

2. 解耦应用和基础设施

通过满足以下两点解耦应用和基础设施:

  • 对接基础设施时,不使用基础设施提供的差异化能力
  • 运行应用时,可以依赖平台的特性

平台实现解耦应用和基础设施,应用和基础设施将可以随意组合,应用无需任何改动即可迁移至其他基础设施,管理起来更方便且不被任何基础设施绑定。

3. 连接应用和基础设施

核心模式:

  • 连接应用和应用,实现分布式架构和微服务架构
  • 连接应用和基础设施,实现应用和基础设施的灵活对接
  • 连接基础设施和基础设施,实现混合云、多云和多数据中心

图:Rainbond 架构层次

Rainbond 的技术优势

从完整性上来说,Rainbond 覆盖了应用的创建组装、运行生产、发布传播三个阶段,是一个重量级的 PaaS。除了“无服务器”以外,Rainbond 还在应用构建、微服务架构、混合云多云方面具备独特的技术优势。

图:Rainbond 交付流程

应用构建

一般容器化的PaaS 平台,往往会从镜像开始应用的构建,这就意味着开发者需要花费额外的时间来把源代码打包成镜像。其次,容器镜像的构建者进行的任何修改,对于镜像使用者来说往往是不透明的,不利于团队之间的协作。另外,当容器镜像依赖的父镜像发生变化时,必须重新构建,而如果不能从源代码自动构建的话,需要手动修改容器的文件系统。这些重复性的工作其实是没有价值的。

Rainbond 在应用构建方面面向多种介质来源,设计为持续集成/持续交付(CI/CD)的插件式 Pipeline。目前支持的来源有:

  • 源码(Java、PHP、Python、Ruby、Node.js、Golang、Scala)
  • 镜像
  • Dockerfile
  • Docker-Compose

基于不同的来源,Rainbond 构建出统一的应用完整运行介质,可以运行在各处 Rainbond 平台之上。

在构建流程中,Rainbond 从 Dockerfile 或镜像文件中智能识别存储、端口等配置信息,近期还会定义 rbdfile 规范,方便开发者在源码中预先定义应用配置和运行环境配置。另外,Rainbond 针对 Jenkins 等已有 CI 系统的对接也会在近期开放。

微服务架构

上文提到的“无服务器”,侧重于应用与资源、资源与资源之间的解耦,而应用与应用之间的解耦,需要依赖微服务架构实现。如果说容器技术对于应用和资源的解耦为我们带来了可移植性和速度,那么微服务架构对于应用之间的解耦则为我们带来了敏捷性和适应性。

Rainbond 的微服务架构设计基于 ServiceMesh,初期以 sidecar 形式对应用所依赖的应用进行 4 层透明本地网络代理,屏蔽了应用的 IP 变化问题,而 Rainbond 本身并不处理通信协议,完整的微服务功能由框架完成,因此 Rainbond 可以原生部署 Spring Cloud、api gateway 等第三方微服务框架。

目前 Rainbond 正在构建应用插件体系,对 sidecar 模式进行进一步的封装,为应用通信和治理创造更大的扩展空间。其中计划在近期增加的以 envoy 为基础的 7 层网络治理插件,将用来向原生的熔断、限流、金丝雀部署等高级治理提供支持。

应用插件体系结合已有 Rainbond APP Runtime 提供的服务伸缩、服务注册和发现、自定义资源注册和发现等功能,将可以原生提供可扩展的微服务运行环境,开发者也无需再学习第三方微服务框架复杂的技术实现。

图:Rainbond 部署 Spring Cloud 微服务框架拓扑图

混合云多云

云计算发展至今,涌现出了各种类型、不同厂商的计算资源,开发者面对的已经不再是单一的物理硬件、虚拟机或公有云,因此如何管理混合云多云也是一个急需解决的问题。

面对各类型计算资源,Rainbond 屏蔽了计算资源之间的不同,提供统一的应用运行环境,让应用在无绑定的情况下快速进行多个数据中心之间的部署和迁移。具体实现如下:

  1. 在各类型计算资源上建立独立的数据中心,没有特殊的基础服务要求
  2. 将所有节点统一抽象为 rbd-node,并按功能分类(计算节点、基础管理节点、存储节点、负载均衡节点等)
  3. 自动安装节点自动化维护系统,对所有节点进行监控和管理

站在资源角度,无论公有或是私有,当我们通过以上方式连接物理机和 IaaS 便实现了混合云的管理,连接不同 IaaS 便实现了多云的管理。

Rainbond 计划在未来推出应用快照功能,对应用介质、环境配置、持久化数据进行快照备份,开发者可以通过此功能迁移运行态应用。

Rainbond 与 Heroku 的对比

做为市场上最早的一批 PaaS 平台,Heroku 过去在海外开发者中备受推崇,它建立了很多沿用至今的平台服务标准,其中就包括 Cloud Native 12 Factors,云原生应用的 12 要素。

Heroku 提倡 App-centric,使开发者可以专注于构建而不必关心基础设施建设。在这一点上,Rainbond 与 Heroku 是一致的。两者也都支持主流开发语言、常用数据服务、应用伸缩、代码上线和回滚、对接 Github,提供应用级监控和网络隔离的用户空间。

不过 Heroku 对分布式架构、混合云多云,以及在安全控制、可见性和灵活性上对于满足业务增长需求的架构略显不足。

Rainbond 与官方 Kubernetes 的对比

Kubernetes 经过三年发展,俨然已经成为了容器编排和管理的社区标准,它提出的一系列概念抽象,非常符合理想的分布式调度系统。但大量高难度技术概念,同时也形成了一条陡峭的学习曲线,直接拉高了 Kubernetes 的使用门槛,而 Rainbond 将这些技术概念包装成为“Production-Ready”的应用,开发者不需要特殊学习即可使用。

另一方面,Kubernetes 本身是一个容器编排工具,并不提供管理流程,而 Rainbond 提供现成的管理流程,包括 DevOps、自动化运维、微服务架构和应用市场等,可以开箱即用。

未来规划

对于未来,Rainbond 计划搭建应用插件扩展体系、支持跨数据中心的应用,并在未来构造互联互通的生态。

搭建应用插件扩展体系

应用往往需要一系列辅助功能来达到生产级别可用,例如 MySQL 需要定期数据备份或同步、api 应用需要实时收集应用进行分析、应用升级需要处理数据 结构和数据持久化。

Rainbond 计划搭建一套通用性强的插件支持体系,允许插件和应用集成使用。开发者可以在体系内贡献自研插件,自研插件的输入、输出、运行方式完全由插件作者制定。

支持跨数据中心应用

在部分特殊场景下,同一个应用需要分区域部署,单个数据中心的高可用是不够的。Rainbond 计划利用 CRDTs 数据模型的分布式架构,解决未来数据在大量边缘数据中心同步的问题。

目前 Rainbond 已经通过应用抽象实现了无状态应用的多数据中心部署,而对于数据库类应用,Rainbond 近期将通过对 Geo-replication database 类分布式数据库的进一步支持,实现跨数据中心型数据应用的多数据中心多活部署。

构造互联互通的生态

通过对接好雨云市,让应用在开发者之间流动起来,既可以快速使用,也可以分享或销售。

通过引入更多的数据中心合作伙伴,让公有数据中心拥有更大的覆盖范围,方便开发者自由选择部署,并根据需要在私有和公有数据中心之间迁移。开发者甚至不需要专门构建自己的数据中心,仅通过简单的控制台即可将应用部署在距离世界上任何用户最近的地方。

2017-12-11 21:365678

评论

发布
暂无评论
发现更多内容

在Vue中使用JSX,很easy的

华为云开发者联盟

JavaScript Vue Vue3 JSX 渲染函数

DataOps(数据运维)指南 - 数据管理的新时代

码语者

DataOps

百亿级系统架构首公开!阿里这份300多页的设计实录你还没有吗?

Java 程序员 架构 面试 后端

Elasticsearch 分片速度、进度及故障排查(qbit)

qbit

elasticsearch shard

WhatsApp 如何启用端到端加密备份数据

CatTalk

facebook 安全 端到端加密

分布式缓存技术

黄敏

211本+985硕+计算机专业投面百度,坐等一周迎来三面,已拿offer

Java 学习 程序员 架构 大厂面试

量化模拟线上流量实践

FunTester

性能测试 接口测试 测试框架 FunTester 线上流量

太绝了吧! 终于有人能把TCP/IP 协议讲的明明白白了

程序员 架构 面试 后端 java

涨薪60%,从美团干到阿里p7,这份Github上的面试笔记把所有Java知识都写出来了

Java 程序员 架构 面试 后端

Python 的 sum():Pythonic 的求和方法

华为云开发者联盟

Python 列表 元组 Pythonic 求和

Python代码阅读(第37篇):获取两个列表中相同的元素

Felix

Python 编程 Code Programing 阅读代码

详解物联网Modbus通讯协议

华为云开发者联盟

物联网 通信 Modbus 通讯协议 TCP通信

遭 GitHub 连夜封杀下架?被泄露的阿里内部 Java 面试手册到底有多强?

收到请回复

Java 面试 阿里 大厂Offer

Apache ShardingSphere 在京东白条场景的落地之旅

SphereEx

开源 数据架构 架构设计 ShardingSphere SphereEx

第 17 章 -《Linux 一学就会》- Linux计划任务与日志的管理

学神来啦

Linux 运维 linux学习 linux云计算 linux基础

云栖大会|盛宴之下,共赴一场视频云的进化论

阿里云视频云

阿里云 音视频 WebRTC 视频云 云栖大会

安全稳定便捷! 融云赋能“轻云会议”满足政府在线会议需求

融云 RongCloud

云计算 音视频 通信 会议 视频云

解读鸿蒙轻内核的监控器:异常钩子函数

华为云开发者联盟

鸿蒙 钩子函数 任务栈 OpenHarmony 异常钩子函数

Elasticsearch 快照相关(qbit)

qbit

Alibaba最新神作!耗时182天肝出来的1015页分布式全栈手册太香了

编程 程序员 IT 计算机 java

写给初学者,一文搞懂大数据学习、岗位、面试及简历

五分钟学大数据

大数据

元宇宙NFT区块链游戏系统开发

面试官提问:如何通过sql方式将数据库表行转列?

Java 数据库 sql 面试 后端

19. 删除链表的倒数第N个数(链表)

黄敏

J2PaaS低代码平台的开源,将进一步助力企业数字化

J2PaaS低代码平台

低代码 低代码开发 低代码开发平台

2021Flexera云报告:企业积极拥抱多云,但云上成本仍然居高不下

行云管家

区块链 云计算 企业上云 上云

构建数字合作格局 赋能政企行业通信——首届WECC 2021即将召开

融云 RongCloud

音视频 IT, 通信 通信云 会议

Android技术分享| 【自习室】自定义View代替通知动画(1)

anyRTC开发者

android 音视频 WebRTC 在线教育 移动开发

主数据与主数据管理(数据治理)

KoLee

数据治理 数字化 主数据管理 主数据

三面阿里,有惊无险成功拿到offer定级P7,只能说是真的难

Java 编程 java架构

Rainbond:国内首个开源的无服务器PaaS_服务革新_刘凡_InfoQ精选文章