概述
Cloud Controller负责管理应用程序的生命周期。当开发者将一个应用发布到Cloud Foundry时也就是指发布到了Cloud Controller中，CC将存储原始应用程序部分，并创建一个记录来追踪应用程序的数据、并且通知DEA打包运行应用。CC还会保存orgs、spaces、services、service实例、user角色等信息。
架构
Cloud_Controller_ng架构图
从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请求；
- 其他部分。
功能：
Cloud Controller是CloudFoundry的管理模块。主要工作包括：
a) 对apps的增删改读；
b) 启动、停止应用程序（通过DEA）；
c) Stagingapps（把apps打包成一个droplet，通过Stager）；
d) 修改应用程序运行环境，包括instance、mem等等；
e) 管理service，包括service与app的绑定等；
f) Cloud环境的管理；
g) 修改Cloud的用户信息（通过UAA，ACM）；
h) 查看CloudFoundry，以及每一个app的log信息。
这似乎有点复杂，但简单的说，可以很简单：就是与VMC和STS交互的服务器端。VMC和STS与CloudFoundry通信采用的是restful接口，另一方面Cloud Controller是一个典型的Ruby on Rails项目，从VMC或者STS接到JSON格式的协议，然后写入Cloud ControllerDatabase，并发消息到各模快去控制管理整个云。
我们以部署一个App到CloudFoundry为例，在我们在敲完那条简单的push命令后，VMC开始工作，在做完一轮的用户鉴权、查看所部署的apps数量是否超过预定数额，问了一堆相关app的问题后，需要发4个指令：
a) 发一个POST到“apps”，创建一个app;
b) 发一个PUT到“apps/:name/application”，上传app;
c) 发一个GET到“apps/:name/”，取得app状态，看看是否已经启动；
d) 如果没有启动，发一个PUT到“apps/:name/”，使其启动。
第一版的CloudController是基于Ruby On Rails的，在新版中，为了与CloudFoundry其他模块一致，并且让架构更加简单，CloudController用Sinatra进行了重写，并且加入了更多的模块去细化CloudController的工作。
另外一个重要的改进是，第一个版本的Droplet是通过NFS共享的，但这样会带来安全、性能等问题，而新版中进行了两大改进：
a) 移除NFS，采用自己开发的，简单的blobstore来存放Droplet;
b) 为Ruby项目进行了优化，把常用的Gem保存在package cache里面。所以在打包Ruby项目的时候不需要到公网上下载Gem文件，而是从CloudFoundry内部的Cache获得，大大加速了Stage过程。
随着CloudFoundry的逐渐成熟，权限管理功能在新的版本进行了很大的加强，在原有的用户模型基础上，加入了组织、用户空间的概念。
用户模型的认证是由UAA模块实现的，它可以与企业已有的认证系统进行整合，例如LDAP，CAS等；鉴权是由ACM模块实现的。
上图示例了一个用户访问CloudController的API的过程。我们可以分别看到UAA与ACM模块在一套鉴权流程各自扮演的角色。