摘要：是一個集群管理器，提供了有效的跨分布式應(yīng)用或框架的資源隔離和共享，可以運行。更貼近于層，而在之上。所以有人稱其為，或者分布式操作系統(tǒng)。你在這里可以看到使用的列表和有什么關(guān)聯(lián)嗎是一個為分布式應(yīng)用提供一致性服務(wù)的軟件，而是一個分布式應(yīng)用。

聽過不少人在討論 Mesos，然而并不是很明白 Mesos 到底能夠解決什么問題，使用場景是怎樣的，周偉濤（國內(nèi)較早一批接觸使用 Docker，Mesos 等技術(shù)的開發(fā)者）用一句話形容它， Mesos 能夠管理每臺機器的 CPU，內(nèi)存等資源，讓你像操縱單個資源池一樣來操縱整個數(shù)據(jù)中心。

周偉濤，現(xiàn)數(shù)人科技（主要產(chǎn)品數(shù)人云，基于 Mesos 和 Docker 技術(shù)的云操作系統(tǒng)）云平臺負責人，曾就職于國際開源解決方案供應(yīng)商 Red Hat， 紅帽認證工程師， Mesos Contributor，高級 Python 開發(fā)工程師。 是國內(nèi)較早一批接觸使用Docker，Mesos 等技術(shù)的開發(fā)者。

Apache Mesos 是一個集群管理器，提供了有效的、跨分布式應(yīng)用或框架的資源隔離和共享，可以運行 Hadoop、MPI、Hypertable、Spark。

（問答來自 OSChina 開源中國社區(qū)第 100 期高手問答 —— Apache Mesos）

Q1：對大多數(shù)人來說還不知道什么是 Mesos，請介紹下他是干什么的，有什么用，怎么用？

A1：你好， Mesos 在國內(nèi)的資料目前雖然不多，但是你隨便百度，谷歌一下，還是有一些的。這里我想拿一個例子來解釋 Mesos，假設(shè)某公司需要頻繁進行大數(shù)據(jù)計算，該任務(wù)運行時需要 N 多 CPU 和內(nèi)存，為了滿足這個需求，我們有兩種思路：

思路一）使用小型機，單機即可為任務(wù)提供足夠 的資源；

思路二）分布式計算，即提供一批普通配置的機器（計算節(jié)點），也就是集群，將計算任務(wù)拆分到各機器上計算，然后匯總結(jié)果。

思路二是當前正在流行的做法，這種方式的優(yōu)點不再多說。為了達到思路二的要求，我們需要建立數(shù)據(jù)中心（集群）。進一步，為了充分利用數(shù)據(jù)中心（集群）的資源（譬如為不同的任務(wù)分配不同資源，按任務(wù)優(yōu)先級分配資源等），我們就需要一個工具來進行整個數(shù)據(jù)中心資源的管理、分配等， 這個工具就是 Mesos。 與 Mesos 類似的工具還有 YARN.

除此之外， Mesos 不僅為計算任務(wù) Offer 資源， 它也支持運行長時任務(wù)（譬如 Web應(yīng)用）。目前國外好多互聯(lián)網(wǎng)公司都在使用 Mesos 來作為它們的集群管理工具，這里是一個 Powered by Mesos list： https://mesos.apache.org/documentation/latest/powered-by-mesos/

Q2：我們現(xiàn)在用 Cloudera 這套，能簡單介紹下 Mesos 和 Cloudera 的差別嗎？

A2：Mesos 的主要目標就是去幫助管理不同框架（或者應(yīng)用棧）間的集群資源。比如說，有一個業(yè)務(wù)需要在同一個物理集群上同時運行Hadoop，Storm及 Spark。這種情況下，現(xiàn)有的調(diào)度器是無法完成跨框架間的如此細粒度的資源共享的。Hadoop 的 YARN 調(diào)度器是一個中央調(diào)度器，它可以允許多個框架 運行在一個集群里。

但是，要使用框架特定的算法或者調(diào)度策略的話就變得很難了，因為多個框架間只有一種調(diào)度算法。比如說，MPI 使用的是組調(diào)度算法，而 Spark 用的是延遲調(diào)度。它們兩個同時運行在一個集群上會導致供求關(guān)系的沖突。還有一個辦法就是將集群物理拆分成多個小的集群，然后將不同的框架獨立地 運行在這些小集群上。再有一個方法就是為每個框架分配一組虛擬機。正如Regola 和 Ducom 所說的，虛擬化被認為是一個性能瓶頸，尤其是在高性能計算 （HPC）系統(tǒng)中。這正是 Mesos 適合的場景——它允許用戶跨框架來管理集群資源。

Mesos 是一個雙層調(diào)度器。在第一層中，Mesos 將一定的資源提供（以容器的形式）給對應(yīng)的框架?？蚣茉诘诙咏邮盏劫Y源后，會運行自己的調(diào)度算法來 將任務(wù)分配到 Mesos 所提供的這些資源上。和 Hadoop YARN 的這種中央調(diào)度器相比，或許它在集群資源使用方面并不是那么高效。但是它帶來了靈活性——比如說，多個框架實例可以運行在一個集群里。這是現(xiàn)有的這些調(diào)度器都無法實現(xiàn)的。就算是 Hadoop YARN 也只是盡量爭取在同一個集群上支持類似 MPI 這樣的第三方框架而已。更重要的是，隨著新框架的誕生，比如說 Samza 最近就被 LinkedIn 開源出來了——有了 Mesos 這些新框架可以試驗性地部署到現(xiàn)有的集群上，和其它的框架和平共處。

