一种Paas平台集群Container容器管理的方法

    最近CloudFoundry 和 Docker的发展势头确实很猛啊,使用这两个开源项目来搭建Paas平台的公司也逐渐的多了起来,但是很多公司仅仅是代搭建了一套试验环境,或者生产环境的规模还很小,很多问题都没有暴露出来,京东云擎(JAE.JD.COM)也是使用CloudFoundry框架搭建的,在此框架的基础上做的二次开发。随着JAE项目的逐渐扩张，用户数越一天比一天多,要管理好上万个Container确实让我们头疼了好久。

   

    其实大家都知道Container的管理主要集中在几个方面,第一个就是从Router进来的流量如何能快速的定位到指定的Container,第二个就是Container容器的健康情况如何快速发现和恢复

    其实只要接触过CloudFoundry的人都知道，CF架构中不管是Container的快速定位还是Container的的健康检查这一块都强依赖NATS消息中间件,通过DEA定时上报Container的心跳(包括了URL和Container的host:port 映射情况),前端Router通过注册NATS的 router.register或router.unregister来更新容器的信息,HM 通过注册心跳来对比用户的期望状态和容器的实际运行状态是否一致,其实这本来是一个很好的组件解耦架构,但是当Container发展到一定规模的时候,nats的消息量就会很大,router或hm要处理的数据也会很多,最主要的问题还是,Container的数据不是经常变动的,也就是说每次传输的信息95%都是一致的。从而导致了Nats和Router做了很多重复的工作。通过定时上报这种模式还有一个缺点就是必须通过设置心跳超时来判断数据的准确性这样就会导致一定的数据延迟性。

   既然Container的数据有一个明显的特点就是不经常变法,那么能不能每次只发生变法的数据呢,如果真能这样就可以大大减少NATS的数据传输和Router处理的压力。我想到的一个办法就是通过zookeeper+NATS来做Container的管理

   具体的思路是这样的,每台DEA在启动的时候向zookeeper注册一个临时节点(节点的内容里面保存了dea所管理的所有Container信息),当有容器创建的时候通过nats发布一条Container创建的消息,同时改变dea临时节点的内容,当有Contaienr销毁(包括人为销毁或Container异常挂掉的销毁)的时候向Nats发布一条容器消费的消息,同时改变dea临时节点的内容,如果VM挂掉或DEA异常挂掉因为DEA注册的是临时节点,所以zookeeper会自动删除这个不存活的dea节点, 在router或hm模块里面 注册dea发布的Container创建或销毁的topic用来处理Container碧昂更的情况, 同时router 在启动的时候需要从zookeeper中获取所有的dea临时节点信息，循环处理每个节点将节点中的Container取出来存在内存里面,当zookeeper发现dea临时节点删除或创建的时候会以事件的方式通知 客户端(比如router),此时router根据事件的类型,如果是删除节点,则删除该dea里面的所有容器,如果是新增节点则增加节点里面的所有Container信息。

    这样一来既可以很好的管理所有Container还减少了很多重复的消息传递和处理,最主要的一个还是不用设置心跳超时从而达到容器的变法更加实时的体现在管理端。具体的逻辑图大概是这个样子。