分享

深度剖析CloudFoundry的架构设计(3-4)

本帖最后由 xioaxu790 于 2014-6-17 09:20 编辑
问题导读:

1、Cloud Controlle模块用于做什么?
2、如何设计CloudFoundry的架构?




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的架构图:
22.jpg


图中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这里将会有大调整,但是在那部份代码公开前,我不方便在这评价太多。

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的架构设计(4)

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

深度剖析CloudFoundry的架构设计
@ hello_message_json中包括DEA的UUID,ip, port, 版本信息等内容。
再例如,CloudController需要启动一个Droplet的instance:
a)首先一个DEA在启动的时候,会首先会对自己UUID的消息主题进行订阅。
33.jpg

深度剖析CloudFoundry的架构设计

其他模块需要通过’’dea.#{uuid}.start”这个主题发送消息来使它启动,一旦这个DEA接收到消息,就会触发process_dea_start(msg)这个方法来处理启动所需要的工作。

b)Cloud Controller或者其他模块发送消息,让UUID为xxx的DEA启动。
44.jpg

深度剖析CloudFoundry的架构设计

c)DEA模块接收到消息后,就会触发process_dea_start(msg)方法。msg是由其他模块发送过来的消息内容,包括:droplet_id,instance_index, service, runtime等内容,process_dea_start会取得这些启动DEA必须的信息,然后进行一系列操作,例如从NFS中取得Droplet,解压,修改必要环境配置,运行启动脚本等等。等一切都准备好后,然后需要给Router发个消息,告诉它这个Droplet已经随时准备好报效国家,以后有相应的request记得让它来处理。
55.jpg

深度剖析CloudFoundry的架构设计

d)Router模块在启动时就已经订阅”router.register”消息主题。
66.jpg

深度剖析CloudFoundry的架构设计

收到前面DEA发出的信息后,会触发register_droplet方法,去绑定Droplet。到此启动一个Droplet的instance工作完成。

我们可以看到整个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支持,会在后续博文中有所论述.




没找到任何评论,期待你打破沉寂

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

推荐上一条 /2 下一条