Q3：您好，Mesos 有哪些典型的應(yīng)用場景？看了一些介紹，說是能做 Docker 的編排服務(wù)。與 OpenStack 這樣的云平臺管理物理機 CPU、內(nèi)存，Cloudera Manager 管理 Hadoop 集群服務(wù)有什么區(qū)別？

A3：現(xiàn)在 Mesos 的應(yīng)用場景非常多，譬如
1）Spark on Mesos （這是標配 ）
2）Jenkins on Mesos
3）Mesos 做 docker 的編排服務(wù)等。

與 OpenStack 相比， 首先，物理機，虛擬機都可以作為 Mesos 的集群節(jié)點；其次， 粒度不同， Mesos 的基本計算單元是容器（LXC） , 而 OpenStack 的是 VM（聽說現(xiàn)在也支持Docker 容器技術(shù)了），前者資源利用率更高；最后，輕量級，Mesos 只負責 Offer 資源給Framework，不負責調(diào)度資源。 OpenStack 更貼近于 IaaS 層，而 Mesos 在 IaaS 之上。所以有人稱其為 DCOS，或者分布式操作系統(tǒng)。

Q4：各方面邊界在哪，有什么優(yōu)劣勢，謝謝。

A4：優(yōu)點
資源管理策略 Dominant Resource Fairness(DRF), 這是 Mesos 的核心，也是我們把Mesos 比作分布式系統(tǒng) Kernel 的根本原因。通俗講，Mesos 能夠保證集群內(nèi)的所有用戶有平等的機會使用集群內(nèi)的資源，這里的資源包括 CPU，內(nèi)存，磁盤等等。很多人拿 Mesos跟 k8s 相比，我對 k8s 了解不深，但是，我認為這兩者側(cè)重點不同不能做比較，k8s 只是負責容器編排而不是集群資源管理。不能因為都可以管理 Docker，我們就把它們混為一談。

輕量級。相對于 YARN，Mesos只負責 Offer 資源給 Framework，不負責調(diào)度資源。這樣，理論上，我們可以讓各種東西使用 Mesos 集群資源，而不像 YARN 只拘泥于 Hadoop，我們需要做的是開發(fā)調(diào)度器（Mesos Framework）。

提高分布式集群的資源利用率：這是一個 Generic 的優(yōu)點。從某些方面來說，所有的集群管理工具都是為了提高資源利用率。VM 的出現(xiàn)，催生了 IaaS；容器的出現(xiàn)，催生了 K8s, Mesos 等等。簡單講，同樣多的資源，我們利用 IaaS 把它們拆成 VM 與 利用 K8s/Mesos 把它們拆成容器，顯然后者的資源利用率更高。（這里我沒有討論安全的問題，我們假設(shè)內(nèi)部子網(wǎng)環(huán)境不需要考慮這個。)

缺點

門檻太高。只部署一套 Mesos，你啥都干不了，為了使用它，你需要不同的 Mesos Framework，像 Marathon，Chronos，Spark 等等?；蛘咦约簩?Framework 來調(diào)度 Mesos給的資源，這讓大家望而卻步。

目前對 Stateful Service 的支持不夠。Mesos 集群目前無法進行數(shù)據(jù)持久化。0.23 版本增加了 Persistent resource 和 Dynamic reserver，數(shù)據(jù)持久化問題將得到改善。

臟活累活不會少。Team 在使用 Mesos 前期很樂觀，認為搞定了 Mesos，我們的運維同學能輕松很多。然而，根本不是那么回事兒，集群節(jié)點的優(yōu)化，磁盤，網(wǎng)絡(luò)的設(shè)置，等等這些，Mesos 是不會幫你干的。使用初期，運維的工作量不僅沒有減輕，反而更重了。Mesos 項目還在緊鑼密鼓的開發(fā)中，很多功能還不完善。

Q5：我想請教下，如果要做一個云服務(wù)平臺，Mesos 和 Kubernates 怎么去選型

A5：目前的現(xiàn)狀是 Mesos 和 K8s 的生態(tài)圈各自都發(fā)展的比較好，丟棄哪一個都很吃虧。不如按你個人的喜好，先選擇一個投下去先用起來。比如數(shù)人云 直接一鍵部署，這樣太方便了?？梢钥焖袤w驗 Mesos 的好處。

這個要看你的具體需求。據(jù)我所知， K8s 目前只支持 Docker 而且鮮有生產(chǎn)環(huán)境的用例； 而 Mesos 不需要你的應(yīng)用包到 Docker 里面并且其經(jīng)歷過生產(chǎn)環(huán)境的考驗。 但是， 反過來， K8s 的社區(qū)更加活躍，其正在高速發(fā)展中，前景非常好。 當然，上述都不是關(guān)鍵， 一個好用的云平臺更多的是要有好的產(chǎn)品理念。 請參考數(shù)人云

