第三，数据存储问题。做业务少不了要在本机存储数据，这样机器就成为“有状态”的，不利于全局调度资源。为了能够全局调度，需要解决三个场景下的问题:是数据不需要永久本地存储但是会实时写到本地的，如应用的日志；二是需要永久存储的如DB数据；三是分布式存储场景中，要做到存储与计算分离。

　　第四，资源的信息管理就是要实现一个CMDB，能管理物理机和 vhost I的关联关系，必须能管理上万台甚至十几万台规模的机器集群。这样的机器集群管理框架目前可选的比较少，我们选择的是 Mesos，主要基于以下两方面的考虑。一是 Mesos目前相对比较成熟，主流的大公司使用较多，在实际场景中的使用规模已达5万台左右；二是 Mesos扩展性比较好，本身是轻量级的，可以灵活定制各种 Framework满足业务需要。

　　Mesos的模块化设计使得它的集群管理本身可做的事情并不多: Master仅仅把从Save收集的资源数据汇报给 Framework； Master和 Slave通过消息交互消息，不需要一直保持长连接。随着 Slave规模的扩大， Master的压力并不会显著增长。 Master本身的高可用是通过ZK( Zookeeper)来保证的，整个集群的架构设计非常清晰。

　　从上面的介绍可以知道网站制作Framework的修改需要比较灵活的支持，而当前 Mesos的 Framework的更新还比较麻烦。如果要更新 Framework的代码，就需要重启每个Slave的 execute，进而可能要停止 Slave上的任务，这在生产环境中是很难接受的。有鉴于此，我们对 Framework进行了无状态设计，在代码实现上，改用动态语言如Groovy来编写需要经常修改的逻辑，这样Govy实现的代码就可以动态加载而不需重启任务，对 Framework的功能进行调整就非常方便了。