设计思想

为什么选择Rainbond？

1.使用简单

Rainbond 遵循 以应用为中心 的设计理念，统一封装容器、Kubernetes和底层基础设施相关技术，让使用者专注于业务本身, 避免在业务以外技术上花费大量学习和管理精力。同时，Rainbond 深度整合应用开发、微服务架构、应用交付、应用运维、资源管理，管理高度自动化，实现统一管理所有应用、所有基础设施和所有IT流程。

2.一步将传统应用变成云原生应用

Rainbond 通过“无侵入”技术，让传统应用不需要改动或少量改动就能快速变成云原生应用。 传统应用转成成云原生应用的方式：

• 有源代码和软件包的应用，平台自动识别开发语言类型和包类型，不改变开发者习惯，代码直接编译、构建成支持云原生特性的应用。
• 对于想实现微服务架构的传统应用，Rainbond提供Service Mesh 微服务架构，应用不改代码就能变成微服务架构。
• 传统应用想要扩展运维和治理功能，Rainbond提供“无侵入”的插件，按需加载插件，开启运维和服务治理能力。

3.实现数字化能力积累和复用

Rainbond能将企业内部各种数字化能力一键发布成组件，并具备组件安装使用、组件编排、组件版本管理、组件升级和持续迭代等完整的管理流程，将企业内部可复用的能力积累到组件库，既避免重复建设，还能将这些组件变成数字资产，为企业创新提供动力。

4.解决2B行业的交付问题，实现各种交付流程自动化

Rainbond提供企业应用的业务集成、多云交付、私有交付、SaaS交付、离线交付、个性化交付、应用市场等能力，将交付过程最大限度自动化，提高企业应用交付效率，降低交付成本。

与其他产品差异

对比维度	Rainbond	Rancher	KubeSphere
核心定位	应用级 PaaS，强调应用抽象与交付，尽量隐藏 Kubernetes 细节	Kubernetes 管理平台，强调多集群治理与运维	Kubernetes 之上的扩展平台，强调更完整的平台能力建设
面向用户	开发者、应用运维、企业 IT 团队，尤其适合不熟悉 K8s 的团队	K8s 管理员、平台运维团队	K8s 管理员、DevOps 工程师、有 K8s 经验的开发者
核心价值	低门槛应用交付、应用模板复用、升级回滚、多云应用管理	多集群统一管理、安全与基础设施运维、生态整合	DevOps、服务网格、可观测等能力的一体化整合
学习曲线	低，聚焦应用本身	中，需要理解集群管理	中高，需要理解 K8s 及相关生态
更适合的场景	快速交付业务应用、企业内部应用平台、传统应用云原生改造	管理多个异构 K8s 集群、建设统一基础设施平台	围绕 K8s 建设更完整的平台能力

如果你已经进入平台选型阶段，建议继续阅读 选型中心、Rainbond vs Rancher 和 Rainbond vs KubeSphere。这里仅保留核心差异速览，详细对比统一维护在独立对比页中。

Rainbond的功能及架构

应用级多云管理

应用级强调以“应用”为中心，跟应用相关技术概念对外暴露，跟应用不直接相关的技术概念统一包装，底层的基础设施通过软件定义系列技术（SDN、SDS、SD-WAN、docker、LB）包装，把底层重复性工作实行实行自动化，并在应用抽象之上支撑应用的开发、架构、交付和运维，这种抽象粒度，即能简化应用的管理，又能满足业务的灵活性。

多云管理的核心是将应用和计算资源解耦，根据场景任意组合，可以实现混合云、边缘云、应用级多云，应用的生命周期管理跟计算资源不直接相关，也就是说应用的开发可以在任何类型的计算资源上，开发好的应用可以直接安装运行在任何类型的计算资源上，还可以随时从一种云迁移到另一种云，应用不用做任何改动。

应用全生命周期管理

应用全生命周期管理包括应用开发、微服务架构、应用交付和应用运维。

