Could Foundry学习（二）——核心组件分析

Cloud Foundry核心组件架构图如下：

主要组件：

    Cloud Controller：实质上是VMC和STS交互的服务器端，它收到指令后发消息到各模快，管理整个云的运行，相当于Cloud Foundry的大脑。

DEA：负责处理对所部署的App的访问请求，其实质是打包和访问Droplet。其中Droplet是通过Stager组件将提交的源代码及Cloud Foundry配置好的运行环境以及一些控制脚本等，全部打包在一起形成的tar文件。

Routers：对所有进来的请求进行路由控制。Router组件是可扩展的，由多个 Router共同处理进来的请求。但如何对Router做负载均衡不属于Cloud Foundry的实现范围。

进入Router的请求主要有两类。

• 第一类是来自VMC Client或者STS的，由Cloud Foundry使用者发出，叫做管理请求。这类请求会被路由到Cloud Controller组件处理。
• 第二类是对所部署的App的访问请求。这部分请求会被路由到App execution，即DEA组件中。

Health Manager：负责从各个DEA获得运行信息，然后进行统计分析、报告、发出告警等。

Services：负责提供云平台的各种应用服务，是一个独立的、插件式的模块，便于第三方方便地把自己的服务整合成Cloud Foundry服务。

辅助组件：

UAA：负责用户模型的认证，使用组织和用户空间等概念，利于用户及权限管理。另外UAA DB用于存储用户相关信息。

NATS：是一个基于事件驱动的、轻量级的消息系统，用于消息发布和订阅，联系着各个模块。

Stager：解决了打包（Stage）过程需要操作大量文件且操作时间长的问题，所以它作为独立进程，使打包工作异步进行，不阻塞作为核心组件的Cloud Controller。