一、Rainbond总体技术架构

Rainbond践行以应用为中心的理念，吸纳优秀的社区解决方案，形成了应用控制、应用运行时，集群控制三大模块结合的数据中心技术架构，结合跨数据中心的上层结构应用控制台和资源控制台，形成了完整的PaaS平台解决方案，下面将对每个组件和重点流程进行介绍：

二、Chaos组件之应用构建（CI）

​Rainbond 应用构建(CI)的过程是将输入介质：源代码 或 Docker镜像进行一系列处理，最终生成 应用抽象 介质的过程。

此过程可重复操作，从而生成一系列的应用版本。

传统意义上说，完整的CI过程会包括：设计、编码、打包、测试和发布，Docker自推出以来逐步成为众多应用代码打包的新形式。

现有的CI产品中已经在源码测试和Pipline方面做得非常成熟，例如Jenkins，Gitlab等，因此Rainbond在对于源码或Docker镜像的前置处理方面可以直接对接第三方服务，由第三方服务处理完成的源码或镜像再对接到 Rainbond-Chaos 模块进行应用抽象。

这样Chaos的输入源是支持Git协议的代码仓库，Docker镜像仓库。如果是源代码，Chaos智能判断源码的类型，例如Java,PHP,Python，Dockerfile等，根据不同的源码类型选择对应的BuildingPack进行源码编译，同时识别源码中定义的运行环境要求参数，应用端口、环境变量等参数，形成应用抽象的配置雏形。除了Dockerfile以外的源码类型将被编译成应用代码环境包（SLUG）存储于分布式存储中，其他的生成Docker本地镜像存储于数据中心镜像仓库中，结合应用的各类属性信息形成应用抽象包。

• 关于源码编译的BuildingPack参考各语言支持文档。
• Chaos组件支持多点高可用部署，多点部署从MQ组件获取应用构建任务。

三、Worker组件之应用部署（CD）

worker组件将chaos构建出来的应用抽象进行实例化，配属应用运行需要的各类资源，完成应用生命周期中的运行态部分（CD）。

应用生命周期中可能经历启停、升级与回滚。不同的应用类型需要进行不同的控制策略，例如无状态应用能够进行无序的滚动升级，而有状态应用的升级控制策略将更加复杂。

应用运行需要各种外部环境支持，例如需要分配租户IP,端口等网络资源，需要根据应用设置配属持久化存储资源，例如共享文件存储分配存储目录，块存储等依托各类插件分配存储资源。根据应用依赖属性建立服务发现和负载均衡策略供给mesh插件。根据应用属性生成调度策略调用Kubernetes集群调度应用运行。

目前Rainbond使用Kubernetes以下资源类型：ReplicationController、Deployment、Statefulset、Service、Pod。对于用户来说，无需理解这些资源，我们产品中也不体现，其只是应用运行的载体。

worker组件功能分为有状态部分和无状态部分，为了实现worker组件的集群部署，worker进行了主节点选举，当选主节点的服务将额外启动一个gRPC服务，提供应用状态等数据服务

四、Entrance组件之应用负载均衡（LB）

当应用成功运行后，面临的就是如何访问的问题，下面就详细讲解Rainbond在应用运行后所做的处理：

• 应用运行时会为每个租户分配子网
  • 租户之间网络隔离，因此集群内运行的应用不能之间被外网访问到。
  • 应用每次启动IP地址跟随变化，所以租户内应用与应用直接也无法直接访问。
• 配置应用端口策略，平台设计了应用端口的服务控制，具有两种类型
  • 对内服务：对平台内部应用开放，并加入到租户级别内部负载均衡，内部应用间访问通过ServiceMesh实现
  • 对外服务：对平台外部应用开放，并加入到平台全局负载均衡
• 设置应用协议类型，应用支持HTTP和TCP协议的应用，并支持添加到负载均衡

Entrance组件支持集群部署，并通过etcd实现全局资源一致性，可防止了对同一个资源操作的重复进行。

五、Eventlog组件之应用日志处理

​Rainbond平台需要处理的日志和消息信息包含三大类，分别为：用户异步操作日志、应用构建日志和应用运行日志，下面针对这三类日志加以详细说明。

5.1 用户异步操作日志

对于用户操作日志，我们需要分布式跟踪每一次操作的最终状态，目前由eventlog组件根据每一次操作的日志汇聚判断操作的最终状态。其他组件在处理某一次异步任务过程中会将过程日志记录通过gRPC消息流发送到eventlog集群。

5.2 应用构建日志

主要展示源码构建或Docker镜像构建的输出信息，这些信息来自于Chaos组件。

