加载中…
正文 字体大小:

开源PaaS平台-CloudFoundry的架构设计-转载

(2012-03-25 16:19:39)
标签:

cloudfoundry

开源

paas

分类: 转载文章
原文:http://www.oschina.net/question/12_32393
CloudFoundry云开发大会:http://www.infoq.com/cn/zones/vmware/

VMware在今年4月份突然发布了业内第一个开源的PaaS——CloudFoundry。发布至今的这几个月里,笔者一直关注它的演进,并从它的架构设计中获益良多,觉得有必要写出来与大家分享一下。

本文会分为两个部份:第一部份主要介绍CloudFoundry的架构设计,从它所包含的模块介绍起,到各部份的消息流向,各模块如何协调合作;第 二部份会在第一部份的基础上,以如何在你的数据中心里面用CloudFoundry部署一个私有PaaS为目标,把第一部分介绍到的架构知识使用起来。

第一部份讲的很多内容,会引用Pat在10月12日的VMwareCloud Forum上面关于CloudFoundry架构的演讲。Pat是CloudFoundry Core的负责人,他的那次演讲很值得一听。如果你当时在场,并且理解他所说的内容,本部份可以选择直接跳过。我除了会把说的内容讲具体点外,不太可能可以讲得比他好。

架构及模块

从总体地看,CloudFoundry的架构如下:这个架构图以及下文所用到的各模块架构图均来自Pat的PPT。从上图能够看到CloudFoundry主要有以下几大组件组成:

开源PaaS平台-CloudFoundry的架构设计-转载

1、Router路由分发:顾名思义,Router组件在CloudFoundry中是对所有进来的Request进行路由。进入Router的request主要有两类:首先是来自VMCClient或者STS的,由CloudFoundry使用者发出的,管理型指令。

例如:列出你所有apps的vmcapps,提交一个apps等等。这类request会被路由到AppLife Management组件,又叫CloudController组件去;第二类是外界对你所部署的apps访问的request。这部份requests 会被路由到Appexecution,又或者叫做DEAs的组件去。所有进入CloudFoundry系统的requests都会经过Router组件, 看到这里可能会有朋友会担心Router成为单点,从而成为整个云的瓶颈。

但是CloudFoundry作为云系统,其设计的核心就是去单点依赖,组件平行扩充,且可替代的以保证扩展性,这是CloudFoundry,甚至所有云计算系统的设计原则,后文会讨论CloudFoundry如何做到这点,目前只要知道,系统可以部署多个Routers共同处理进来的 requests,但是Router上层的LoadBalance不在CloudFoundry的实现范围,CloudFoundry只保证所有的 request是无状态的,这样就使上层均衡附载选择面非常非常大了,例如可以通过DNS做,也可以部署硬件的LoadBalancer,或者简单点,弄台ngnix作负载均衡器,都是可行的。

Router组件,目前版本是对nginx的一个简单封装(http和反向代理服务器)。熟悉ngnix的朋友应该知道,它可以一个套接字文件(.sock文件)作为输入输出。所有安装CloudFoundry的Router组件服务器都会安装一个nginx。从整体的来看,Router组件的结构如下:

开源PaaS平台-CloudFoundry的架构设计-转载

外界httprequest进入CloudFoundry服务器,nginx会首先接到request,nginx通过sock与 router.rb进行交互,于是真正处理请求的是Router组件。router.rb里面根据传入的url,用户名密码等,进行逻辑判断,到 CloudController组件或者DEA组件取数据并且返通过与niginx连接的.sock文件返回。

router.rb是对nginx进行了逻辑封装。熟悉CloudFoundry的朋友肯定知道,CloudFoundry给每一个app分配了一 个url访问,如果直接使用VMware所托管的CloudFoundry.com的话,那你的app的url可能就是 xxx.cloudfoundry.com,无论通过命令给你的app扩展了多少个instances,都是从这个url访问的,这里面的url转换路由 就是由router.rb实现的。

可以看到router核心还是转换和分发路由,除这个外再处理下鉴权方面的事情,由于router是所有外部request的唯一入口,很多这方面事情都可以在router做。

2、DEA(Droplet Execution Agency): 首先要解析下什么叫做Droplet。Droplet在CloudFoundry的概念里面是指一个把你提交的源代码,以及CloudFoundry配套好的运行环境,再加上一些管理脚本,例如Start/Stop这些小脚本全部压缩好在一起的tar包。还有一个概念,叫做Stagingapp,就是指制作上面描述这个包,然后把它存储好的过程。CloudFoundry会自动保存这个Droplet,直到你start一个app的时候,一台部署了DEA模块的服务器会来拿一个Droplet的copy去运行。所以如果你扩展你的app到10个instances,那这个Droplet就被会复制十份,让 10个DEA服务器拿去运行。

