Marathon 架構和 Aurora 架構在Mesos的應用場景存在差異

Marathon 架構和 Aurora 架構都能在 Mesos 叢集上排程和運作常駐服務。後者同樣具有任務型業務排程能力。功能角度類似Marathon和Chronos的角色。

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 沒有付費客戶，現在也沒有軟體商店。