应用插件
概述
Rainbond 的插件体系抽象集中在业务层面，理论基础源于 Kubernetes 的 Pod 机制和一部分容器概念。针对平台业务层面对 Kubernetes 容器编排进行抽象，转变为一个对用户体验友善的 Rainbond 插件产品的过程，方便用户在不需要懂 Kubernetes 原理的情况下使用。
Rainbond 的插件类型主要有以下两种:
- 初始化容器: 在 pod 创建时运行的容器，主要用于初始化应用的数据、环境等，初始化容器在主容器启动之前启动，主要用于初始化应用的数据、环境等。
- 一般容器: 与主容器同时启动的容器，主要用于扩展应用的功能，如日志收集、监控等。
设计原则
Rainbond插件体系的设计遵循易于理解和易于使用的原则：
- 易于理解: 在 Rainbond 插件体系中，插件使用的过程即主容器与 init 或 sidecar 等容器结合的过程，原 理是将插件容器以 sidecar 容器（大部分）的形式编排至主应用的 pod 中，共享主应用容器的网络和环境变量。
- 易于使用: Rainbond 插件体系易于使用的原则体现在类应用化、绑定使用、独有的变量作用域等方面。
类应用化
Rainbond 插件体系为插件设计了与应用类似的生命周期，包含创建、启用、关闭等模式，与 Rainbond 平台用户操作应用的习惯保持一致。同时， Rainbond 插件体系简化了插件创建类型，支持基于 docker image 和 dockerfile 创建，创建插件比创建应用更加简单。
插件创建流程设计如下图所示：
需要注意的是，当一个插件版本固定后，其内存、版本信息、插件变量无法再做修改，这些元素仅作用于当前插件版本。需要修改插件变量等元素时，对插件进行重新构建，重复创建流程即可。
创建完成后，用户可以对插件进行针对性设置，目前可以设置变量、插件生效与否和内存设定。内存的限制将在 Pod 创建时进行限制，插件变量生效与实时修改在下文中会继续介绍。
独有的变量作用域
注入到容器内的变量设计为有两类：共用变量 与 插件变量。
- 共用变量就是主容器的变量，为使插件参与甚至扩展主应用的功能，在 Pod 创建过程中将主应用的环境变量注入到了插件容器中。
- 插件变量则仅作用在该插件容器内部，防止插件间的变量重复与混用。
插件使用
从应用市场安装插件
Rainbond 提供了丰富的插件市场，用户可以在应用市场中选择合适的插件安装到自己的应用中。
进入团队 -> 插件，点击从应用市场安装，选择需要的插件，点击安装即可。
新建插件
- 进入团队 -> 插件，点击新建插件:
- 插件名称: 插件的名称，用于区分不同的插件。
- 安装来源: Rainbond 提供镜像和 Dockerfile 两个安装来源。使用镜像时，提供镜像地址。使用 Dockerfile 文件时，提供项目源码地址。
- 插件类型: 插件类型有
初始化类型和一般类型。 - 资源限制: 插件的资源限制，包括 CPU 和内存。
- 启动命令: 插件的启动命令。
- 说明: 插件的说明信息。
- 进入已创建的插件内，构建插件。
- 添加插 件配置，如下：
- 配置组名称: 配置组的名称，用于区分不同的配置组。
- 配置项: 配置插件的环境变量，支持字符串、单选和多选三种类型。
开通插件
安装或新建插件完成后，需要将插件开通到组件中。
在组件详情页，点击插件，选择需要的插件，点击开通即可。
性能分析插件
- 进入团队 -> 插件，选择从应用市场安装插件，搜索性能分析插件，点击安装。
- 进入组件详情页，点击插件，选择性能分析插件，点击开通。
- 进入监控页面，选择性能分析插件，查看性能分析详情。
指标解释:
- 响应时间: 响应时间也称为延迟，组件一般工作于网络通信的应用层，比如 http、mysql、redis、grpc 等。组件每次处理一次客户端请求的用时即响应时间。如果我们从网络报文的维度来衡量的话即请求报文第一个包到达到响应报文的第一个包发出中间的时间。
- 吞吐率: 吞吐率也称为通讯量，即组件在单位时间内处理请求的次数。
- 错误率: 错误有显性错误（比如 HTTP 500 错误）和隐性错误（比如 HTTP 返回 200 然而业务是错误的），这里我们主要关注显形错误，每一种通信协议都有标准的错误类型，比如 mysql 有查询语句错误。错误率正常情况下与组件的饱和度有密切关系。