Rainbond 源代码目前托管在 Github 上，采用 GPLv3 协议。项目地址。 什么是无服务器PaaS？不过随着近年来容器和软件定义系列技术的成熟，以上阻碍 PaaS 发展的问题有机会得到解决，PaaS 可以变得更灵活，形成支持各种语言和架构场景且简单易用的平台——无服务器 PaaS（Serverless PaaS），可以从应用角度支持各类复杂技术架构和业务交付流程，让用户专注业务开发和管理，而不需要关注底层服务器相关的复杂技术。 Rainbond 的设计思路1. 以应用粒度包装底层复杂技术和基础设施 但如果将基础设施通过软件定义系列技术对接管理，梳理清楚技术点之间的内在联系，用开发和运维的最佳实践，配合 Kubernetes 等技术，就可以将以上技术以应用的粒度简化包装，让最终用户通过简单的使用方式专注在业务交付之上。同时应用粒度还能继续兼容现有技术架构，不影响架构灵活性。 通过满足以下两点解耦应用和基础设施： - 对接基础设施时，不使用基础设施提供的差异化能力
- 运行应用时，可以依赖平台的特性
3. 连接应用和基础设施 从完整性上来说，Rainbond 覆盖了应用的创建组装、运行生产、发布传播三个阶段，是一个重量级的 PaaS。除了“无服务器”以外，Rainbond 还在应用构建、微服务架构、混合云多云方面具备独特的技术优势。 图：Rainbond 交付流程 一般容器化的PaaS 平台，往往会从镜像开始应用的构建，这就意味着开发者需要花费额外的时间来把源代码打包成镜像。其次，容器镜像的构建者进行的任何修改，对于镜像使用者来说往往是不透明的，不利于团队之间的协作。另外，当容器镜像依赖的父镜像发生变化时，必须重新构建，而如果不能从源代码自动构建的话，需要手动修改容器的文件系统。这些重复性的工作其实是没有价值的。 基于不同的来源，Rainbond 构建出统一的应用完整运行介质，可以运行在各处 Rainbond 平台之上。 微服务架构 Rainbond 的微服务架构设计基于 ServiceMesh，初期以 sidecar 形式对应用所依赖的应用进行 4 层透明本地网络代理，屏蔽了应用的 IP 变化问题，而 Rainbond 本身并不处理通信协议，完整的微服务功能由框架完成，因此 Rainbond 可以原生部署 Spring Cloud、api gateway 等第三方微服务框架。 应用插件体系结合已有 Rainbond APP Runtime 提供的服务伸缩、服务注册和发现、自定义资源注册和发现等功能，将可以原生提供可扩展的微服务运行环境，开发者也无需再学习第三方微服务框架复杂的技术实现。 图：Rainbond 部署 Spring Cloud 微服务框架拓扑图 云计算发展至今，涌现出了各种类型、不同厂商的计算资源，开发者面对的已经不再是单一的物理硬件、虚拟机或公有云，因此如何管理混合云多云也是一个急需解决的问题。 站在资源角度，无论公有或是私有，当我们通过以上方式连接物理机和 IaaS 便实现了混合云的管理，连接不同 IaaS 便实现了多云的管理。 做为市场上最早的一批 PaaS 平台，Heroku 过去在海外开发者中备受推崇，它建立了很多沿用至今的平台服务标准，其中就包括 Cloud Native 12 Factors，云原生应用的 12 要素。 不过 Heroku 对分布式架构、混合云多云，以及在安全控制、可见性和灵活性上对于满足业务增长需求的架构略显不足。 Rainbond 与官方 Kubernetes 的对比另一方面，Kubernetes 本身是一个容器编排工具，并不提供管理流程，而 Rainbond 提供现成的管理流程，包括 DevOps、自动化运维、微服务架构和应用市场等，可以开箱即用。 未来规划搭建应用插件扩展体系 Rainbond 计划搭建一套通用性强的插件支持体系，允许插件和应用集成使用。开发者可以在体系内贡献自研插件，自研插件的输入、输出、运行方式完全由插件作者制定。 在部分特殊场景下，同一个应用需要分区域部署，单个数据中心的高可用是不够的。Rainbond 计划利用 CRDTs 数据模型的分布式架构，解决未来数据在大量边缘数据中心同步的问题。 构造互联互通的生态 通过引入更多的数据中心合作伙伴，让公有数据中心拥有更大的覆盖范围，方便开发者自由选择部署，并根据需要在私有和公有数据中心之间迁移。开发者甚至不需要专门构建自己的数据中心，仅通过简单的控制台即可将应用部署在距离世界上任何用户最近的地方。
| 
