一、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.<uuid>.start 和 dea.<uuid>.start ;
2)cloud controller 会订阅 staging.advertise 和 dea.advertise,根据信息构造并实时更新 dea_pool 和 stager_pool;
3)当有 push 或者 start 应用的请求时,cloud controller 会查询两个 pool,找到合适的 dea,向对应的 [dea|stager].<uuid>.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来提供服务;