深度剖析CloudFoundry的架构设计

1、深度剖析CloudFoundry的架构设计2011-10-27 13:23 来源:博客VMware在今年4月份突然发布了业内第一个开源的 PaaSCloudFoundry。发布至今 的这几个月里，笔者一直关注它的演进， 并从它的架构设计中获益良多， 觉得有必要写出来 与大家分享一下。本文会分为两个部份：第一部份主要介绍CloudFoundry的架构设计，从它所包含的模块介绍起，到各部份的消息流向，各模块如何协调合作；第二部份会在第一部份的基础上， 以如何在你的数据中心里面用CloudFoundry部署一个私有PaaS为目标，把第一部分介绍到的架构知识使用起来。第一部份讲的很多内容，会引用Pat

2、在10月12日的VMwareCloud Forum上面关于CloudFoundry架构的演讲。Pat是CloudFoundry Core的负责人，他的那次演讲很值得一听。 如果你当时在场，并且理解他所说的内容，本部份可以选择直接跳过。我除了会把说的内容讲具体点外，不太可能可以讲得比他好。从总体地看，CloudFoundry的架构如下、架构及模块appsapp lifecycle managementapp executionservjceIrfecycleblQbstoreservice instancesrauth/:router1 t这个架构图以及下文所用到的各模块架构图均来自Pat的PP

3、T从上图能够看到CloudFoundry主要有以下几大组件组成：1、Router :顾名思义，Router组件在 CloudFoundry中是对所有进来的Request进行路由。进入 Router的request主要有两类：首先是来自VMCClient或者STS的，由CloudFoundry使用者发出的，管理型指令。例如：列出你所有 apps的vmcapps,提交一个apps等等。这类request会被路由到 AppLife Management组件，又叫CloudController组件去；第二类是外界对你所部署的apps访问的request。这部份requests 会被路由到 Appexe

4、cution，又或者叫做 DEAs的组件去。 所有进入CloudFoundry系统的requests都会经过Router组件，看到这里可能会有朋友会 担心Router成为单点，从而成为整个云的瓶颈。但是CloudFoundry作为云系统，其设计的核心就是去单点依赖，组件平行扩充，且可 替代的以保证扩展性，这是CloudFoundry，甚至所有云计算系统的设计原则，后文会讨论CloudFoundry如何做到这点，目前只要知道，系统可以部署多个Routers共同处理进来的requests，但是 Router 上层的 LoadBalanee 不在 CloudFoundry 的实现范围，CloudFo

5、undry 只保证所有的request是无状态的，这样就使上层均衡附载选择面非常非常大了，例如可以通过DNS做，也可以部署硬件的LoadBalancer，或者简单点，弄台 ngnix作负载均衡器，都是可行的。Router组件，目前版本是对nginx的一个简单封装。熟悉ngnix的朋友应该知道，它可以一个套接字文件（.sock文件）作为输入输出。所有安装CloudFoundry的Router组件服务器都会安装一个nginx，其ngnix.conf 文件有以下配置：upstream vcp router server uniXT/tmo/route r sock；从整体的来看，Router组件的结

6、构如下:routerhttp reques-trequesl外界httprequest 进入CloudFoundry 服务器，nginx会首先接到request , nginx通过 sock与router.rb 进行交互，于是真正处理请求的是Router组件。router.rb 里面根据传入的url ,用户名密码等，进行逻辑判断，至UCloudController 组件或者DEA组件取数据并且返通过与niginx连接的.sock文件返回。router.rb 是对nginx进行了逻辑封装。熟悉CloudFoundry的朋友肯定知道，CloudFoundry给每一个app分配了一个url访问，如果

7、直接使用VMware所托管的CloudF 的话，那你的 app的url可能就是 ，无论通过命 令给你的app扩展了多少个instances，都是从这个url访问的，这里面的url转换路由就 是由router.rb 实现的。2、DEA(Droplet Execution Agency):首先要解析下什么叫做Droplet 。 Droplet 在CloudFoundry的概念里面是指一个把你提交的源代码，以及CloudFoundry配套好的运行环境，再加上一些管理脚本，例如 Start/Stop 这些小脚本全部压缩好在一起的 tar包。还有 一个概念，叫做 Stagingapp ,就是指制作上面描

