【編者的話】
mesos
在愛奇藝目前管理著大約 2000 臺物理機，分布在多個資料中心，單個集群最大節點數接近 600。
storm
，spark
這類實時計算分析業務等。
時光如逝，回望 mesos 在愛奇藝的發展歷程，也並非一番風順。且不論起初的時候人員不足，借人幫助開發，開源**成熟度不夠，一日三坑，不得不暫時擱置一些專案；更別提在一家發展迅速的科技娛樂公司去推動基礎設施服務變革的乏力感。
愛奇藝從 2013 年底開始調研 mesos，這個聲稱受到
google borg
集群管理系統啟發的開源資料中心作業系統核心。
mesos 是乙個
asf頂級開源專案，mesos的作者也建立了
mesosphere
公司來更好的推動 mesos 生態的發展。
並且，基於 mesos，mesosphere 發布了開源的資料中心作業系統
dc/os
，這一次，暴露在你眼前的不僅是核心，而是乙個完整的資料中心作業系統。
這之後，由於人員和開發量的關係，以及到了年中的時候，我們發現
chronos
作為基於 mesos 的短任務排程器已經變得比較完善，順理成章的，我們嘗試從自研的轉碼框架切換到 chronos，由此開始了一段新的征程。
和使用 mesos 的感覺不一樣，chronos 並沒有 mesos 那樣穩定，以至於在後面大半年的時間裡，我們使用了一些臨時手段來維持穩定，直到後來有更多時間徹底解決了 chronos 的穩定性問題，在那之後，chronos 幾乎沒有再出過問題。
我們對 chronos 進行了大量開發，其中有超過 30 個 commit 回饋到 chronos 社群並被接受，而大部分則是我們內部私有的改動，不夠通用，所以沒有提交到社群，而我們內部則為修改後的 chronos 取名為 sisyphus，古希臘中推著石頭上山的神，這也是我們為數不多的自認為取得好的專案名字！
伴隨著 chronos 穩定性的提高，轉碼業務量逐步切換到 mesos 集群，直到 2015 年中轉碼團隊不再維護任何生產集群；至此，chronos 完全支撐了公司的轉碼生產業務。
在開發 chronos 的同時，我們也上線了
hadoop
on mesos 業務，不過由於業務量不大，以及後來 yarn/mapreduce2 的推出，我們將執行在 mesos 上的業務全部遷移到了 yarn 集群。
另一方面，storm 在解決了一些問題之後，能夠穩定的提供服務，所以我們也將 storm 業務接入了 mesos 集群。對於另乙個可以執行在 mesos 之上的框架 spark 來說，彼時的 spark 執行在 mesos 上還不夠穩定，所以我們並沒有上線 spark on mesos 業務。
因為，2014 年底我們開始了對
marathon
這裡還想囉嗦幾句，我對
iaas
和 paas
的理解。
從使用者角度來看，iaas 和 paas 面向的使用者群有所區別，前者要求使用者對系統有更好的理解，更高的熟悉度，類似管理員的角色；而後者要求使用者對軟體開發環境有更好的熟練度，類似開發者角色。
另一方面，從使用者的角度來說，iaas 提供虛機本非使用者所需，使用者得到的虛機和物理機並沒有本質區別，所以對使用者來說，沒有什麼附加值；iaas 之所以普遍存在，出發點並不是為了給使用者提供更好，更高階的服務，而是節約計算成本，提高大規模計算資源的維護能力。
所以，paas 平台 qae 是更好的選擇。
我們的下一步是乘上
微服務的風口，提供更多的微服務友好的基礎設施以及產品給我們的使用者（公司內部開發者）。
因為微服務幾乎總是和容器形影不離，可能會被人誤以為實現了容器雲平台，自然而然的也就實現了微服務平台。
在我看來，其實不然，容器僅僅只是一種軟體分發、執行方式，和服務並不位於同乙個維度；微服務之所以和容器形影不離，無非是容器相較於虛機來說更加易用，靈活，更加適合微小的服務來利用物理計算資源。
想象一下，微服務帶來了什麼問題？
sre所以，在這個例子中，對於開發者來說，將業務管理成本降低了 100 倍，太棒了！
更難的是，這 100 個微服務的治理，100 個微服務的拓撲、依賴關係是什麼樣的？各個微服務之間的流量是怎樣的？流量是否健康？微服務介面是否有完善的鑑權管理？是否能從各種維度對微服務之間的請求限流？服務呼叫跟蹤排障？怎樣快速發現，接入服務，跨資料中心的流量管控等等？
微服務基礎設施例如：
api gateway，
，鏈路呼叫跟蹤，服務中心等正在積極的開發當中，相信和 qae 一樣，兩年過後，一定也會得到內部使用者的認可。
兩年太遠，只爭朝夕；來看看我們現在正在做哪些事情呢。
改造 qae 的健康檢查，以前是基於 marathon 的健康檢查，由於 marathon 健康檢查是集中式的，所以當容器達到數千的時候，可能會出現瓶頸；而 mesos 的分布式健康檢查則不會有這個問題，因為計算節點總是伴隨著業務規模規模一起增長的。
qae 支援託管計算資源，作為乙個通用的平台，我們有一些推薦的最佳實踐，比如：容器的配置有上限，因為我們不希望使用者把容器當做虛機，甚至物理機來使用；
支援的網路特性，分布特性有限制，例如：共享的集群可不想讓使用者使用 host 網路模式；
出於這些考慮，有些非常想使用 qae 的特殊業務（例如：直播轉碼，hcdn 等）不得不被擋在了門外。
所以，我們正在實現 qae 支援託管的計算資源，主要需要實現：
除了 qae 之外，對於 mesos 和
docker
，我們也在做一些很酷的事情：
雖然自認為我們在推動公司容器化應用的道路上取得了一些階段性的成果，但路漫漫，其修遠兮，還有更多的事情等著我們去完成！
作者介紹：
luffy，目前負責公司私有雲計算平台（虛機及容器）的建設；加入愛奇藝前，在英特爾開源技術中心參與 meego、tizen 移動作業系統的開發；開源軟體使用者、愛好者、貢獻者，對多個開源專案有**貢獻，從作業系統基礎軟體 systemd，d-bus 到雲計算專案 mesos，chronos 等。
原文發布時間為：
2017-09-18
luffy
mesos 在愛奇藝的實踐
愛奇藝 筆試
題目描述 時間限制 1秒 空間限制 32768k 牛牛養了n只奶牛,牛牛想給每只奶牛編號,這樣就可以輕而易舉地分辨它們了。每個奶牛對於數字都有自己的喜好,第i只奶牛想要乙個1和x i 之間的整數 其中包含1和x i 牛牛需要滿足所有奶牛的喜好,請幫助牛牛計算牛牛有多少種給奶牛編號的方法,輸出符合要求...
愛奇藝程式設計題
1 爐石傳說 時間限制 c c 語言1000ms 其他語言3000ms 記憶體限制 c c 語言65536kb 其他語言589824kb 題目描述 小明喜歡玩一款叫做爐石傳說的卡牌遊戲，遊戲規則如下，玩家擁有n顆水晶和m張卡牌，每張卡牌的使用會消耗a顆水晶並且造成b的傷害值，請你幫小明算一下該如何使...
愛奇藝的自製節目
w 節目的現場搭建比較複雜，每一期都要在演播室 a 來錄製，x 節目的攝影機位調整會影響節目質量，每一期都固定在演播室 b 來錄製。而節目 y 和節目 z 的搭建都比較容易移動，攝影也沒有特別的要求，既可以在演播室 a 錄製，也可以在演播室 b 錄製。已知 w 節目一共 ew 期，每期錄製需要 w ...