下图是DEA模块的架构图:
开源PaaS平台-CloudFoundry的架构设计-转载

Cloud Controller模块(下面会介绍)会发送start/stop等基本的apps管理请求给DEA,dea.rb接收这些请求,然后从NFS里面找到合适的Droplet。前面说到Droplet其实是一个带有运行脚本的,带运行环境的tar包,DEA只需要把它拿过来解压,并即行里面的start脚本,就可以让这个app跑起来。到此,app算是可以访问,并start起来了,换句话说就是有这台服务器的某一个端口已经在待命,只要有request 从这个端口进来,这个app就可以接收并返回正确的信息。可以理解为dea是一个容器,对部署的应用进行了二次封装,该容器可以动态的创建,托管和运行。

接着dea.rb要做些善后的工作:1、把这个信息告诉Router模块。我们前面说到,所有进入CloudFoundry的requests都是 由Router模块处理并转发的,包括用户对app的访问request,一个app起来后,需要告诉router,让它根据loadbalance等原 则,把合适的request转进来,使这个app的instance能够干起活;2、一些统计性的工作,例如要把这个用户又新部署了一个app告诉 CloudController,以作quota控制等;3、把运行信息告诉HealthManager模块,实时报告该app的instance运行情 况。另外DEA还要负责部份对Droplet的查询工作,譬如,如果用户通过CloudController想查询一个app的log信息,那DEA需要 从该Droplet里面取到log返回等等。

3、CloudController:CloudController是CloudFoundry的管理模块。主要工作包括:

  • a) 对apps的增删改读;
  • b) 启动、停止应用程序;
  • c) Staging apps(把apps打包成一个droplet);
  • d) 修改应用程序运行环境,包括instance、mem等等;
  • e) 管理service,包括service与app的绑定等;
  • f) Cloud环境的管理;
  • g) 修改Cloud的用户信息;
  • h) 查看Cloud Foundry,以及每一个app的log信息。

这似乎有点复杂,但简单的说,可以很简单:就是与VMC和STS交互的服务器端。VMC和STS与CloudFoundry通信采用的是 restful接口,另一方面CloudController是一个典型的Rubyon Rails项目,从VMC或者STS接到JSON格式的协议,然后写入CloudController Database,并发消息到各模快去控制管理整个云。和其他ROR项目一样,CloudController的所有API可以从 conf/routes.rb里看到。开放的Restful接口好处在于第三方应用开发和集成,企业在用CloudFoundry部署私有云的时候,可以 通过这些接口来自动化控制管理整个Cloud环境。这部份内容将在第二部份论述。下图是Cloud Controller的架构图:

开源PaaS平台-CloudFoundry的架构设计-转载

图中Health Manager和DEA是外部模块,CCDatabase就是CloudController Database,这个是整个CloudFoundry不能做HP的地方。CloudController Database的并发性不会很多,应用级别的数据库访问是由底下的Service模块处理的,这个数据库存的是Cloud的配置信息。读操作主要来自 DEA启动,作为初始化DEA的依据;以及healthmanager模块会从这里读取预期的状态信息,这部份数据会与从DEA得到的实际状态信息进行比对。

NFS是多个CloudController的共享存储,CloudController其中一个重要工作就是StagingApps。 Droplets的存储是在集群环境的唯一的。而CloudController是集群运行,换言之,就是每一个控制Request可能由不同的 CloudController处理,假设一个简单的用户场景:我们需要部署一个app到CloudFoundry中。我们在敲完那条简单的push命令 后,VMC开始工作,在做完一轮的用户鉴权、查看所部署的apps数量是否超过预定数额,问了一堆相关app的问题后,需要发4个指令:

  • 1.发一个POST到”apps”,创建一个app;
  • 2.发一个PUT到”apps/:name/application”,上传app;
  • 3.发一个GET到”apps/:name/”,取得app状态,看看是否已经启动;
  • 4.如果没有启动,发一个PUT到”apps/:name/”,使其启动。

如果第2和第4步由不同的Cloud Controller来处理,而又无法保证他们能找到同一个Droplet,那第4步将会因为找不到对应的Droplet而启动失败。如何保证这一连串指 令过来所指向的Droplet都是同一个呢?使用NFS,使CloudController共享存储是最简单的方法。但是这个方法在安全性等方面并不完 美。在10月12日的VMwareCloud Forum上,Pat告诉我们下一版本的CloudFoundry这里将会有大调整,但是在那部份代码公开前,我不方便在这评价太多。