8、述这个包，然后把它存储好的过程。CloudFoundry会自动保存这个 Droplet，直到你start 一个app的时候，一台部署了 DEA模块的服务器会来拿一个Droplet的copy去运行。所以如果你扩展你的 app到10个instances，那这个Droplet就被会复制十份，让10个DEA服务器拿去运行。下图是DEA模块的架构图：fetch dropletsstart/top rnsianceadirectcommunicationwith servicesCloud Controller 模块（下面会介绍）会发送 start/stop等基本的apps管理请求给DEA dea.rb接

9、收这些请求，然后从NFS里面找到合适的 Droplet。前面说到 Droplet其实是一个带有运行脚本的，带运行环境的tar包，DEA只需要把它拿过来解压，并即行里面的start脚本，就可以让这个 app跑起来。到此，app算是可以访问，并 start起来了，换句 话说就是有这台服务器的某一个端口已经在待命，只要有request从这个端口进来，这个app就可以接收并返回正确的信息。接着dea.rb要做些善后的工作：1、把这个信息告诉 Router模块。我们前面说到，所有进入CloudFoundry的requests都是由Router模块处理并转发的，包括用户对app的访问request，一个a

10、pp起来后，需要告诉 router，让它根据loadbalanee 等原则，把合适的 request转进来，使这个app的instanee能够干起活；2、一些统计性的工作，例如要把这 个用户又新部署了一个app告诉CloudController ，以作quota控制等；3、把运行信息告诉HealthManager模块，实时报告该 app的instanee 运行情况。另外 DEA还要负责部份对 Droplet的查询工作，譬如，如果用户通过CloudController想查询一个 app的log信息,那DEA需要从该Droplet里面取到log返回等等。3、CloudController : Cl

11、oudController是 CloudFoundry 的管理模块。主要工作包括：a）对apps的增删改读；b）启动、停止应用程序；c）Staging apps（把 apps 打包成一个 droplet ）;d）修改应用程序运行环境，包括instanee、mem等等；e）管理 service，包括 service 与 app 的绑定等；f）Cloud 环境的管理；g）修改Cloud的用户信息；h）查看Cloud Foundry，以及每一个 app的log信息。这似乎有点复杂，但简单的说，可以很简单：就是与VMC和STS交互的服务器端。VMC和STS与CloudFoundry通信采用的是 res

12、tful 接口，另一方面 CloudController是一个典型的Rubyon Rails项目，从VMC或者STS接到JSON格式的协议，然后写入 CloudController Database，并发消息到各模快去控制管理整个云。和其他 RO顾目一样，CloudController 的所有API可以从conf/routes.rb里看到。开放的 Restful接口好处在于第三方应用开发和集成，企业在用CloudFoundry部署私有云的时候，可以通过这些接口来自动化控制管理整个Cloud环境。这部份内容将在第二部份论述。F图是Cloud Controller的架构图:starVslop in

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

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

15、: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告诉

16、我们下一版本的CloudFoundry这里将会有大调整，但是在那部份代码公开前，我不方便在这评价太多。4、HealthManager:做的事情不复杂，简单的说是从各个 DEA里面拿到运行信息，然后进行统计分析，报告等。统计数据会与 CloudController的设定指标进行比对，并提供Alert等。HealthManager模块目前还不是十分完善，但是CloudManage栈里面，自动化 health管理、分析是一个很重要的领域，而这方面可以扩展的地方也很多，结合OrchestrationEngine可以使云自管理、自预警；而与 BI方面技术结合，可以统计运营情况，合理分配资源等。这方面Cl

17、oudFoundry还在发展之中。5、 Services:Cloud Foundry的Service模块从源代码控制上看就知道是一个独立的、可Plugin的模块，以方便第三方把自己的服务整合入CloudFoundry生态系统。在 Github上看至U service 是与 CloudFoundry Core 项目 vcap 独立的一个 repository ，为 vcap-service 。 Service模块其中设计原则是方便第三方服务提供商提供服务。在这方面CloudFoundry做得很成功，从 Github上看，已经有以下服务提供：a)MongoDB; b) mysql; c) neo4

18、j; d)PostgreSql; e) RabbitMQ; f) Redis; g)vBlob。基类都是放在 base 文件夹中。第三方如果需要自己开发CloudFoundry的服务，需要继承改写它里面的两个基础类：Node 和 Gateway;而里面一些操作，如：Provision ，可以在 base 的 provisioner.rb 基础上加入自己的逻辑，同样的还有 Service_Error 和Service_Message等。关于如何写自己的Service , ELC的博客会推出相应文章详细论述，并不在本文的讨论范围里面，从架构了解上来说，只要知道服务间的关系，知道个服务与base间透

