Cloud Foundry中DEA组件内应用的启动与资源监控
Cloud Foundry中所有的应用都运行在一个称为DEA的组件中，DEA的全称是Droplet Execution Agent。
DEA的主要功能可以分为两个部分：运行所有的应用，监控所有的应用。本文主要讲解Cloud Foundry v1版本中DEA如何启动一个应用，以及DEA如何监控应用的资源使用。虽然DEA两个功能的实现远不止这么多，但是笔者认为启动应用和监控应用资源是DEA的精髓所在，很多其他的内容都是在这两个点上进行封装或者强化。
DEA启动应用在一般情况下，启动一个应用，首先需要三样东西：环境，源码，应用入口。
关于环境，Cloud Foundry在DEA节点处，已经部署完多套不同框架应用运行所需要的环境。关于源码，Cloud Foundry中有一个droplet的概念，它是一个可运行的源码包，比用户上传的源码还要多一些Cloud Foundry自定义添加的内容，比如说对于Spring应用，Cloud Foundry会将Tomcat将应用源码打包在一起，并且添加Tomcat中应用的启动，终止脚本等。关于程序入口，刚才已经涉及到，打包过程中，启动脚本已经被加入droplet之中。因此，DEA只需要简单的通过环境来执行启动脚本，就可以成功启动应用。在研究了源码之后，也会发现DEA中最主要的文件名为agent.rb，在启动这方面，也就是充当一个代理的角色，通过Linux底层的脚本命令来完成对应用的操作。
了解Cloud Foundry中消息机制的开发者，一定会熟悉NATS的订阅/发布机制，而DEA也正是通过这种机制实现接收“启动应用”的请求。订阅代码如下：
usage = @usage[pid] ||= [] cur_usage = { :time => Time.now, :cpu => cpu, :mem => mem, :disk => disk } usage << cur_usage而metrics变量则是记录整个DEA所有运行的应用加起来的应用资源，以便之后更新varz信息。
以上便是对于Cloud Foundry的DEA中的应用启动与应用资源监控。
评价 由以上的分析可知，Cloud Foundry v1版本中的DEA在实现资源的监控时，通过linux底层的ps来完成，而对于资源的控制，则并没有做的很好，使用的方式为启动时限制与超额时停止的策略。该方法显然不是最佳的，而Cloud Foundry也推出了warden的容器，实现对DEA中应用资源使用时的控制与隔离。如果笔者这脑袋能理解或者读懂的话，期待不久给大家送上warden的实现，以及cgroup的机制。
转载清注明出处。
这篇文档更多出于我本人的理解，肯定在一些地方存在不足和错误。希望本文能够对接触Cloud Foundry中DEA中应用运行与资源监控的人有些帮助，如果你对这方面感兴趣，并有更好的想法和建议，也请联系我。
我的邮箱：shlallen@zju.edu.cn