cloud_controller_ng简介
cloud_controller_ng是Cloud Foundry v2版本中的一个重要组件。其中cloud_controller_ng是cloud_controller的next generation（ng）的含义，而cloud_controller_ng的设计不兼容原先老版的cloud_controller。老版本的cloud_controller采用Rails的MVC框架来实现，而cloud_controller_ng则采用Sinatra框架来实现，从实现角度来讲，更加轻量级。该版本的cloud_controller_ng还添加了很多重要的概念，比如app以及service必须使用的space和organization等。为简单起见，下文中以ccng代替cloud_controller_ng。
cloud_controller_ng架构图
以下是笔者通过对ccng源码的理解，自行描绘的ccng简单架构图。
从ccng架构图中可以看出ccng可以分为以下多个模块：
- DEA模块，主要负责与DEA组件进行交互；
- Stager模块，主要负责与DEA组件的staging部分进行交互；
- Blobstore模块，主要负责创建一个blobstore的存储，以供Cloud Foundry存储应用所需的静态文件；
- HealthManager（HM）模块，主要负责与HealthManager组件进行交互；
- CCDB模块，负责维护cloud_controller的数据库；
- collector_registrar模块，负责作为component向Collector组件注册；
- router_registrar模块，负责将cloud controller组件的域名注册至Router组件；
- legacy_api部分，负责接管ccng关于info，bulk以及services等的RESTful请求；
- 其他部分。
下文将从以上提及的多个模块，逐步剖析ccng的架构实现。
cloud_controller_ng之Stager模块
Stager模块的功能是负责管理应用的源码和buildpack进行捆绑打包，而最终打包后的形式为droplet。
在Cloud Foundry v1的版本中，对于一个Cloud Foundry云平台只有一个Stager组件。而在Cloud Foundry v2版本中，由于已经不存在原来独立的Stager组件，而将和Stager功能类似的staging模块设计成DEA的一个子模块。因此，如果v2版本的Cloud Foundry部署了多个DEA的话，那么该云平台中就会有多个Staging模块。正是由于有多个Staging模块的缘故，在ccng处设计了一个与这些Staging进行交互的模块，可以姑且称之为ccng的stager模块，该模块维护了一个stager
资源池，即stager_pool，并通过stager_pool来接收和分发有关staging任务的请求。
当有staging任务需要完成时，需要创建一个staging_request,该方法的实现位于：/cloud_controller_ng/lib/cloud_controller/app_stager_task.rb,代码如下:
# We never stage if there is not a start request
def staging_request
{ :app_id => @app.guid,
:task_id => task_id,
:properties => staging_task_properties(@app),
# All url generation should go to blobstore_url_generator
:download_uri => @blobstore_url_generator.app_package_download_url(@app),
:upload_uri => @blobstore_url_generator.droplet_upload_url(@app),
:buildpack_cache_download_uri => @blobstore_url_generator.buildpack_cache_download_url(@app),
:buildpack_cache_upload_uri => @blobstore_url_generator.buildpack_cache_upload_url(@app),
:start_message => start_app_message,
:admin_buildpacks => admin_buildpacks
}
end该请求的结构很清晰的表明了staging所做的工作，对应的工作如下：- app_id:创建的应用的id；
- task_id:相应的staging_task的id；
- properties:应用的基本属性等，比如使用资源，应用环境，使用服务等；
- download_uri:在blobstore中存储的应用源码app_package；
- upload_uri:最后打包成droplet之后，上传该droplet所使用的uri；
- buildpack_cache_download_uri:在blobstore中存储的该app所需要的buildpack的下载uri；
- buildpack_cache_upload_uri:buildpack上传的uri；
- start_message:启动该app所需要的基本信息，最终由DeaClient类的start_app_message方法来实现；
- admin_buildpacks:提供admin_bulidpack的下载uri。
除了创建staging_request，还需要从stager_pool中找出合适的stager来完成staging任务，找到合适的stager_id之后，即向该staging发送staging_request。
cloud_controller_ng之DEA模块
DEA模块的功能是负责ccng与众DEA之间通信。
在ccng中，DEA模块可以大致氛围三个部分：dea_client,dea_pool和dea_respondent。
dea_client
dea_client主要负责作为一个client，实现发送请求给DEA。当有请求到达ccng，ccng需要获取dea上应用的信息时，ccng都需要通过dea_client来完成发送请求。比如说：需要启动一个应用时，由dea_client来给DEA发送start请求；需要停止一个应用时，由dea_client来给DEA发送一个stop请求等。
dea_respondent
dea_respondent主要负责作为一个响应者，实现完成由DEA主动发送过来的请求。这类请求主要是当DEA中的应用退出的时候，会由DEA通过NATS想ccng发送应用退出的消息，从而ccng可以做后续相应的善后工作。
dea_pool
dea_pool主要负责维护Cloud Foundry中所有DEA的资源池。当Cloud Foundry中有新的DEA启动并开始工作时，都会通过NATS向ccng发布advertise信息，而ccng则通过发来的该部分信息向dea_pool中注册DEA信息。当有应用需要启动的时候，ccng需要找到合适的DEA来完成启动工作，这个时候则由dea_pool通过各DEA的资源使用情况等其他重要条件完成DEAs的筛选，找出符合条件的DEA。
cloud_controller_ng之blobstore模块
blobstore模块主要负责维护静态文件的存储，这部分文件主要分为三部分：
- 应用源码
- 应用buildpack
- staged应用，即droplet
cloud_controller_ng之HM模块
HM模块主要负责与health_manager建立通信，并完成有关应用健康状态的监控。该部分也可以简单分为两部分，一个为client，一个为respondent：- health_manager_client:主要负责充当ccng与health_manager进行通信的client端，通过messagebus初始化，并通过messagebus实现find_crashes,find_flapping_indices,health_instances三个功能。
- health_manager_respondent:主要负责接收ccng与health_manager通信过程中health_manager发来的信息，其中包含，health_manager要求ccng启动某些拥有，停止某些应用等。
其中关于HM模块，目前的ccng中包含有两个不同形式的HM，一个health_manager模块，另一个为hm_9000模块。
以上便是本文对cloud_controller_ng架构的简单解析。
转载请注明出处。
这篇文档更多出于我本人的理解，肯定在一些地方存在不足和错误。希望本文能够对接触Cloud Foundry中cloud_controller_ng组件的人有些帮助，如果你对这方面感兴趣，并有更好的想法和建议，也请联系我。
我的邮箱：shlallen@zju.edu.cn新浪微博：@莲子弗如清