深度剖析CloudFoundry的架构设计(4)
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工作完成。
我们可以看到整个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支持，会在后续博文中有所论述.