Docker Swarm与Apache Mesos的区别

转自http://www.infoq.com/cn/articles/difference-between-swarm-Docker-and-mesos-apache

Docker Swarm 是目前 Docker 社区原生支持的集群工具，它通过扩展 Docker API 力图让用户像使用单机 Docker API 一样来驱动整个集群；而 Mesos 是 Apache 基金会下的集群资源管理工具，它通过抽象主机的 CPU、内存、存储等计算资源来搭建一套高效、容错、弹性的分布式系统。

显然，这两者功能上有交集，网络上也有很多关于 Docker Swarm, Mesos 和 Kubernetes 之间区别的讨论，作为一个 Mesos 重度用户，最近也抽时间把玩了下 Docker Swarm。一路下来，Docker Swarm 给我的感觉首先是它特别简单、灵活，相较于 Mesos 而言， Docker Swarm 对集群的侵入性更小，从而资源损耗也更低；其次，我特别想强调的是目前看来，虽然它与 Mesos 之间功能有重叠，但是两者关注在不同的东西上了，所以拿这两者作比较没有多大意义。当然，未来这种情况可能会发生变化，这取决于社区的 roadmap 。下面我会从多个角度把 Docker Swarm 和 Mesos 进行比较。

配置

在安装配置方面，Docker Swarm 要比 Mesos 简单的多。使用 Docker Swarm 搭建一套集群，最简单的情况下只需要 3 步：

1. 通过 shell 命令 swarm create 生成一个集群的 token;
2. 借助这个 token 将想要添加到集群的主机广播到 Docker Hub 集群发现 的公共服务（Hosted Discovery with Docker Hub）上，这样我们就把主机添加集群中了；
3. 接下来通过命令 swarm manage 以及相应的 token 我们就可以在任何一台连接到互联网的主机上管理我们的集群了。

进一步，为了安全和性能起见，如果我们想脱离 Docker Hub 集群发现 的公共服务，我们只需要在第1步使用 staticfile、consul、etcd 或者 ZooKeeper 中的任意一个，甚至是静态的IP列表来做集群发现即可。

与 Docker Swarm 不同，我们必须保证 Mesos 的管理节点（master，相当于上述第3步中的 manager 机器）一直正常运行，然后才能向集群中添加agent/slave节点；另外向集群中添加节点时还需要配置 resource，containers 等基本参数；最后只搭建好了 Mesos 集群是无法方便的使用集群资源的，我们需要 Marathon、Chronos、Spark 等调度器去调度资源，才能真正使用起这套东西。显然 Mesos 的配置要比 Docker Swarm 复杂的多，当然这主要也是由 Mesos 需要支撑多种资源调度导致的。

易用性

由于 Docker Swarm 对外提供完全标准的 Docker API，只需要理解 docker 命令，用户就可以开始使用 Swarm 集群了； 而对于 Mesos 来说， 我们需要额外了解 Marathon 等调度器的 API 才能真正将 Docker 任务发布到集群上。当然 Marathon 调度器也为我们带来了好处，譬如 docker 容器的健康检查，失败重启机制等。

架构

我们首先参考博客 《Weave Discovery and Docker Swarm》里的架构图来分析下 Docker Swarm 的架构。

图中 vm1 和 vm2 代表集群中的计算节点，集群的每个节点上都运行着一个 swarm-agent 的 Docker 容器，这个swarm-agent 负责向 集群发现的后台（backend）广播节点的IP，其中 backend 我们在上面的配置部分已经提过，它可以是 Docker Hub 集群发现的公共服务或者是 etcd， consul、ZooKeeper 等一致性中间件；

vmmaster 代表集群中的管理节点，它上面运行着 swarm-manager 的容器，其中 vmmaster 是能够访问 backend 的任意机器， 譬如笔记本等；swarm-manager 通过监听 backend 来获取集群信息， 然后访问 vm1，vm2 的 docker daemon 程序的 REST API 接口部署容器等。

同时，我们借用 http://www.ericsson.com/research-blog/data-knowledge/mesos-meetup-hosted-ericsson-research/ 中的 Mesos 架构图解释下 Mesos 的架构，图中的 Mesos Slave 代表集群中的计算节点，对应于上图的 vm1/vm2；Mesos Master 与 MarathonScheduler 合起来一起对应于上图中 vmmaster；Mesos Master 是主动向其调度器 offer 资源的， 然后由调度器决定是否接受这些资源。

至此，我们已经可以发现两者的不同，Mesos 是支持多种调度器的，Docker 容器型的任务，Hadoop、Spark 的计算任务等都可以运行在 Mesos 框架上，Mesos 强调的是资源混用的能力；而 Docker Swarm 只专注于 Docker 容器型任务。从而，依据不同的调度器，Mesos 的执行器（executor）是可配置的；而 Docker Swarm 只需要 Docker Daemon 一种执行器。

集群高可用／容错

