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.<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来提供服务；