共计 5850 个字符，预计需要花费 15 分钟才能阅读完成。
这篇文章将为大家详细讲解有关开源 PaaS Rainbond 架构与实现的示例分析，文章内容质量较高，因此丸趣 TV 小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
回顾云计算产业技术的发展，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 以应用为中心（app-centric）的产品设计理念体现在：
应用生产阶段，Rainbond 从设计上支持从各类型软件源构建生产应用，包括各类型编程语言源码、容器镜像、DockerCompose 文件等，以生产线的形式定义应用个层面元素——输入代码，输出应用；
应用运行阶段，Rainbond 以软件定义的方式管理存储、网络、计算等各种资源，并在此基础上运行 App-Runtime，为应用提供统一的、丰富的服务，构建高性能架构；
应用传播阶段，Rainbond 作为交付桥梁实现应用的一处构建、处处使用，即使是包含数百个独立应用的微服务架构服务，企业也可以通过 Rainbond 交付给最终用户一键部署使用；
Rainbond 希望以产品为纽带，构建由所有使用者组成的相辅相成的整体——在互联互通的应用管理生态体系中，有人创造应用、有人发挥应用的最大价值、有人为应用提供超大资源保障。
Rainbond 的技术架构
Rainbond 是一套完整的 PaaS 平台解决方案，包括由应用控制、应用运行时、集群控制等三大魔魁结合而成的数据中心技术架构，以及跨数据中心的上策应用控制台和资源控制台。
重点组建包括：
Chaos（应用构建 /CI）
Worker（应用部署 /CD）
Entrance（负载均衡 /LB）
Eventlog（日志处理）
Webcli（容器控制）
Monitor（集群监控）
Node（集群节点管理与 Service Mesh）
MQ（消息）
App-UI
Resource-UI
grctl（命令行工具）
Chaos（应用构建 /CI）
Rainbond 应用构建 (CI) 组件——Chaos 主要用于完成处理输入介质（源代码、Docker 镜像）并生成 Rainbond 应用抽象介质的过程。
传统意义上完整的 CI 过程包括：设计、编码、打包、测试、Release。而随着 Docker 逐步成为众多应用代码打包的新形式，以及 Jenkins、Gitlab 等已有的 CI 产品在源码测试和 Pipline 方面的成熟，Rainbond 实现了对源码或 Docker 镜像的前置处理，可直接对接第三方服务，由第三方服务完成源码或镜像处理，再对接到 Rainbond-Chaos 模块进行应用抽象。
Chaos 支持 Git 协议代码仓库、Docker 镜像仓库。对于源代码，Chaos 智能判断源码类型，如 Java、PHP、Python、Dockerfile 等，并根据不同源码类型选择对应 BuildingPack 进行源码编译，同时识别源码中定义的端口、环境变量等参数，形成应用抽象的配置雏形。Dockerfile 以外的源码类型将被编译成应用代码环境包（SLUG）存储于分布式存储中，其他源码则生成 Docker 本地镜像存储于数据中心的镜像仓库中，结合应用的各类属性信息形成应用抽象包。
源码编译的 BuildingPack 请参考各语言支持文档
Chaos 组件支持多点高可用部署，多点部署从 MQ 获取应用构建任务
Worker（应用部署 /CD）
应用部署（CD）组件——Worker 将 Chaos 构建完成的应用抽象进行实例化，配置应用运行需要的各类资源，并完成应用生命周期中的运行态部分工作（启停、升级、回滚等）。
不同的应用类型需要不同的控制策略，例如无状态应用能够进行无序的滚动升级，而有状态应用的升级控制策略将更复杂一些。
应用运行需要各种外部环境支持，例如网络资源（租户 IP、端口等）分配、应用配属持久化存储资源设置，再如分配存储目录和块存储等依托各类插件的存储资源分配、根据应用依赖属性建立服务发现和负载均衡策略供给 mesh 插件等。
根据应用属性生成的调度策略通过调用 Kubernetes 集群调度应用运行。目前 Rainbond 涉及 ReplicationController、Deployment、Statefulset、Service、Pod 等 Kubernetes 资源类型。不过对于 Rainbond 用户来说，不需要理解这些概念，这些概念在 Rainbond 产品只做为应用运行的载体，中没有使用上的复杂体现。
Worker 组件功能分为有状态部分和无状态部分，为了实现 worker 组件的集群部署，worker 进行了主节点选举，当选主节点的服务将额外启动一个 gRPC 服务，提供应用状态等数据服务。
Entrance（负载均衡 /LB）
负载均衡（LB）组件——Entrance 是已运行应用的关键组件。
Rainbond 应用运行时为每个租户分配子网，租户之间网络隔离，因此集群内运行的应用不能直接通过外网访问，而应用每次启动 IP 地址随之变化，租户内应用与应用之间也无法直接访问。
因此，Rainbond 设计了应用端口级的服务控制，具备对内服务和对外服务两个服务级别。打开相应的服务级别，应用运行时会生成对应的服务发现策略和负载均衡策略。
应用与应用直接的内部访问由 ServiceMesh 完成，而应用外部访问的负载均衡，由于不同应用提供不同协议的服务（http、mysql、mongo、websocket 等）、现有负载均衡器（nginx、haproxy 等）对于不同协议支持效果不同，Rainbond 设计在 4 层协议支持之外，实现应用级别的负载均衡器选择。
Entrance 模块需要对接不同的负载均衡器，针对于此抽象了池、节点、路由器规则等资源，实现不同的 adapter 适配不同的负载均衡器，并根据应用运行时和集群中应用的状态变化、上线策略，实时操作负载均衡器以实现应用级别的 LB。
Entrance 集群部署通过 etcd 实现全局资源一致性，防止了对同一个资源的重复操作
Eventlog（日志处理）
Rainbond 需要处理用户异步操作日志、应用构建日志、应用运行日志等日志和消息信息。
对于操作日志，需要分布式跟踪每一次操作的最终状态，由 Eventlog 组件根据每一次操作的日志汇聚判断。其他组件在处理异步任务过程中，会将过程日志记录通过 gRPC 消息流发送到 eventlog 集群。
Rainbond 推荐区分应用日志为两类：由标准输出和错误输出的系统日志和输出到持久化文件的业务日志（访问日志）。
对于标准输出的日志，Rainbond 定制了 docker 日志处理驱动插件，基于 TCP 数据流通信实现将所有计算节点的容器日志，实时送往 Eventlog 组件按照应用级别的汇聚，从而进行存储和实时推送到 UI。
随着集群规模越大，运行应用越多，日志处理量非常大，因此我们实现了 Eventlog 的集群，每一个应用的日志在传输之前会选择送往的 eventlog 服务节点，类似于数据分区。选择过程中做了均衡分配处理，例如当前有 10000 个应用，3 个 eventlog 服务节点，将做到每个 eventlog 节点分别处理 3000 左右应用日志。
对于输出到持久化目录的业务日志，一般需要对其进行自动分析（例如对接 ELK 系统），因此在插件体系中安装日志处理插件，收集持久化目录的日志文件并输送到第三方日志分析服务上。
由于各种实时推送的需要，eventlog 组件实现了 websockt 服务
Webcli（容器控制）
为方便用户进入容器空间进行命令行操作，Rainbond 提供 Webcli 组件，通过与 UI 进行 websocket 通信，用户可以模拟 Web 终端发送各类 shell 命令。
Webcli 通过 kubernets 提供的 exec 方式在容器中执行命令并返回结果到 Web 终端。
Webcli 属于无状态组件，天然支持多点高可用部署
Monitor（集群监控）
Rainbond 包含应用业务性能级、应用容器资源级、集群节点级、管理服务级等多维度监控。
而集群监控组件 Monitor 是在监控报警项目 Prometheus 基础之上包装而成，能够自动发现以上描述的各类监控对象并完成配置，将以上所述所有监控目标纳入 Prometheus 监控范围。Rainbond 各组件也都实现了 Prometheus 的 exporter 端暴露监控指标。
Prometheus 本身有单点性能障碍，当单节点服务监控目标数量很多时，内存使用量和磁盘使用量会变得非常大。为解决这一问题，Monitor 组件在 prometheus 之上建立集群查询机制，实现了 Prometheus 的多点数据分区运行。
在报警方面，Monitor 能够自动配置一些默认的报警规则（自定义的报警规则支持在资源管理后台体现），未来还将支持支持命令行控制。
实际运行中，Prometheus 将发出报警信息到 Monitor，在完成去重、忽略等操作后根据级别向用户发送邮件、微信、站内报警信。
Node（集群节点管理与 Service Mesh）
Node 是 Rainbond 集群的基础组件，运行于所有节点之上。当 Node 运行于管理节点，将具备 master 角色，维护所有节点的状态与健康检查。
在监控方面，Node 暴露出节点的操作系统级别各类指标（集成 promethes node-exporter），同时定时检查不同属性的节点上运行的各类服务状态、网络状态等。Node 会尝试自动解决监控到的问题，这是集群自动化运维能力的来源之一。
所有计算节点运行的 Node 服务共同组建起租户网络内运行应用的运行环境支持，特别是 ServiceMesh 支持。
Node 提供了 envoy 的全局化配置发现支持，与应用绑定的 envoy 插件通过宿主机网络跳出租户网络，访问 Node 服务获取全局的服务网络治理配置信息。其他应用插件通过同样的机制，可以从 node 服务中动态获取配置、应用运行信息等。
MQ（消息）
考虑到能够提供分布式消息一致性的消息中间件设计都很重，Rainbond 没有选择使用已有的消息中间件服务，基于 etcd 实现轻量级分布式、消息持久化和一致性消息中间件 MQ，用于维护异步任务消息、提供多种主题的发布和订阅能力，提供 gRPC 和 http 两种接口实现 pub/sub。
对于异步消息任务的保证执行是 MQ 组件的下一步迭代方向
App-UI
应用控制台 UI 组件是 Rainbond 以应用为中心抽象的关键模块，基于 Django+Ant design 前后端分离架构设计，为应用抽象、应用组抽象、数据中心抽象、应用市场抽象提供交互体验。目前 App-UI 组件实现了完整的应用创建、管理流程，应用交付分享流程。
Resource-UI
Resource-UI（资源控制台 UI）组件面向运维人员设计，提供 Rainbond 集群资源管理，关注节点物理资源、集群资源、管理服务资源、应用实际使用资源、租户资源等管理，是 Rainbond 自动化运维能力的关键展示平台。Resource-UI 目前属于 Rainbond 企业版功能模块，未来计划支持对接 IaaS 的资源管理能力，
grctl（命令行工具）
grctl 命令行工具提供一些有趣实用的应用管理功能和集群运维功能，方便开源使用用户来说在没有 ResourceUI 的情况下进行集群管理和运维，目前正在并逐步丰富中。
关于 Rainbond
Rainbond 是一款以应用为中心的开源 PaaS，由好雨基于 Docker、Kubernetes 等容器技术自主研发，可作为公有云或私有云环境下的应用交付平台、DevOps 平台、自动化运维平台和行业云平台，或作为企业级的混合云多云管理工具、Kubernetes 容器管理工具或 Service Mesh 微服务架构治理工具。
关于开源 PaaS Rainbond 架构与实现的示例分析就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
