Mesos/Marathon的缺点

　　看了下 Mesos 和 Marathon 文档，夸赞的话就不提了，大家夸的够多了，这里来说一下他的不足之处，

　　1、Mesos 的代码用 C++ 写的，它大量使用模板，用了 stout 库，玩 monadic 的 Option 模板类啥的，没看出给代码正确性、可维护性带来多大好处，而且编译慢的要死，完整编译一遍要一两个小时。代码的OO 的封装并不完善，比如 systemd 的 runtime path, cgroup hierarchy path 路径拼接这种事居然没隐藏起来，让调用方自己拼接。

　　2、对 Docker 的支持是后加的，原先自己实现了资源隔离，现在还保留着这些功能，这块成了鸡肋了，代码还累赘。

　　3、SASL 认证是后加的，没仔细考古，感觉认证、授权都是很晚才考虑的，内置的 crammd5 的 authentication, authorization 的配置是命令行传入，修改要重启 Mesos master，文档里没仔细说 SASL，看起来 authentication 不需要重启 Mesos master 了，但 authorization 还是用 --acls 命令行传入，没发现有 RPC 接口动态改的，这你妹的管理性也太差劲了! 相比之下，看看 Hortonworks Data Platform 2.3 对认证和授权的完善程度，天壤之别啊!

　　4、Mesos master/slave 要连接到同一个 Zookeeper 集群，上万节点的集群里 ZooKeeper 压力太大，ZooKeeper 对整个集群稳定性重要性太高，也就是说 Mesos slave 不够自治。有意思的是 Mesos master 自己做了个 replicated log，貌似基于 PAXOS 一致性协议，用来记录 slave、tasks 什么的状态，这大概也是考虑到对 ZooKeeper 压力不能太大。 YARN 的架构里 ApplicationMaster 做了一个中间层，让每个 app 自治多点，不用依赖 MR1 里的单点 job tracker，Marathon 有这个意思，但是一个 Marathon master 会管理大量 app，只能用运行多个 Marathon 集群的办法增强 app 自治，个人觉得差强人意。 从这点看，YARN 的伸缩性和健壮性更好。

　　5、不止 authentication/authorization/resource 的静态配置，mesos slave 的 attributes 配置也是静态的，用 --attributes 命令行选项给 mesos slave 指定，所以给 slave 加个标签、改个标签都要重启 mesos slave。

　　6、resource 比如 cpu、mem 的动态预留在 0.23 版才加入，也就是说 0.23 之前，类似 YARN queue 的概念是静态配置的。在 Queue 的管理上，我原以为 Marathon 会加强，结果发现它压根没管 queue。Mesos 按framework role 来映射到资源分配，不支持树状的资源池。一个 marathon master 只用于管理一个资源池，这个资源池里所有 app 共用，没有配额限制，也不区分多个 job submitters，所以 Mesos 的搞法是只允许管理员提交 job 么? 还是说每个用户、每个 app 都搭独立的 Mesos master? 这就不用搞data center OS，大家直接瓜分物理机得了。

　　7、Mesos/Marathon 没考虑跨机房集群联合，这个也罢，微黑。

　　综上，我觉得 Mesos 一开始就没考虑多租户、动态配置管理这种事，最近才刚开始发现 DCOS 需要这些特性才慢慢加，比较之下，YARN 更多传承了高性能计算领域的 resource management + scheduler 设计。不客气的说，Mesos 这种学院派搞出的玩意，其实还不如 YARN 这种工程派凤凰涅槃后搞出的玩意好。