开源PaaS Rainbond的架构与实现

回顾云计算产业技术的发展，IaaS层虚拟化的逐步成熟，解决了过去使用物理计算集群所面对的资源提供者和使用者之间的耦合问题，一定程度上降低了交付应用和创造业务价值的门槛，但在开发和运维的技术难度方面表现一般。

随后，以Docker、Kubernetes为代表的容器技术日益盛行，对应用的虚拟化为创造和交付大规模业务系统铺平了道路。然而单纯的容器管理还不足以实现我们对于企业IT的愿景——只需关注业务，无需在底层技术和基础设施上花费大量时间和精力。

因此我们提出了“应用管理“的概念，围绕以应用为中心，呈现为无服务器PaaS和云原生SaaS两个产品服务。

应用管理的价值

对于大多数企业IT来说，业务价值来源于创造应用和使用应用两个场景。传统的业务系统运行方式，要求企业IT搭建运行环境，考虑网络、存储、配置、负载均衡、安全等一些列基础设置管理问题……这些工作在每一次系统搭建时重复进行，占据了大量的企业IT成本。

通过在应用与计算资源之间增加应用管理层（无服务器PaaS/云原生SaaS）实现解耦，开发者和使用者仅关注业务逻辑设计、编码、测试、上线等业务直接相关工作，源代码与云端运行之间的复杂工作交给应用管理层自动化完成。

换个角度来说，开发者和使用者将无需面对底层计算资源的管理复杂性，解除了开发对于运维的依赖，而运维人员仅需在平台自动化资源管理的基础上维护资源池稳定即可。当开发与运维之间责任清晰、边界明确，DevOps工作流也随之得到天然的落地。

应用管理的服务模式

应用管理是Rainbond的核心设计思路，包括北向的应用抽象管理和南向的计算资源管理。

两层应用抽象模型适用绝大多数企业IT系统和基础应用，包括互联网应用、行业应用、物理网应用和大数据技术应用等等。

在此基础之上对于微服务架构的支持，包括开箱即用的Service Mesh、插件式治理功能扩展、兼容spring cloud、api gateway、dubbo等主流微服务架构，可实现多类型单体应用、新老应用的规模化整合，并配套标准、完整的功能特性。

当然，不同应用可能会有不同的高级需求，如Mysql热备份、外网访问应用需求防火墙等。Rainbond相应设计了应用插件体系，对应用功能进行差异化、无侵入式的拓展。

在计算资源管理方面，Rainbond对不同的计算资源进行统一池化，通过软件定义基础设置提供标准的计算服务，公有云计算资源、IDC厂商、企业私有x86-64架构计算资源均作为Rainbond数据中心接入。

总结里说，Rainbond的服务模式可以描述为，用户将任何应用运行于任何计算资源之上，按需灵活组合，并以SaaS化服务的形式提供给终端用户。

以应用为中心的产品设计

Rainbond以应用为中