• 开发阶段，Rainbond提供开箱即用的开发测试环境，对接各类源代码仓库，自动识别开发语言并编译构建和打包，通过应用市场安装各种开发工具。
• 架构阶段，支持各种常见微服务架构，业务服务可以模块化编排，通过服务拓扑可视化了解业务的结构和依赖关系，通过插件扩展各种服务治理能力。
• 交付阶段，支持应用持续交付流程，开发的应用以应用模版的形式存放到应用市场，通过应用市场对应用展示和分类，对于联网的用户，远程连接应用市场，一键安装和升级。对于离线用户，从应用市场导出离线应用包，到用户环境导入离线应用包，一键安装和运行。
• 运维阶段，把所有应用运维工作通过web界面呈现，除了基本的应用管理（启动、关闭、重启、删除）操作外，主要的运维过程都是自动化的，提供可观测性深入了解自动化的执行过程。面对大数据和大用户的应用场景，支持业务快速伸缩，及时响应业务的变化。

能力复用和共享

组件是独立运行、可复用、可扩展、可集成的单元，支持不同的粒度大小，支持版本管理，组件可以在不同应用场景中复用，组件自身可以迭代升级，积累的组件统一存放到组件库，当有应用需要使用组件时，只需通过“拖拉拽”的方式快速拼装，当积累的组件越多，交付应用的速度也越快。

Rainbond怎么工作？

Rainbond主要有两部分组成，一个是提供Web界面的Rainbond控制台，另一个是安装在K8s集群内部的Rainbond集群管理端。

Rainbond控制台提供控制面的监控和管理，主要服务开发人员和管理人员，控制台通过Rainbond集群管理端提供的API来管理K8s集群和运行在K8s集群上的应用，并把元数据存储在本地，控制台关闭不影响K8s集群和业务服务的运行。一个控制台能监控和管理多个K8s集群。

Rainbond集群管理端通过控制台或Helm方式安装到一个或多个K8s集群内，由它对接标准K8s API，控制台的监控和管理指令通过调用K8s API实现，通过控制台部署的应用，也可以使用K8s的命令查看和管理。

云原生的本质和最终效果

云计算本质上解决的是资源的自动化管理问题，但数字化和信息化的关键在应用，云计算没有解决应用的管理问题，应用的管理和运维是难题，对人依赖度很高，云原生的出现就是为了解决应用的管理问题。

应用管理比资源管理复杂很多，涉及到应用开发、应用架构、应用交付和应用运维等应用层的管理，还要配合应用解决资源自动化管理问题，云原生本质就是解决应用的自动化管理问题。

从效果来看，云原生的最终目标是让开发者聚焦自己的业务，业务之外（基础设施、应用架构、应用运维）的事情不用关心，只需要懂业务就能创造出自己想要的应用，并能按需交付客户。

应用抽象模型是云原生可落地的关键（实现思路）

云原生落地的难点在使用，如果能将云原生底层复杂的技术包装成开发者熟悉的应用层属性和动作，开发者就不用学习新的概念和技术；如果能将业务跟运维能力解耦，跟微服务框架解耦，就能实现开发者按需扩展运维能力和切换微服务框架，实现对业务按需赋能；如果能实现根据不同客户类型，自定义交付流程和自动化交付，就能大大降低交付成本，提升客户满意度。

当以上三点都能解决，就可以让开发者聚焦在业务本身，业务之外的事情不用关心，有更多精力关注客户价值输出。

基于以上思考，通过应用抽象模型是个解决思路，对应用整体进行包装和抽象，包含应用运行所需的全部运行定义，与底层技术和概念隔离。向上用户不需要再学习和了解系统级概念和技术，应用内部把业务和扩展能力解耦，使用应用级概念开发和管理，需要扩展服务治理、运维、安全等能力时按需开启插件。向下则包装Kubernetes的概念和抽象，屏蔽掉底层基础设施的差异，实现应用抽象模型可以运行在各类基础设施上。

应用抽象模版核心设计在三方面：

1. 应用级抽象

2. 架构充分解耦

3. 使用应用模版交付

应用级抽象能简化理解和使用

应用级抽象是“以应用为核心”的抽象模型，对用户暴露应用级的概念、属性和动作，底层Kubernetes和系统级的概念和技术，要么完全实现自动化，要么包装成应用级的属性和动作。

