|
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 步：
进一步，为了安全和性能起见，如果我们想脱离 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 对容器的调度已经相当丰富：
由于 Mesos 更加 generic，其在容器调度方面稍显欠缺，目前我们可以通过设置主机attribute来将容器调度到指定的机器上。 选择当你尝试在 Docker Swarm 和 Mesos 之间做选择的时候，可以考虑以下几点。
最后，想再强调一遍，Mesos 更多的是从经济学角度出发来提高整个集群的资源利用率，拿它跟 YARN、Google Borg 作比较更合适；而 Docker Swarm 专注于 Docker 的集群管理，拿它跟 Kubernetes 比较可能更合适。 当然，在容器集群管理复杂度的问题上，基于Mesos的商业产品DCOS，如：国外的Mesosphere，国内的数人云，都已经做的非常简单和易用了。 所以总的来说，如果您想搭建一套集群生产环境，从稳定性和可扩展性来看，建议选择Mesos；如果是仅想运行Docker容器，从易用性角度来看，建议采用Docker Swarm。 作者简介周伟涛，现数人科技云平台负责人，曾就职于国际开源解决方案供应商 Red Hat， 红帽认证工程师， Mesos Contributor，高级 Python 开发工程师。 是国内较早一批接触使用Docker、Mesos等技术的开发者。 参考
(责任编辑：IT) |
