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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A3：現在 Mesos 的應用場景非常多，譬如
1）Spark on Mesos （這是標配 ）
2）Jenkins on Mesos
3）Mesos 做 docker 的編排服務等。

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

Q4：各方面邊界在哪，有什么優劣勢，謝謝。

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

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

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

缺點

門檻太高。只部署一套 Mesos，你啥都干不了，為了使用它，你需要不同的 Mesos Framework，像 Marathon，Chronos，Spark 等等。或者自己寫 Framework 來調度 Mesos給的資源，這讓大家望而卻步。

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

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

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

A5：目前的現狀是 Mesos 和 K8s 的生態圈各自都發展的比較好，丟棄哪一個都很吃虧。不如按你個人的喜好，先選擇一個投下去先用起來。比如數人云 直接一鍵部署，這樣太方便了。可以快速體驗 Mesos 的好處。

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

Q6：對于長時間任務，有沒有好的調度器算法或者策略

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

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

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

Q8：Mesos 現在可以逐漸應用到生產環境了？

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

Q9：Mesos 和 Zookeeper 有什么關聯嗎？

A9：Zookeeper 是一個為分布式應用提供一致性服務的軟件， 而 Mesos 是一個分布式應用。所以在生產環境，我們需要使用 Zookeeper 來為 Mesos 提供一致性服務。

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

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

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

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

A11：

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

可以進行性能統計

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

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

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

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

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

1. 調度器先申請節點1的 16G 內存，再申請節點 2 的 8G 內存，用哪個節點的內存完全由調度器控制

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

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

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