为了实现灵活的应用编排和自动化调度，Kubernetes定义了很多概念，提供丰富的扩展机制，并以YAML的方式跟它交互，Kubernetes的这些可编程的体验，对管理和扩展Kubernetes的人来说，是非常好的特性，但对于普通开发者，门槛太高，并且很多概念和技术跟自己开发的业务并没有直接关系，所以对于普通开发者来说需要更加友好的操作体验，不需要学习就能使用。

应用级抽象和Kubernetes概念粗粒度的对应关系：

应用级属性	Kubernetes概念
应用运行环境	Containers
应用运行属性	Workload
应用网络属性	SDN
应用存储属性	SDS
应用对外服务属性	Ingress
应用对内服务属性	Service
应用插件	Pod
应用配置	ConfigMap

应用级抽象并不是要将Kubernetes概念全部隐藏起来，而是对于不同的使用者，职责不同展现不同的交互界面。对普通开发者职责是开发业务，只需要关心应用级的概念，提供应用级的操作界面。

但对于云原生平台的管理人员，除了关心应用级的概念，还要关心Kubernetes的管理和维护，有能力的话还可以扩展平台的能力，所以对于平台管理人员，提供高级的暴露Kubernetes概念的操作界面，或者直接操作Kubernetes也可以管理平台上的应用，通过这种方式也规避了，由于包装概念产生的“黑箱”导致对平台的可观测性和可掌控性不足。

架构充分解耦，根据使用场景按需组合

基于应用级的抽象，应用模型通过标准的Kubernetes API实现跟基础设施的解耦，所有符合标准Kubernetes API 的基础设施都可以实现对接和部署，比如各公有云厂商的Kubernetes实现、K3s、KubeEdge等，通过这样的解耦，开发者只需要关心业务和能力扩展，不用在关心基础设施的差异，对接应用模型的应用不需要改动就能透明部署到公有云、私有云和边缘设备上，实现了应用级多云。

通常在应用里，还会包括一些跟业务无关的功能，他们的作用是为了让应用更好的运行。比如：服务治理、微服务框架、运维工具、安全工具等，这些能力跟应用有强耦合关系的，需要改代码扩展能力，将这部分能力解耦，应用就只需要关注在业务了，而且扩展的能力有很强的复用性，其他应用也需要。

应用中扩展能力的解耦使用Kubernetes的Pod，Pod中包含一个或多个容器，所有容器共享网络、存储，应用运行在一个容器，扩展的能力通过扩展容器的方式运行，通过共享的网络和存储实现了应用和扩展能力的解耦，这种解耦方式对业务完全无侵入，扩展的能力用插件的形式包装，就可以实现应用按需安装和启动插件，根据网络流向和容器启动顺序可以定义几种类型插件：

插件类型	说明
入口网络插件	网络流量先到入口网络插件，然后到业务容器。例如：网关、WAF、安全工具、限流
出口网络插件	网络流量先到业务容器，然后到插件容器。例如：负载均衡、断路器、加密访问
出入网络插件	网络流量先到插件容器，再到业务容器，再回到插件容器。例如：Service Mesh proxy
旁路插件	网络上旁路运行。例如：性能分析、监控、调用链分析、日志管理
初始化插件	Pod的Init容器，Pod启动先启动Init容器。例如：数据库初始化

按照Pod机制实现的插件只能扩展单个业务容器的能力，而要对应用扩展微服务架构能力，需要对每一个业务容器扩展服务治理的插件，这跟Service Mesh的实现机制一致。

Service Mesh的Data Plane需要对每个业务容器注入Proxy，对于完整应用就是扩展Service Mesh能力，对完整应用扩展的能力是应用级插件，根据注入Proxy的差异可以支持多种类型的Service Mesh实现，比如：Istio、Linkerd、Dapr，应用可以按需开启Service Mesh能力，或更换实现框架。当应用跟微服务架构解耦，每一个业务容器不再受微服务框架和开发语言限制，每个业务容器只需要专注业务本身，业务容器之间也同步实现了解耦。

通过将架构充分的解耦，解耦后的业务、插件、对接多云的能力都能实现随意组合，开发者选择喜欢的开发语言开发业务组件，根据业务契约编排依赖关系，根据服务治理和运行稳定性要求，按需开启Service Mesh插件和其他运维插件，运行的基础设施环境，也根据实际需要自动对接。