CloudController可以理解为核心的调度模块,它从HealthManager获取性能和健康数据,根据调度策略动态的创建,停止实例,包括实例到router的挂接。整个方案类似原有的应用虚拟化的方法,并不一定需要有负载均衡硬件的支持。

4、HealthManager: 做的事情不复杂,简单的说是从各个DEA里面拿到运行信息,然后进行统计分析,报告等。统计数据会与CloudController的设定指标进行比对, 并提供Alert等。HealthManager模块目前还不是十分完善,但是CloudManage栈里面,自动化health管理、分析是一个很重要 的领域,而这方面可以扩展的地方也很多,结合OrchestrationEngine可以使云自管理、自预警;而与BI方面技术结合,可以统计运营情况, 合理分配资源等。这方面CloudFoundry还在发展之中。

5、Services:Cloud Foundry的Service模块从源代码控制上看就知道是一个独立的、可Plugin的模块,以方便第三方把自己的服务整合入 CloudFoundry生态系统。在Github上看到service是与CloudFoundry Core项目vcap独立的一个repository,为vcap-service。Service模块其中设计原则是方便第三方服务提供商提供服务。在 这方面CloudFoundry做得很成功,从Github上看,已经有以下服务提供:a)MongoDB; b) mysql; c) neo4j; d) PostgreSql; e) RabbitMQ; f) Redis; g)vBlob。基类都是放在base文件夹中。

第三方如果需要自己开发CloudFoundry的服务,需要继承改写它里面的两个基础类:Node和Gateway;而里面一些操作, 如:Provision,可以在base的provisioner.rb基础上加入自己的逻辑,同样的还有Service_Error和 Service_Message等。关于如何写自己的Service,ELC的博客会推出相应文章详细论述,并不在本文的讨论范围里面,从架构了解上来 说,只要知道服务间的关系,知道个服务与base间透过继承关系来横向扩充,而CloudFoundry与apps调用Service是通过base来完 成这一简单的架构方法即可。

6、NATS(Message bus): 从CloudFoundry的总架构图看,位于各模块中心位置的是一个叫nats的组件。NATS是由CloudFoundry的架构师Derek开发的一个轻量级的,支持发布、订阅机制的消息系统Github开源地址是:https://github.com/derekcollison/nats。其核心基于EventMachine开发,代码量不多,可以下载下来慢慢研究。

CloudFoundry是一个多模块的分布式系统,支持模块自发现,错误自检,且模块间低耦合。其核心原理就是基于消息发布订阅机制。每个台服务 器上的每个模块会根据自己的消息类别,向MessageBus发布多个消息主题;而同时也向自己需要交互的模块,按照需要的信息内容的消息主题订阅消息。 譬如:一个DEA被加入CloudFoundry集群中,它需要向大家吼一下,以表明它已经准备好服务了,它会发布一个主题是”dea.start”的消息:

我们可以看到整个CloudFoundry的核心就是一套消息系统,如果想了解CloudFoundry的来龙去脉,去跟踪它里面复杂的消息机制是 非常好的方法。另一方面,CloudFoundry是一套基于消息的分布式系统,面向消息的架构是它节点横向扩展,组件自发现等云特性的基础。

Cloud Foundry的架构简单介绍至此,其实作为第一款开源的PaaS,CloudFoundry架构有很多可以学习借鉴的地方,很多细节上的处理是很精妙 的,这些内容如果有可能会在后续文章继续探讨,本文题虽为深入CloudFoundry,其实也只是浅尝即止,把总体架构介绍一下,目标在于使我们有足够 的背景知识去用CloudFoundry搭建企业内部的私有PaaS。总结一下,笔者从CloudFoundry的结构中学到的东西:

1、基于消息的多组件架构是实现集群的简单、且有效方法。消息可以使集群节点间解耦,使自注册,自发现这些在大规模数据中心中很重要的功能得到实现;

2、适当的抽象层,模板模式的使用,方便第三方可以方便在CloudFoundry开发扩展功能。CloudFoundry在DEA及 Service层都做了抽象层处理,相对应地使开发者可以容易地为CloudFoundry开发Runtime和Service。例如,在 CloudFoundry刚推出的时候,只支持Node.js,Java, Ruby,但第三方提供商、开源社区快速跟进,为CloudFoundry添加了PHP,Python的支持。这得益于CloudFoundry精巧的 DEA架构设计,如何开发新的Runtime支持,会在后续博文中有所论述.

0

阅读 收藏 转载 喜欢 打印举报
  

新浪BLOG意见反馈留言板 电话:4006900000 提示音后按1键(按当地市话标准计费) 欢迎批评指正

新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

新浪公司 版权所有