19、过继承关系来横向扩充，而CloudFoundry与apps调用Service是通过base来完成这一简单的架构方法即可。6、NATS(Message bus):从CloudFoundry的总架构图看，位于各模块中心位置的是一 个叫nats的组件。NATS是由CloudFoundry的架构师Derek开发的一个轻量级的，支持发 布、订阅机制的消息系统。Github 开源地址是： 其核心基于EventMachine开发，代码量不多，可以下载下来慢慢研究。CloudFoundry是一个多模块的分布式系统，支持模块自发现，错误自检，且模块间低 耦合。其核心原理就是基于消息发布订阅机制。每个台服务器上的

20、每个模块会根据自己的消息类别，向MessageBus发布多个消息主题；而冋时也向自己需要交互的模块，按照需要的 信息内容的消息主题订阅消息。譬如：一个DEA被加入CloudFoundry集群中，它需要向大家吼一下，以表明它已经准备好服务了，它会发布一个主题是”dea.start ”的消息：NATS.piiD!ishj dea.start'r 阻h巳 o vne5sage json) hello_message_json 中包括 DEA的 UUID,ip, port, 版本信息等内容。再例如，CloudController需要启动一个 Droplet 的 instanee :a) 首先一

21、个DEA在启动的时候，会首先会对自己UUID的消息主题进行订阅。NATS.sutascrjbeCd&a.sfuuidlstdn") I I msg I process d电 startimsgj其他模块需要通过dea.#uuid.start”这个主题发送消息来使它启动，一旦这个DEA接收到消息，就会触发process_dea_start(msg)这个方法来处理启动所需要的工作。b) Cloud Controller或者其他模块发送消息，让UUID为xxx的DEA启动。N ATS,pu bi I shf'de a tdea J d. start", ispn)

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

23、;cresister', :=> VCAP;:CompQnent,uurd.:host =? lot道 I ip,:port => instance:port|r删options! 11 instance! :url5J,:tags 二鼻rframework -> inEtancerframeworkj:runtime => instance:runtime.to json)d) Router模块在启动时就已经订阅” router.register”消息主题。NATS.subscribe' router.register i ' |nnp has

24、h = Yail：!p3rser.par5e( itiEh ：5VEtx>li?o keys =>return *jui oris - riiifit hrtshhuris训总丄则* 附蛰 1st 电匚由opl 电 tfmrl,Msg_h 的 h岀 ertpn 年:tagMU收到前面DEA发出的信息后，会触发register_droplet 方法，去绑定 Droplet。到此启动一个Droplet的instanee 工作完成。如果想了解 CloudFoundryCloudFoundry 是组件自发现等云特性的基PaaS CloudFoundry 架我们可以看到整个 CloudFou

25、ndry的核心就是一套消息系统，的来龙去脉，去跟踪它里面复杂的消息机制是非常好的方法。另一方面, 一套基于消息的分布式系统，面向消息的架构是它节点横向扩展, 础。Cloud Fou ndry的架构简单介绍至此，其实作为第一款开源的这些内容如果有可能会在后构有很多可以学习借鉴的地方，很多细节上的处理是很精妙的，续文章继续探讨，本文题虽为深入CloudFoundry，其实也只是浅尝即止，把总体架构介绍一下，目标在于使我们有足够的背景知识去用CloudFoundry搭建企业内部的私有 PaaS总结一下，笔者从 CloudFoundry的结构中学到的东西:1、基于消息的多组件架构是实现集群的简单、且有效方法。消息可以使集群节点间解耦，使自注册，自发现这些在大规模数据中心中很重要的功能得到实现;2、适当的抽象层，模板模式的使用，方便第三方可以方便在CloudFoundry开发扩展功能。CloudFoundry在DEA及Service层都做了抽象层处理，相对应地使开发者可以容易地 为CloudFoundry开发Runtime和Service。例如，在 CloudFoundry刚推出的时候，只支持Node.js,Java, Ruby，但第三方提供商、开源社区快速跟进，为CloudFoundry添加了PHP,Python的支持。这得益于 CloudFound