无服务器(ServerLess)PaaS—Rainbond宣布开源

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

Rainbond是好雨开源的生产级无服务器PaaS，该项目基于Kubernetes、CI/CD、多数据中心管理等技术，为云原生应用的创建组装、运行生产、发布传播提供全生命周期解决方案，并构建应用与基础设施、应用之间及基础设施之间的互联互通生态体系。

在设计层面，Rainbond遵循“以应用为中心，软件定义一切”，它通过软件定义系列对计算资源、运行环境、运维管理、复杂技术进行了应用化包装，使资源、架构、应用充分解耦，对外呈现简单的使用体验，包括构建、配置以及监控、日志、依赖、存储、端口等所有信息和操作均围绕应用层面展开，应用可以一处构建、到处运行。

源代码构建

有别于一般容器云平台，Rainbond不仅可以从镜像或以docker-compose方式构建应用，还支持Java、PHP、Python、Ruby、Node.js、Golang、Scala等主流语言的源代码构建。换句话说，用户不需要理解Docker，也不需要编写Dockerfile，Rainbond将自动识别语言，并将源代码自动构建成应用。与此同时，Rainbond还提供了对于Jenkins等第三方CI/CD的对接支持。

在Rainbond上构建的应用，可搭配Mysql、Redis、Zookeeper等各类数据存储应用，构成一个完整的服务，并可发布到私有应用市场供企业内部共享，或分享到好雨云市进行商业销售。

微服务架构落地

微服务架构是Rainbond的核心功能之一，在它之上部署的任何应用，本身即是微服务，可按照微服务的方式进行操作。借助好雨微服务架构强大的插件体系，Rainbond无侵入原生提供服务治理、服务注册与发现、服务升级、服务监控、服务伸缩等功能，同时支持各类第三方微服务框架。

同样由好雨开源的最佳实践项目云框架中的Spring Cloud、api gateway等微服务架构主题，均可完美运行于Rainbond之上，开发者仅需替换实例中业务代码即可变成自己的微服务架构项目，并通过docker-compose的方式一键部署。

混合云多云管理

混合云多云管理是Rainbond的另一项优势功能。在云计算飞速发展的今天，众多厂商提供了丰富的各类型公有云资源，Rainbond通过对应用与资源的解耦，将各类资源（私有云服务器、公有云服务器、网络资源）统一整合成Rainbond数据中心，对各类资源进行自动管理，实现跨区域互联与租户化隔离，用户无需关注服务器即可将应用部署于混合云多云环境。

除了上文提到的特点，云帮还具备以下特性：

CI/CD

• 支持Java、PHP、Python、Ruby、Node.js、Golang等语言直接构建
• 支持docker镜像和Dockerfile构建应用
• 支持Docker Compose快速部署
• 可对接私有和公有Git仓库
• 支持云框架一键部署
• 遵循云原生应用12要素原则
• 支持应用一键升级/回滚，当前业务不间断
• 根据用户使用场景可以灵活定制开发和发布流程

高效运维

• 支持停止、启动、删除等应用控制
• 提供应用操作日志
• 支持应用日志实时输出、查看和打包下载
• 应用原生支持负载均衡
• 提供单点和多节点服务高可用机制
• 应用支持端口／域名／环境变量／对内对外服务的高级管理选项
• 支持应用手动伸缩（垂直、水平）
• 支持应用特性增强
• 提供实时的业务级监控
• 支持实时HTTP／MySQL协议性能分析

应用市场

• 支持发布应用到应用市场
• 支持发布一组分布式应用到应用市场
• 支持企业内部私有应用市场，IT部门和其他部门高效衔接
• 好雨应用市场提供大量开源和商业应用
• 支持从应用市场一键安装
• 支持对已发布应用进行管理

微服务架构

• 支持跨开发语言和跨协议的微服务架构
• 原生支持Service Mash
• 支持服务自动发现和服务动态编排
• 支持依赖关系与环境变量管理
• 支持微服务架构发布到应用市场并支持一键安装
• 支持非微服务按微服务管理和对接微服务架构
• 通过整体服务拓扑图快速监控和管理微服务架构
• 支持Spring Cloud、Dubbo、api gateway等主流微服务架构

其他

• 支持平台全功能的API接口
• 提供的团队权限管理
• 提供基于全路由的网络组建
• 提供基于Overlay的网络组建
• 支持NAS存储方式，如NFS／GlusterFS
• 支持多数据中心管理
• 支持多租户

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

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

目前，Rainbond源代码已托管在Github上，采用GPLv3许可证。Github：https://github.com/goodrain/rainbond  文档：https://www.rainbond.com/docs/

什么是无服务器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类分布式数据库的进一步支持，实现跨数据中心型数据应用的多数据中心多活部署。

构造互联互通的生态

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

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