首页 > 代码库 > Could Foundry学习(二)——核心组件分析
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。
Could Foundry学习(二)——核心组件分析