Docker Swarm 与 Mesos 都可以通过一致性中间件构造高可用集群。Mesos 的 Master 节点一般通过 ZooKeeper 保证高可用，而 Docker Swarm 的 manager 节点可以通过 consul、etcd 或 ZooKeeper 中的任意一个来保证高可用。 但是从目前 Docker Swarm 的架构来看，Swarm manager 节点的高可用不是必需的，因为即使 manager 节点宕机了，Swarm 的原有服务也不会受到影响。我还有一种更极端的想法， Swarm 集群平时不需要 manager 节点，只有在需要 metrics 信息，发布新的应用，或者健康检查时再启动 manager 服务即可，这是因为 manager 节点目前的功能非常单一，像容器的健康检查，失败重启等功能还没有实现，文档中提到的资源管理，以及服务中断等机制也都没有详细的介绍，我估计应该还在开发中。

基本的健康检查

截止我写这篇文章时，Docker Swarm 没有提供对其部署的容器进行健康检查的功能，所以需要容器部署方来进行相应的容器的健康检查以及异常重启等；而 Mesos 的调度器 Marathon 是支持健康检查的，它可以每隔一段时间扫描一次应用的绑定端口，并在容忍3次或者几次失败后将应用重启，目前支持 HTTP、TCP协议，当然，这都需要应用提供 health 的接口。

可扩展性/可插拔

由于 Docker Swarm 使用标准的 Docker API，从而任何使用 Docker API 与 Docker 进行通讯的工具都可以无缝地和 Docker Swarm 协同工作，譬如与 docker-compose 结合实现多主机 scale 容器，这个与 Kubernetes 的 Pod 非常类似；与 Shipyard 集成等。但这对 Docker Swarm 来说也是一个缺点：你只能做 Docker API 规定的事情。如果 Docker API 不支持某个你要的功能，你就不能直接使用 Docker Swarm 来实现，你可能需要使用一些特别的技巧来实现（也可能完全不能实现）。

Mesos 的可扩展性首先在于它可以承接各种调度器，Spark、Hadoop、Kafka、Cassandra、Marathon、Chronos 等等都可以拿 Mesos 来做资源池；其次，Mesos 可以与 Mesos-DNS 结合来实现内部的服务发现/负载均衡。

另外，Docker Swarm 也可以与 Mesos 结合，在Docker Swarm 的 repo 里面有一个 docker-swarm-on-mesos 子模块 https://github.com/docker/swarm/tree/master/cluster/mesos 。Docker Swarm 可以借助它成为 Mesos 的调度器，使用 Mesos 资源池里面的资源。但是目前我个人还没有发现这种结合的价值，唯一能够想到的一点就是可以借此绕过 Mesos 来直接调度 docker 容器同时集群仍然支持资源混用，毕竟我们通过 Mesos 来直接操纵单个容器没有那么方便。

弹性

Mesos 与 Docker Swarm 都支持的向集群添加新的节点。

调度

Docker Swarm 对容器的调度已经相当丰富：

• 通过参数 constraint 将容器发布到带有指定label的机器上。譬如将 MySQL 发布到storage==ssd 的机器上来保证数据库的IO性能；
• 通过参数 affinity 将容器发布到已经运行着某容器的机器上，或者已经pull了某镜像的机器上；
• 通过参数 volumes-from, link, net 等将容器自动发布到其依赖的容器所在的机器上；
• 通过参数 strategy 可以指定 spread，binpack和random 3种不同 ranking node 策略，其中 spread 策略会将容器尽量分散的调度到多个机器上来降低机器宕机带来的损失，反之binpack策略会将容器尽量归集到少数机器上来避免资源碎片化，random策略将会随机部署容器。

由于 Mesos 更加 generic，其在容器调度方面稍显欠缺，目前我们可以通过设置主机attribute来将容器调度到指定的机器上。

选择

当你尝试在 Docker Swarm 和 Mesos 之间做选择的时候，可以考虑以下几点。

• 你要部署的集群只是运行 Docker 容器么？如果是，你可以考虑 Docker Swarm，否则如果你的集群资源需要混用，你最好尝试 Mesos。
• 你要部署的集群是大型生产环境么？如果是，建议优先考虑 Mesos， 毕竟 Docker Swarm 还在开发中，而 Mesos 已经被国内外很多公司应用于生产环境上了；如果你只是想尝试 Docker 相关的东西，请考虑 Docker Swarm。
• 你或你的团队有足够丰富的 Linux 和分布式经验么？如果没有，建议考虑 Docker Swarm，毕竟 Docker Swarm 的配置使用都更简单，更易于troubleshooting；而使用 Mesos 集群，你需要解决 docker 之外的很多问题，Mesos 将成为你额外的负担。

最后，想再强调一遍，Mesos 更多的是从经济学角度出发来提高整个集群的资源利用率，拿它跟 YARN、Google Borg 作比较更合适；而 Docker Swarm 专注于 Docker 的集群管理，拿它跟 Kubernetes 比较可能更合适。 当然，在容器集群管理复杂度的问题上，基于Mesos的商业产品DCOS，如：国外的Mesosphere，国内的数人云，都已经做的非常简单和易用了。

所以总的来说，如果您想搭建一套集群生产环境，从稳定性和可扩展性来看，建议选择Mesos；如果是仅想运行Docker容器，从易用性角度来看，建议采用Docker Swarm。