应用模版成为能力复用和应用交付的载体

应用模型以应用模版的形式具象化展现和存储，应用由源码、容器镜像和插件拼装而成，然后一键导出成应用模版，应用模版设计主要围绕使用者，让使用者能用起来，让应用交付并产出价值，从而拉动应用的迭代和开发。

从使用体验上，应用模版可以一键安装和一键升级，通过“拖拉拽”的方式实现业务拼装。应用模版有很强灵活性，应用模版支持不同颗粒度大小，模版和模版能拼装出新的模版，新的模版还可以持续拼装，颗粒的大小由使用者决定，由使用者赋予它意义。应用模版可以交付到兼容Kubernetes API的分支版本，实现一键安装和升级，或将应用模版存放到应用市场，实现即点即用的效果。

应用模版需要具备四个特点：

1. 模块化，可以形成可复用的能力单元，按需拼装使用场景。

2. 自治，自给自足，可以独立安装、升级和管理，确保组合的灵活性。

3. 可编排，模版和模版可以拼装出新模版，具备无限拼装能力。

4. 可发现，通过内部服务和外部服务两种方式体现，可供业务和技术、开发者和其他应用访问。

通过应用模版实现可复用模块和能力的打包。应用的架构充分解耦后，业务组件和扩展插件理论上可以复制到其他应用中，但直接复制代码或镜像非常低效，而且还有很多运行环境相关的配置需要考虑，将业务组件和扩展插件打包成应用模版，并将应用模版发布到应用市场供其他人使用，可以最大程度实现模块和能力的复用，减少重复造轮子。

通过应用模版实现SaaS、私有化和离线环境的自动化交付，和个性化场景模块拼装。应用模板中包含应用运行态所需的全部资源，对接到客户运行环境，就可以实现一键安装和运行，屏蔽了客户环境差异，一套产品模版可以交付所有类型客户，对于离线环境，应用模版以文件的形式导出，到客户离线环境再导入运行即可。

对于功能需要个性化的场景，利用应用模版对业务模版打包的能力，先拼装已经模块化的能力，然后再定制化开发，新开发的功能，如果可复用还可以继续发布成应用模版，供后续复用。

Rainbond 上实现云原生的体验

基于以上的设计思路，让开发者专注于业务本身，回到用户效果和价值体现的原点上，不用关心底层复杂的技术和不相关的概念，全面实现应用自动化。Rainbond提供了开箱即用的体验，使用简单，不需要懂容器和Kubernetes，支持管理多种Kubernetes集群，提供企业级应用的全生命周期管理。主要功能包括应用开发环境、应用市场、微服务架构、应用交付、应用运维、应用级多云管理等。

开发应用的体验：

1. 代码无需改动，就能变成云原生应用。对于新业务或已有业务，代码不需要改动就能将其容器化。不需要懂Docker 、Kubernetes等技术，就能将应用部署起来，具备云原生应用的全部特性。

2. 业务积木式拼装编排。可复用的业务模块积累到应用市场，当有新业务需要开发，基于应用市场已经业务模块，通过“拖拉拽”的方式拼装，然后再开发没有的业务能力，当积累的业务模块越多，开发新业务的速度越快。

3. 开箱即用的Service Mesh微服务架构，并可一键更换Service Mesh框架。不用学习微服务框架的SDK，通过无侵入的方式实现Service Mesh微服务架构，主流的Service Mesh框架以插件的形式存在，需要时开启，如果觉得不好还可以随时更换。

使用应用的体验：

1. 像安装手机App一样安装云原生应用。云原生应用以应用模版的形式存放到应用市场，当对接各种基础设施或云资源，实现应用即点即用或一键安装/升级。

2. 普通开发者不需要学习就能实现应用运维。通过应用级抽象，普通开发者了解应用级属性就能实现应用运维，并通过插件扩展监控、性能分析、日志、安全等运维能力，应用运维不再需要专用的SRE。

3. 复杂应用一键交付客户环境。复杂应用发布成应用模版，当客户环境可以联网，对接客户环境一键安装运行，当客户环境不能联网，导出离线应用模版，到客户环境导入并一键安装运行。