组件

组件的作用是使开发人员能够不用关注底层基础架构的情况下定义业务单元的部署模式，组件描述了可以作为大型分布式应用程序的一部分进行实例化的功能单元。例如，应用程序中的每个微服务都被描述为一个组件。再例如Wordpress+Mysql的业务系统Wordpress和Mysql被分别描述为组件。

组件模型具有以下主要属性：

• 构建源 定义组件的构建方式，主要包括源代码类、镜像类和应用模型类。

• 组件类型 定义组件的部署模式，目前Rainbond支持单实例无状态、多实例无状态、单实例有状态和多实例有状态类型，后期支持基于Operator的模式进行组件类型扩充。

• 环境配置 定义组件运行环境配置，包括环境变量和配置文件两类。

• 存储 定义组件的持久化存储需求。

• 端口 定义组件向外提供服务的能力。

• 资源配属和实例数量 定义组件部署的规模。

• 依赖关系 定义组件间通信依赖关系和变量注入配置。

如何用好“组件”

组件的划分是一个至关重要的事物，需要开发者掌握好以下原则：

• 一个组件一个服务；

• 一个组件一个主进程；

• 一个组件具有明确的业务边界；

• 有状态与无状态分离；

在Rainbond中，一个组件一个容器，因此如果是自定义镜像场景中，镜像的制作思想也应该与组件划分思想一致。在Kubernetes原生场景中经常有同一个Pod中多个容器的模式。一般情况下都是一个主业务容器加一些运维特性容器构成，比如Mysql+Mysql监控容器，API服务加日志收集容器等等，有主有次，主容器是业务，次容器是通用的运维特征，因此在Rainbond中将Pod多容器的能力运用成组件+插件的模式。组件定义主要业务，插件定义运维特征且通用。

让运行于外部的服务成为Rainbond组件

Rainbond 平台统一管理企业的业务系统，不可避免的是部分业务可能无法或暂无必要迁移到 Rainbond 集群中，但集群中已有组件可能需要与其通信或希望通过Rainbond 网关统一管理外网流量如何。对于此类场景 Rainbond 扩充了一个特殊的“组件”类型，第三方组件。通过指定第三方组件通信地址的方式将其纳入Rainbond 统一管理范畴。