深度剖析CloudFoundry的架构设计(2)

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模块的架构图：

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

接着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返回等等。

 

原文：http://datacenter.watchstor.com/infra-134681_1.htm