dea架构分析

一、DEA整体架构

图1 DEA和其他组件

图2 DEA和warden

 

二、DEA和外部组件

1、DEA和NATS
在CF内部,各个组件相互配合来完成某项功能,都是通过nats的消息机制来完成的;

2、DEA和cloud controller
1)dea启动时,生成唯一的uuid来标识自身
    dea将自身信息发布到 staging.advertise 和 dea.advertise 两个消息主题; 
    同时订阅 staging..start 和 dea..start ;
2)cloud controller 会订阅 staging.advertise 和 dea.advertise,根据信息构造并实时更新 dea_pool 和 stager_pool;
3)当有 push 或者 start 应用的请求时,cloud controller 会查询两个 pool,找到合适的 dea,向对应的 [dea|stager]..start 发送消息;
4)对应 uuid 的dea 收到消息,根据消息信息执行 staging、start应用的操作;

3、DEA和router
router启动时,订阅 router.register ,同时向 router.start 发送消息;
DEA启动后会订阅 router.start ,然后将自身信息(ip、port等)发送到 router.register ;
router 接收到 router.register 上 dea 的消息后,立即更新路由信息;
以上过程不断循环,保持 router状态最新;

DEA向router注册应用实例,对外提供服务;
应用以warden中container的形式,对外提供服务;
router和dea通过NATS定时通信,获取到应用容器的ip、port等信息;

 

三、dea的文件服务

dea有两个跟文件服务有关的server:file api server 和 dea directory server;
dea启动时会附带启动file api server,而directory server的启动则是单独进行;
这两个server的区别在于:
dea directory server 启动后会向router注册,即外部可以访问到dea directory server;
所有跟dea相关的上传(上传droplet)和下载(如获取应用log文件)都是直接通过dea directory server来进行;
file api server起一个验证并返回请求真实路径的作用;

比如执行cf logs 命令,是重定向到dea directory server来提供服务;

 

你可能感兴趣的:(CloudFoundry)