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