Docker Swarm與Apache Mesos的區別
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 步：
- 通過 shell 命令 swarm create 生成一個集群的 token;
- 借助這個 token 將想要添加到集群的主機廣播到 Docker Hub 集群發現 的公共服務（Hosted Discovery with Docker Hub）上，這樣我們就把主機添加集群中了；
- 接下來通過命令 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。
作者簡介
周偉濤，現數人科技云平臺負責人，曾就職于國際開源解決方案供應商 Red Hat， 紅帽認證工程師， Mesos Contributor，高級 Python 開發工程師。 是國內較早一批接觸使用Docker、Mesos等技術的開發者。
參考
來自： http://www.infoq.com/cn/articles/difference-between-swarm-docker-and-mesos-apache