Mesos 在愛奇藝的實踐
Mesos 平臺每周啟動的容器超過 500 萬，峰值在線容器數近 2 萬；適當的資源超賣給我們帶來的是在最近一個季度中，所有集群 CPU 平均利用率超過 20%，而最繁忙的集群超過 50%，這對于一家互聯網公司來說非常不易。
在這些驚訝的數字背后，Mesos 支撐著許多重要業務，包括但不限于，幾乎所有視頻、音頻、圖片轉碼，對服務質量和穩定性要求非常高的在線服務以及 Storm ， Spark 這類實時計算分析業務等。
牛刀小試
時光如逝，回望 Mesos 在愛奇藝的發展歷程，也并非一番風順。且不論起初的時候人員不足，借人幫助開發，開源代碼成熟度不夠，一日三坑，不得不暫時擱置一些項目；更別提在一家發展迅速的科技娛樂公司去推動基礎設施服務變革的乏力感。
愛奇藝從 2013 年底開始調研 Mesos，這個聲稱受到 Google Borg 集群管理系統啟發的開源數據中心操作系統核心。
Mesos 是一個 ASF 頂級開源項目，Mesos的作者也創建了 Mesosphere 公司來更好的推動 Mesos 生態的發展。
并且，基于 Mesos，Mesosphere 發布了開源的數據中心操作系統 DC/OS ，這一次，暴露在你眼前的不僅是內核，而是一個完整的數據中心操作系統。
在 2014 年初，我們將 Mesos 0.16.0 部署到了生產環境，之上運行了一個自研的任務調度器，以短任務的形式運行視頻轉碼業務。
這之后，由于人員和開發量的關系，以及到了年中的時候，我們發現 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 的調研，并且在 Marathon 之上設計和開發我們自己的 PaaS 平臺 QAE（iQIYI App Engine）。
自研 PaaS 平臺 QAE
QAE 是一個完全自助式的（除了配額申請）容器云平臺，用戶（公司內部開發者）只需要申請資源配額，就能在 QAE 上實現對 App 的全自助式管理，生命周期管理自不必說，其它的高級功能例如：
- 基于角色的鑒權
- App 和容器的監控
- 非侵入式的接入自定義監控
- 訂閱式的報警
- 根據任何監控指標自動伸縮
- 支持灰度發布、AB 測試
- App 的高級分布策略
- 健康檢查
- 日志管理
- 歷史容器管理（方便排障）
- 在線控制臺
- CI/CD，自動部署
從用戶角度來看，IaaS 和 PaaS 面向的用戶群有所區別，前者要求用戶對系統有更好的理解，更高的熟悉度，類似管理員的角色；而后者要求用戶對軟件開發環境有更好的熟練度，類似開發者角色。
另一方面，從用戶的角度來說，IaaS 提供虛機本非用戶所需，用戶得到的虛機和物理機并沒有本質區別，所以對用戶來說，沒有什么附加值；IaaS 之所以普遍存在，出發點并不是為了給用戶提供更好，更高級的服務，而是節約計算成本，提高大規模計算資源的維護能力。
所以，PaaS 平臺 QAE 是更好的選擇。
從容器到微服務
經過兩年多的漫長發展，QAE 羽翼漸豐，也接入了近萬的在線容器，形成了良好的用戶口碑，已經變成了能夠吸引用戶主動采用的平臺。
我們的下一步是乘上 微服務 的風口，提供更多的微服務友好的基礎設施以及產品給我們的用戶（公司內部開發者）。
因為微服務幾乎總是和容器形影不離，可能會被人誤以為實現了容器云平臺，自然而然的也就實現了微服務平臺。
在我看來，其實不然，容器僅僅只是一種軟件分發、運行方式，和服務并不位于同一個維度；微服務之所以和容器形影不離，無非是容器相較于虛機來說更加易用，靈活，更加適合微小的服務來利用物理計算資源。
想象一下，微服務帶來了什么問題？
一個單體 App，如果需要部署 100 個實例來提供服務，以前基于虛機的時候，開發者需要部署 100 臺虛機，不管他用什么方式，總之需要部署；要知道，愛奇藝并沒有專門的應用 SRE 幫助開發者維護運行環境；而現在，如果開發者使用 QAE 來管理他的 App，那么只需要在 QAE 上部署一次即可，100 個，1000 個實例，不過是點點按鈕的事情。
所以，在這個例子中，對于開發者來說，將業務管理成本降低了 100 倍，太棒了！
但是，如果開發者決定將單體 App 拆分呢？如果拆成 100 個微服務，會變成什么情況？
在 QAE 上他得部署 100 次，即使 QAE 有 App 復制/導入的功能，也依然捉襟見肘，運維成本高企。
更難的是，這 100 個微服務的治理，100 個微服務的拓撲、依賴關系是什么樣的？各個微服務之間的流量是怎樣的？流量是否健康？微服務接口是否有完善的鑒權管理？是否能從各種維度對微服務之間的請求限流？服務調用跟蹤排障？怎樣快速發現，接入服務，跨數據中心的流量管控等等？
而這些微服務基礎設施，嚴格來說，并非需要總是和容器聯系起來，而是應該作為另一個維度的基礎設施，發揮著舉足輕重的作用，微服務基礎設施之于微服務就像虛機和容器之于單個 App 實例一樣重要。
微服務基礎設施例如：
API gateway， APM ，鏈路調用跟蹤，服務中心等正在積極的開發當中，相信和 QAE 一樣，兩年過后，一定也會得到內部用戶的認可。
只爭朝夕
兩年太遠，只爭朝夕；來看看我們現在正在做哪些事情呢。
改造 QAE 的健康檢查，以前是基于 Marathon 的健康檢查，由于 Marathon 健康檢查是集中式的，所以當容器達到數千的時候，可能會出現瓶頸；而 Mesos 的分布式健康檢查則不會有這個問題，因為計算節點總是伴隨著業務規模規模一起增長的。
QAE 支持托管計算資源，作為一個通用的平臺，我們有一些推薦的最佳實踐，比如：容器的配置有上限，因為我們不希望用戶把容器當做虛機，甚至物理機來使用；
支持的網絡特性，分布特性有限制，例如：共享的集群可不想讓用戶使用 HOST 網絡模式；
出于這些考慮，有些非常想使用 QAE 的特殊業務（例如：直播轉碼，HCDN 等）不得不被擋在了門外。
所以，我們正在實現 QAE 支持托管的計算資源，主要需要實現：
- 計算集群對用戶的鑒權，托管的集群只能被有權限的用戶看到和使用
- 集群特性，QAE 需要能夠探測集群支持的特性，例如：這個集群支持 HOST 網絡模式，支持配置 32 核的超大容器等等。
除了 QAE 之外，對于 Mesos 和 Docker ，我們也在做一些很酷的事情：
- 切換到 Mesos unified container，踢掉Docker daemon 這個一直不太穩定的家伙
- 從 Device-Mapper 切換到 OverlayFS ，另一個在高并發新建/刪除容器下不夠穩定的組件
- 從可配置的靜態資源超分遷移到動態的 Mesos Oversubscription，進一步提升資源利用率；這是一個和南京大學合作的項目，相信很快就會有結果
- 實現離線和在線業務的真正混布，結合 Mesos Oversubscription，進一步降低集群管理成本，提高利用率
- 使用 Mesos 統一管理 GPU 計算資源
- 引入公有云，提高 Mesos 集群擴容的速度和效率，讓業務能夠自由的在私有云和公有云上調度。
雖然自認為我們在推動公司容器化應用的道路上取得了一些階段性的成果，但路漫漫，其修遠兮，還有更多的事情等著我們去完成！
原文鏈接： Mesos 在愛奇藝 （作者：luffy）
作者介紹：
luffy，目前負責公司私有云計算平臺（虛機及容器）的建設；加入愛奇藝前，在英特爾開源技術中心參與 MeeGo、Tizen 移動操作系統的開發；開源軟件用戶、愛好者、貢獻者，對多個開源項目有代碼貢獻，從操作系統基礎軟件 Systemd，D-Bus 到云計算項目 Mesos，Chronos 等。