Cloud Foundry中cloud_controller_ng架构简析

文章由LinuxBoy分享于2019-03-27 02:03:50热评（86）

Cloud Foundry中cloud_controller_ng架构简析

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

blobstore在具体实现中还会接管很多工作，比如：文件的拷贝，文件uri的创建，文件的压缩，文件的指纹定义等。

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
新浪微博：@莲子弗如清

推荐文章：

Cloud Foundry中cloud_controller_ng架构简析