Q6：對于長時間任務(wù)，有沒有好的調(diào)度器算法或者策略

A6：長任務(wù)是依靠馬拉松 Marathon 框架，對于 Docker，Mesos + Marathon 基本上是現(xiàn)在最成熟的分布式運行框架。長任務(wù)是依靠馬拉松 Marathon 框架，對于 Docker，Mesos + Marathon 基本上是現(xiàn)在最成熟的分布式運行框架。

Q7：請問下 Mesos 和 Docker 結(jié)合，Mesos 只是能解決資源分配問題對么？

A7：對的，Mesos 負責資源分配，需要有個東東負責 Docker 的任務(wù)調(diào)度，這樣就能將 Docker實例自動下發(fā)到集群中運行。這個組件叫馬拉松 Marathon。Mesos + Marathon 基本上現(xiàn)在最穩(wěn)定的 Docker 集群化調(diào)度框架

Q8：Mesos 現(xiàn)在可以逐漸應(yīng)用到生產(chǎn)環(huán)境了？

A8：Mesos 早就可以應(yīng)用到生產(chǎn)環(huán)境了， 國外的 Airbnb, Apple, Uber, Twitter，國內(nèi)的攜程，愛奇藝，還有我們公司數(shù)人科技都在生產(chǎn)環(huán)境使用了 Mesos。 你在這里可以看到使用 Mesos 的列表 https://mesos.apache.org/documentation/latest/powered-by-mesos/

Q9：Mesos 和 Zookeeper 有什么關(guān)聯(lián)嗎？

A9：Zookeeper 是一個為分布式應(yīng)用提供一致性服務(wù)的軟件， 而 Mesos 是一個分布式應(yīng)用。所以在生產(chǎn)環(huán)境，我們需要使用 Zookeeper 來為 Mesos 提供一致性服務(wù)。

Q10：Mesos，Swarm，Kubernetes 之間有沒有競爭關(guān)系？雖然這三家都說互相支持，但是這樣做會不會太啰嗦了？

A10：Swarm 與 K8s 有很多交叉。 Mesos 更多的是 Focus 在資源管理上， 只是恰好可以使用 Container 做資源隔離。競爭與否，還需要看社區(qū)的走向吧。

Q11：你好，看了看這個框架想請教幾個問題：

1.這個框架是否自帶日志搜集模塊？
2.這個框架能否進行性能統(tǒng)計？
3.這個框架在某個節(jié)點資源耗盡時可否自動切換？如果所有節(jié)點資源耗盡是否容易崩潰，自恢復能力如何？
4.這個框架可否配置負載均衡？
謝謝:)

A11：

帶日志模塊，但是功能比較簡單，沒有一個全局的展示

可以進行性能統(tǒng)計

Mesos 是根據(jù)當前的集群資源統(tǒng)計來決定給調(diào)度器分配多少資源的，資源耗盡只會導致新的應(yīng)用無法部署，不會影響正在運行的東西。

可以配置負載均衡。 并且 Mesos 本身也有多 Master 機制

Q12：請問 Mesos 怎樣決定分配多少資源？分配的資源什么時候回收？

A12：Mesos 與其它的集群管理工具不同， Mesos 本身不負責分配資源，它只是將當前集群的剩余資源提供給注冊到它的調(diào)度器，由調(diào)度器本身來決定使用多少資源，以及合適釋放資源。

Q13：假設(shè)集群里有 3 臺服務(wù)器，每臺服務(wù)器可用內(nèi)存 16G，現(xiàn)在調(diào)度器要運行一個任務(wù)需要24G 內(nèi)存，那么 Mesos 是把整個集群的 48G 內(nèi)存當成一個整體來提供，還是會向調(diào)度器提供每臺服務(wù)器剩余的內(nèi)存,也就是說下面兩種情況哪種才是正確的：

1. 調(diào)度器先申請節(jié)點1的 16G 內(nèi)存，再申請節(jié)點 2 的 8G 內(nèi)存，用哪個節(jié)點的內(nèi)存完全由調(diào)度器控制

2. 調(diào)度器一次過申請 24G 內(nèi)存，由 Mesos 控制具體是用了哪個節(jié)點的內(nèi)存。有可能是每個節(jié)點都分配了 8G；也有可能是一個節(jié)點 16G，另一個節(jié)點 8G

A13：看過 DPark 實現(xiàn) Mesos 的調(diào)度器。你一個任務(wù)需要 24G 內(nèi)存，這個任務(wù)就需要拆分才可以調(diào)度起來。每個小任務(wù)需要 16G 以下的內(nèi)存。才能通過調(diào)度器，調(diào)度到具體服務(wù)器。 調(diào)度器一般都是把任務(wù)調(diào)度到文件所在的機器上。由調(diào)度器控制使用哪里的資源， Mesos 告訴調(diào)度器哪些資源可用。

閱讀完這 13 個問答，希望可以讓你對 Mesos 的認識更深，并用于項目實踐，分享更多地經(jīng)驗給 Mesos 愛好者:)