5.3 应用运行日志等

关于应用日志，目前我们分为两种形式：

• (1) 标准输出/错误输出的日志

对于标准输出的日志，Rainbond定制了docker日志处理驱动插件，基于TCP数据流通信实现将所有计算节点的容器日志实时送往Eventlog组件按照应用级别的汇聚，从而进行存储和实时推送到UI。

• (2) 输出到持久化文件的业务日志（访问日志）

对于输出到持久化目录的业务日志，一般需要对其进行自动分析，例如对接ELK系统，因此在插件体系中安装日志处理插件，收集持久化目录的日志文件输送到第三方日志分析服务上。

随着集群规模越大，运行应用越多，日志处理量非常大，因此我们实现了Eventlog的集群，每一个应用的日志在传输之前会选择送往的eventlog服务节点，类似于数据分区。选择过程中做了均衡分配处理，例如当前有10000个应用，3个eventlog服务节点，将做到每个eventlog节点分别处理3000左右应用日志。

由于各种实时推送的需要，eventlog组件实现了websockt服务。

六、Webcli组件之应用容器控制

该组件实现了通过web的方式连接到容器控制台的功能。该组件通过与UI进行WebSocket通信，用户可以通过模拟Web终端发送各类shell命令，webcli通过kubernets提供的exec方式在容器中执行命令并返回结果到Web终端。

Webcli属于无状态组件，天然支持多点高可用部署。

七、Monitor组件之集群监控

Rainbond集群需要多个维度的监控：

• 应用业务性能级
• 应用容器资源级
• 集群节点级
• 管理服务级
  Rainbond借助Prometheus封装了Monitor组件，能够自动发现以上描述的各类监控对象并完成配置，将监控目标纳入Prometheus监控范围。Rainbond各组件也都实现了Prometheus的exporter端暴露监控指标。

Prometheus有单点性能障碍，例如单节点服务监控目标越多，内存与磁盘使用量大等问题，对于大型集群，我们借助monitor组件实现了Prometheus多点数据分区运行，并建立了Prometheus的集群查询机制。

除了监控我们还需要报警，monitor能够自动配置一些默认的报警规则，自定义的报警规则支持将在资源管理后台体现，后续将支持命令行控制。Prometheus发出报警信息到monitor,完成去重，忽略等操作后根据级别与用户需求完成邮件、微信、站内消息等报警方式。

八、Node组件之集群节点管理与ServiceMesh

Node组件是Rainbond集群组建的基本服务，集群内所有节点都需要运行该组件。

运行于管理节点的Node具有master角色，维护所有节点的状态与健康检查。在监控方面，Node暴露出节点的操作系统级别各类指标（集成promethes node-exporter），同时定时检查不同属性的节点上运行的各类服务状态，网络状态等。监控到问题并尝试自动处理，以提供集群自动化运维能力。

​第二方面，所有计算节点运行的Node服务组建起租户网络内运行应用的运行环境支持，特别是ServiceMesh支持。

Node提供了envoy的全局化配置发现支持，跟应用绑定的envoy插件通过宿主机网络跳出租户网络，访问到Node服务，并最终获取全局的服务网络治理配置。其他应用插件使用同样的机制从node服务中动态获取配置，应用运行信息等。

九、MQ消息组件

​MQ组件是基于etcd实现的轻量级分布式、消息持久化和一致性的消息中间件。该组件维护异步任务消息，提供多种主题的发布和订阅能力。

我们没有选择使用已有的消息中间件服务，主要是我们要实现分布式消息，还要保证消息的一致性，评估了现有的方案后都觉得不太合适且复杂，因此我们基于etcd的分布式能力实现了轻量级MQ组件，提供了gRPC和http两种接口实现pub/sub。

十、App-UI组件

应用控制台UI组件作为Rainbond以应用为中心抽象的关键模块，面向应用开发者和应用使用者。基于Django+Ant design前后端分离架构设计，提供用户对应用抽象、应用组抽象，数据中心抽象，应用市场抽象提供交互体验。实现完整的应用创建、管理流程，应用交付分享流程等。

十一、Resource-UI组件（企业版）

资源控制台UI组件提供Rainbond集群资源管理，计划支持对接IaaS的资源管理能力，面向运维人员设计。关注节点物理资源，集群资源，管理服务资源，应用实际使用资源，租户资源等管理。Rainbond自动化运维能力的关键展示平台。

十二、命令行工具grctl

grctl命令行工具提供一些有趣实用的应用管理功能和集群运维功能，并逐步丰富中。对于开源使用用户来说在没有ResourceUI的情况下方便进行集群管理和运维。