深度剖析CloudFoundry的架构设计(5) |
发布时间: 2012/7/22 16:08:00 |
第三方如果需要自己开发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”的消息: @ hello_message_json中包括DEA的UUID,ip, port, 版本信息等内容。 再例如,CloudController需要启动一个Droplet的instance: a)首先一个DEA在启动的时候,会首先会对自己UUID的消息主题进行订阅。 其他模块需要通过’’dea.#{uuid}.start”这个主题发送消息来使它启动,一旦这个DEA接收到消息,就会触发process_dea_start(msg)这个方法来处理启动所需要的工作。 b)Cloud Controller或者其他模块发送消息,让UUID为xxx的DEA启动。 c)DEA模块接收到消息后,就会触发process_dea_start(msg)方法。msg是由其他模块发送过来的消息内容,包括:droplet_id,instance_index, service, runtime等内容,process_dea_start会取得这些启动DEA必须的信息,然后进行一系列操作,例如从NFS中取得Droplet,解压,修改必要环境配置,运行启动脚本等等。等一切都准备好后,然后需要给Router发个消息,告诉它这个Droplet已经随时准备好报效国家,以后有相应的request记得让它来处理。
d)Router模块在启动时就已经订阅”router.register”消息主题。
收到前面DEA发出的信息后,会触发register_droplet方法,去绑定Droplet。到此启动一个Droplet的instance工作完成。亿恩科技石头 负责服务器租用和托管业务 本文出自:亿恩科技【www.enkj.com】 |