Mesos框架對比：Marathon 和 Aurora

Marathon 和 Aurora 都能在 Mesos 集羣上調度和運行常駐服務。本文比較了兩個框架的不一樣和優劣。

問題

Marathon 框架和 Aurora 框架都能在 Mesos 集羣上調度和運行常駐服務。個人問題是：

1. 兩個框架有哪些不一樣？我費了半天勁，也沒有找到可以很好地解釋兩者的關鍵區別的資料。

2. 任何程序或代碼，只要能在 Linux 系統上正常地運行，就能被這些框架調度和運行，這麼說對嗎？ Marathon 的開發者說 Marathon 可以運行「可在 shell 中執行」的任何程序或代碼。不過，這話有點空洞，讓人琢磨不透，:)

第 1 個解答

聲明：我是 Apache Aurora 的副總裁，擔任 Twitter 公司 Aurora 團隊的技術負責人也差很少五年了。個人觀點或許有片面之處，純屬我的觀點，與 Twitter 公司或者 Apache 基金會無關。

任何程序或代碼，只要能在 Linux 系統上正常地運行，就能被這些框架調度和運行，這麼說對嗎？ Marathon 的開發者說 Marathon 可以運行「可在 shell 中執行」的任何程序或代碼。不過，這話有點空洞，讓人琢磨不透，:)

徹底正確。 Marathon 和 Aurora 框架的本質就是調度集羣的資源，執行用戶提交的 Shell 代碼。

兩個框架有哪些不一樣？我費了半天勁，也沒有找到可以很好地解釋兩者的關鍵區別的資料。

確實， Aurora 和 Marathon 提供了類似的功能特性，都屬於「常駐服務的調度器」。換句話說，用戶提交如何運行常駐服務的腳本代碼，兩個框架將盡全力保證常駐服務的持續運行。

下面粗略地談談兩個框架的不一樣，包括每一個框架的缺陷。我能夠負責任地說，框架的開發者很是瞭解這些缺陷，正在設法修正。

易用程度

安裝 Aurora ，給人感受好似在拓荒，不容易。 用戶要控制和使用 Aurora ，要麼使用命令行程序，要麼使用某個 thrift 客戶端調用 Aurora 對外暴露的 thrift API （正在開發 REST API ，目前還不可用）。 用戶會感到犯難，由於他們得使用領域特定語言（ DSL ）配置 Aurora 。這種作法的好處是方便分享配置的模板和通用模式。

與之相比， Marathon 很容易上手，用戶很快就能運行一個 「Hello World」服務。 Marathon 提供很是棒的文檔，描述多種環境下如何運行一個服務。Marathon 提供 REST API ，方便用戶編寫調用 Marathon 的定製工具。 Marathon 使用 JSON 做爲配置格式，容易上手，但有爲了使用而使用之嫌。

目標用戶

Aurora 一直是爲大型工程組織而而設計的。 在 Twitter 公司，計算機集羣包含數萬臺機器，幾百個工程師在使用它，它也是支撐 Twitter 業務的關鍵。這勢必要求保證集羣系統的擴展性、穩定性和安全性。所以，咱們只會爲 Aurora 添加可以在生產環境中擴展的特性（例如，咱們把 Aurora 的 Docker 支持標記爲一個 beta 特性，由於 Docker 自己以及 Mesos-Docker 進程都存在須要解決的問題）。 Aurora 還提供了搶佔等功能，從而支持在同一個集羣中混合部署關鍵業務服務和原型、實驗任務。

很難評價 Marathon 的擴展性。 Marathon 老是很快推出新特性（ 例如， 添加 Docker 支持），從實踐的角度，感受太過冒進。這不能老是歸因於 Marathon ，其它各層也難逃干係。 Marathon 沒有提供搶佔的功能。

全部權

重點是搞清楚一個項目的全部權和管治模式。這不只決定了項目的開放性，更決定了哪些人和哪些公司擁有否認決議的權力。

• Marathon 的擁有者是 Mesosphere 公司

這是好事仍是壞事，不一樣的人有不一樣的見解。首先，用戶能夠付費購買 Marathon 的支持和額外功能；其次， Marathon 項目存在商業銷售， Mesosphere 公司的商業利益最終決定該項目的走向。

• Aurora 的擁有者是 Apache 基金會（ ASF ）

Aurora 項目採用 ASF 的管治模式，徹底由社區驅動。 Aurora 沒有付費客戶，如今也沒有軟件商店。

小結 若是你是一個新手，準備在 Mesos 上運行服務，我推薦使用 Marathon ，既容易上手，又方便融入 Mesos 生態系統。若是你準備爲公司構建具備戰略意義的私有云平臺，敬請考慮使用 Aurora ，由於它本就是爲此而生，並且已經在實踐中獲得證實。

第 2 個解答

兩個框架我都用過，下面是個人經驗總結。

Aurora

[+] 還能調度週期性任務
[+] 細粒度、可擴展、基於文件的配置
[+] 支持命名空間，因此多個環境能夠共存
[-] 只讀的用戶界面，沒有官方 API
[~] 文件配置和命令行執行的模式很麻煩（好處是更容易擴充功能集）

Marathon

[+] 很容易安裝和使用
[+] 提供用戶控制界面和擴展功能的 API （有些 API 功能目前都沒包含在用戶界面中）
[+] 監聽 API 調用的事件總線
[-] 只能處理常駐任務
[-] 部署-運行-清理三個步驟的區分不是很清晰，必須寫在一行腳本里

即便 Aurora 的功能更強，我仍是願意選擇使用 Marathon ，由於 Aurora 太複雜，沒有用戶控制界面，沒有提供 API 。

第 3 個解答

我使用 Marathon 的經驗更多些。

務虛：

• 相對而言， Marathon 是通過檢驗的產品，已經用在 AirBnB 的生產環境中。 Aurora 只是一個處於早期階段的 Apache 項目。

• 兩個框架都開源且開發活躍。你們既能夠請求官方代碼庫合併本身的貢獻，又能夠指出官方代碼庫存在的問題。

務實：

• Marathon 不能調度批處理任務和輪轉任務

• Marathon ( 0.8.x ) 有友好的用戶界面，更好的任務執行狀態監控

至於你的第二個問題，用戶能夠運行任何命令或者 Docker 容器， Mesos 保證了資源的隔離。假定你的機羣中 50% 是 CentOS 節點， 50% 是 Ubuntu 節點。若是你請求執行一個任務apt-get，有 50% 的可能會沒法執行。 Mesos 和 Marathon 對節點的實際系統一無所知。

第 4 個解答

聲明：我只有 Marathon 的使用經驗，沒用過 Aurora 。

關於第一個問題：從本質上說， Apache Aurora 至關於 Marathon Chronos ，即它可以調度和執行常駐服務和輪轉（批處理）任務。請參考 Aurora 用戶指南

關於第二個問題：是的，任何程序或代碼都能被兩個框架調度和執行可以。目前用 cgroups 和 Docker 運行程序，你也能夠指定本身的容器機制

原文連接：Marathon vs Aurora and their purposes（翻譯：柳泉波）

=======================

譯者介紹

柳泉波，讀書喝茶踢球寫程序。

來自：http://dockone.io/article/370