开源PaaS Rainbond的架构与实现

Rainbond是以应用为中心的开源PaaS,由好雨基于Docker、Kubernetes等容器技术自主研发,可作为公有云或私有云环境下的应用交付平台、DevOps平台、自动化运维平台和行业云平台,或作为企业级的混合云多云管理工具、kubernetes容器管理工具或Service Mesh微服务架构治理工具。

回顾云计算产业技术的发展,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的情况下进行集群管理和运维,目前正在并逐步丰富中。


开源PaaS Rainbond v3.6.0版本现已发布,提供Service Mesh微服务架构的开箱即用,插件式扩展治理功能,并支持spring cloud、api gateway、dubbo等框架。

进一步了解:Rainbond

原文发布于微信公众号 - 好雨云(goodrain-cloud)

原文发表时间:2018-06-29

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏CSDN技术头条

京东商品详情页应对“双11”大流量的技术实践

【编者按】此文是根据京东资深Java工程师张开涛11月21日在msup主办的 into100沙龙第14期《京东商品详情页应对大流量的一些实践》演讲中的分享内容整...

30410
来自专栏企鹅号快讯

如何改善遗留的代码库

作者 | Jacques Mattheij 译者 | aiwhj 在每一个程序员、项目管理员、团队领导的一生中,这都会至少发生一次。原来的程序员早已离职去度假了...

1947
来自专栏架构师小秘圈

系统架构设计的原则和模式

1 分层架构 分层架构是最常见的架构,也被称为n层架构。多年以来,许多企业和公司都在他们的项目中使用这种架构,它已经几乎成为事实标准,因此被大多数架构师、开发者...

3867
来自专栏逍遥剑客的游戏开发

Tiled源码分析: 序

35612
来自专栏程序员宝库

号称“开发者神器”的github,到底该怎么用?

GitHub是一个拥有数十亿行代码的网站,每天有数百万开发者聚集在一起,与开源软件进行协作和报告问题。简而言之,它是一个基于Git构建的软件开发人员的平台。

1034
来自专栏腾讯云技术沙龙

杨原:腾讯云Kafka自动化运营实践

下面我们有请腾讯云基础架构部高级工程师杨原给我们带来主题分享——腾讯云Kafka自动化运营实践。

1.2K13
来自专栏Java帮帮-微信公众号-技术文章全总结

【大牛经验】千万级并发实现的秘密

千万级并发实现的秘密 先解释一下什么是10k问题: 什么是 10K 问题? 在 1999 年,Dan Kegel 向网络服务器提出了一个骇人听闻的难题: 是时候...

5485
来自专栏杨建荣的学习笔记

关于PV,流量和带宽(r5笔记第37天)

参加了DTCC归来之后,各大电商技术大牛都会自豪的分享一下自己公司网站的PV,流量等等。当时也是一知半解,回来之后赶紧查了查,也算是扫扫盲。 以下摘自网络中,自...

4254
来自专栏顶级程序员

号称“开发者神器”的GitHub,到底该怎么用?

源 / 开源最前线 GitHub是一个拥有数十亿行代码的网站,每天有数百万开发者聚集在一起,与开源软件进行协作和报告问题。简而言之,它是一个基于Git构建的软件...

3867
来自专栏大数据文摘

大型网站系统架构演化之路

2455

扫码关注云+社区

领取腾讯云代金券