【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

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:365660

评论

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

Ascend C保姆级教程:我的第一份Ascend C代码

华为云开发者联盟

人工智能 华为云 昇腾 华为云开发者联盟 企业号 8 月 PK 榜

KaiwuDB 助力能源企业实现 4 大价值提升

KaiwuDB

KaiwuDB 分布式储能

跑AI大模型的K8s与普通K8s有什么不同?

华为云开发者联盟

人工智能 云计算 华为云 华为云开发者联盟 企业号 8 月 PK 榜

一文带你了解跨境数据传输和隐私

镭速

跨境数据传输

软件测试 | 人工智能:优势与挑战

测吧(北京)科技有限公司

测试

浅析Java - SPI机制 | 京东云技术团队

京东科技开发者

Java 后端 spi 企业号 8 月 PK 榜

人工智能改善生活:不同受众的定制化应用

测吧(北京)科技有限公司

一座玉带桥,盘古通天下

脑极体

AI

聊聊Http服务化改造实践

树上有只程序猿

微服务架构 HTTP Feign

PoseiSwap 开启“Poseidon”池,治理体系或将全面开启

威廉META

快乐开源活动全面升级!提PR,赢PS5、Switch等缤纷好礼

飞桨PaddlePaddle

人工智能 百度飞桨

高效构建实时数仓:探秘NineData数据复制技术

NineData

数据库 大数据 实时数仓 数据复制 迁移指南

Elasticsearch ILM Shrink Action源码优化与探讨

腾讯云大数据

ES

深度解读智能媒体服务的重组和进化

阿里云视频云

云计算 视频云

点对点传输技术可实现更大的文件传输

镭速

大文件传输 点对点传输

Spring高手之路13——BeanFactoryPostProcessor与BeanDefinitionRegistryPostProcessor解析

砖业洋__

spring springboot BeanFactoryPostProcessor BeanDefinitionRegistry

Kubernetes实现微服务容器化

雾岛听风(锋)

微服务 k8s 容器化

2024光储充展|太原国际光储充技术装备展会

秋硕展览

展会 光伏展 储能展

Java单元测试及常用语句 | 京东物流技术团队

京东科技开发者

Mockito 测试 单元测试 企业号 8 月 PK 榜 Java单元测试

【稳定性】揭秘团队快速排查问题的三字经,你学会了吗? | 京东物流技术团队

京东科技开发者

团队 线上故障 故障排查 企业号 8 月 PK 榜

云密一体,京东云密码资源池实力守护安全防线

京东科技开发者

云原生 网络安全 密码安全 企业号 8 月 PK 榜

盘点那些国际知名黑客(上篇)

禅道项目管理

软件测试/测试开发丨Python 内置库 正则表达式

测试人

Python 正则表达式 程序员 软件测试 自动化测试

Xmind for Mac(思维导图软件) 23.08中文激活版

mac

XMind 思维导图软件 苹果mac Windows软件

深入MaxCompute -第十二弹 -PIVOT/UNPIVOT

阿里云大数据AI技术

大数据

华为云828营销季火热进行中,3大热门产品助力中小企业云上成长

平平无奇爱好科技

揭秘ChatGPT,如何打造自己的自定义指令 | 京东云技术团队

京东科技开发者

自定义指令 大语言模型 chatgpt app 企业号 8 月 PK 榜

开源图形驱动在OpenHarmony上的使用和落地

OpenHarmony开发者

OpenHarmony

关于我为什么要用微前端这件事

这我可不懂

架构 前端开发 微前端

机场数据安全三步走战略|盾见

极盾科技

数据安全

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