本文主要概述阿裡巴巴zeus資源排程系統的背景和實作思路。本文主線：問題、解決方案、依賴基礎知識、工程實踐、目标、經驗分享。立足企業真實問題、正常解決政策，引出依賴的容器技術、實踐方案，所有這些落實到工程實踐，要解決那些問題、實作哪些目标、技術大趨勢的影響。最後給出阿裡巴巴的實踐經驗。本序列文章并不是突出架構上重大突破，畢竟這個領域已經發展了10多年了。而是，實踐過程中的一些細節、一些特殊場景下的特殊處理方法，作為一種新的認知素材。依賴的容器或周邊系統，都不會進行深入的分析，圍繞資源排程概括性地做一些總結和補充些細節描述。
1. 背景：資源浪費剖析
企業裡面資源排程的存在或者必要性，與企業發展規模有很強的關聯關系。任何企業從一開始就有某種程度的、某種特有階段性的“伺服器資源配置設定使用方案”，隻是對資源或者成本“優化”的度,或者效率的要求急迫性、重要性不是那麼突出。當伺服器數量以萬為機關增長，成本支出過億的大背景下，依賴面向容器技術的資源排程和管理，顯得非常急迫和重要。制定執行成本優化目标，落到實踐中，首先需要對資源浪費、已有系統的缺陷、資源使用率不高進行系統化的診斷，然後執行平穩的逐漸優化、提升效率、使用率。這就是問題或者需求的源頭。
（1）資源管理混亂
資源管理系統沒有掌握資源的利用情況，目前的資源使用率是怎麼樣的，有哪些空閑資源不是太清楚。甚至有些資源脫離了系統的管理，成為僵屍資源。這樣造成了大量可用資源的閑置和浪費。
（2）申請和使用不一緻
例如，營銷或者宣傳活動，申請幾百台資源執行個體，由于業務沒有預期那麼好，或者預留buffer，應對超預期壓力。最終的結果是申請和使用不一緻。活動期間，白天整體使用率偏高，晚上整體使用率偏低。例如，初期資源少，每一次申請和使用的一緻性，并沒有系統統一追蹤沉澱、統一透明化度量，業務慢慢發展了，單純申請機器擴容不一定是最佳的。軟體是否也需要進行優化更新了呢。容量評估和預測、曆史趨勢追蹤預測等系統完善度直接影響申請和使用的過程一緻性、長期一緻性。
（3）線上業務的通路低谷期間資源浪費
對于網站來說，通路量是呈現成曲線分布的，有高峰有低谷。在通路高峰的時候資源使用率比較高，在通路低谷的時候，則資源比較閑置，進而造成大量資源的浪費
（4）故障修複
機器的磁盤、記憶體條、網卡，随時都會壞掉，統計機率大約是萬分之三，一旦壞掉了，進入維修流程。1萬台規模，每天來個3、5台，一個禮拜也就20多台，再花個1個禮拜慢慢修複。修複了，回歸可用資源池又是一段時間。這種浪費是隐形的，很零碎。一年下來累計的不可用工作小時非常大。故障自動識别、自動腳本處理、故障預警等直接影響效率、準确率。
（5）可達效率
在it軟體中，基本上沒有解決不了的問題。系統分層、功能弱化總是能夠把問題的影響或者問題的複雜度降到最低，最終達到服務可上線的目标。系統之間的這種分層或者功能弱化形成的依賴關系，上下遊之間的可達效率，其實也非常影響系統的整體資源使用率。例如：a上遊rt、qps非常大，a下遊b能夠處理的吞吐量大，但是rt相對增長，整體鍊路可達效率逐層降低。适當的整合能夠帶來一定的資源使用率提升。
2. 阿裡zeus介紹
zeus是一個資源排程系統，它對資料中心的伺服器資源進行統一的排程和配置設定。它的主要功能包括：
（1）對資料中心的實體資源進行了封裝，隐藏了其中的細節。對于外界來說，整個資料中心就像是一台巨大的伺服器，對外提供cpu, 記憶體，存儲，網絡等資源。應用開發者不需要關心自己的應用部署在哪台伺服器上。
（2）接收應用的資源申請請求，為應用排程配置設定資源。
（3）優化成本。通過超賣，混合部署等方法提高資源使用率，節約成本。
（4）提升系統穩定性。zeus在進行資源排程時，會監控系統的軟硬體故障，確定有故障的資源不被配置設定，對有問題的實體資源進行跟蹤處理。
3. 資源的虛拟化
zeus使用lxc容器技術對實體資源進行切分隔離，在cpu、memory、disk、network量化後的資料基礎上，按照固定或者分時共享，實作資源動态共享，整體提升實體機的資源使用率。容器技術還有其他的優勢，例如屏蔽硬體的異構性，帶來面向api的資源配置設定和資料沉澱，進而為資源預測提供了規範、統一的資料。另外，容器技術是雲時代的加速器，以docker容器為代表的容器技術極大的友善了應用運維管理。當然容器技術從某種角度看，也有一些不足，不能應用在所有場景當中、難以解決依賴關系問題、較差的隔離性、潛在的蔓延問題、缺乏工具。
容器技術把硬體等計算、存儲、傳輸資源進行了無狀态性、相對透明的共享。容器内的具體任務以及容器的生命周期等管理，交給了上層業務進行管理、運維。
從任務實作的語言來看，一類是編譯型語言（c、c++、golang）實作的服務，一類是解釋型語言（java、php、javascript）。對于前者，程序啟動時并不需要一次性hold住固定大記憶體，對于後者特别是java，在程序啟動時候，配置固定記憶體開銷。兩種不同類型語言，使得實體機記憶體資源的動态共享模型有所不同，而cgroup實作的cpu set或者cpu子系統，可以動态共享cpu。磁盤io、網絡io通過隊列、聚合等也可以執行“限流”。另外，在單jvm程序中，合并部署多個應用，或者單jvm程序中，通過租用的方式，啟動多個服務，共享同一個jvm程序。
從資源生命周期看，長期租用、短期租用、不定時租用。不定時租用對應的往往是分時共享，而長期租用多半是固定配額共享或者專有共享。資源在時間、粒度、上下文環境一緻、業務類型上進行平衡。
不論哪種角度看共享，隻要有共享，就必須保障基礎環境的一緻性，不能因為共享者的環境變更導緻其他服務受影響。實時環境巡檢也就必不可少。
在一個大的生态性質的資源排程管理系統中，上面這些往往同時存在不同的業務叢集中。在一個業務叢集中、抽象出一套綜合的政策是很難滿足多場景需求的。不同業務叢集，在底層的硬體抽象、運維監控管理工具是可以統一的。資源共享的粒度、時機，可以多樣化。
4. 技術架構
zeus主要采取分布式二層架構模式，配置設定政策空閑優先，融合業務相親相近、負載錯峰、業務穩定性等多種限制條件，基于超賣的資源共享。排程并發上，選擇資源是全局排序，采取的程式設計語言是golang。容器服務的對象集中在線上service。線上離線混部部分，采取分時共享資源。通過周邊多個系統的協調，為公司每年節約大量成本，并且所使用的政策是常态化的。也有一些一次性的政策，針對11大促特殊場景的需求。
zeus從穩定性，資源使用率，運維自動化這三個方面來考慮排程的問題。實時監控基礎設施層的故障，并進行自動化處理，對上層應用屏蔽掉故障，進而提升系統的穩定性。通過多種排程政策，以及混合部署等方案提升資源使用率。通過提升排程的成功率，提供多種資料分析工具和資料視圖提升運維自動化程度。
架構圖如下
5. 資源使用率
5.1 超賣
應用在申請的資源的時候，往往會申請比他實際使用更多的資源。也就是說他申請的資源，在實際使用中，他是用不了這麼多資源的。這樣就形成了資源的浪費。我們内部通過超賣來解決這個問題。
超賣帶來的挑戰就是，超賣多少比較合适。如果超賣多了，會引起資源競争，導緻系統的不穩定。如果超賣少了，會導緻資源的浪費。我們需要找到一個平衡點，既不會影響系統的穩定性，也不會有很多的資源浪費。解決方案就是實行動态的超賣系數。先設定一個比較低的超賣系數，然後在系統運作的過程中，采集分析資源使用率情況，根據資源使用率的實際情況調高或者調低超賣系數。
5.2.混合部署
離線任務（jobs或者短周期任務）、線上任務（service或者長周期任務）通過合并部署來共享主控端資源。一種是實時錯峰共享資源，當排程系統發現目前線上任務的資源使用率比較低的時候，把離線任務排程上來運作，進而提高資源的使用率。但要確定線上任務優先搶占資源，如果發生離線任務和線上任務争搶資源的情況，要殺掉離線任務，把資源讓給線上任務。一種是固定配額來共享，service和jobs固定一定的資源，然後根據service空閑周期，jobs加大資源計算，動态調整cpu資源，假設記憶體、io都不是瓶頸，也就是部分的調整資源給jobs。或者不關注service空閑，在jobs固定配額内自由送出jobs計算。這種時間視窗越短，對任務切換要求能力更高，需要資源實時預測模型。例如 borg系統，針對程序最近時刻記憶體開銷進行實時調整。這對c、c++是有益處的，而對java就很難快速實施了，因為需要改jvm參數，進而jvm需要重新開機，然後是業務代碼重新開機。一種是分時獨占傳遞，在service空閑周期内，service停止服務，完整的将資源空閑出來給jobs使用。
5.3.減少資源碎片
在資源配置設定的時候，有兩種方式，一種是湊整配置設定，一種是打散配置設定。湊整配置設定就是盡量将一台主控端配置設定滿，這台主控端配置設定滿了以後，再去配置設定到别的主控端。這種配置設定方式的好處是資源碎片比較少，資源使用率比較高，但容易造成資源競争，系統不穩定。打散配置設定就是每次配置設定的時候找到空閑資源最多的主控端進行配置設定，這種配置設定方式的好處是各個主控端的負載比較均衡，但是會造成較多的資源碎片。zeus的處理方法是在這兩種方式之間找到一個平衡點，同時考慮湊整和負載均衡的問題，既要減少資源的碎片，也要考慮負載的适當均衡。
6. 穩定性
6.1. 故障處理
zeus會實時監控基礎設施層的各種軟硬體故障。提前發現大量軟硬體或作業系統故障的主控端，并标記為unavailable，線下定期處理。定期處理并回收失聯及load過高的主控端（數10台），成本回收并提高應用運作穩定性。提供黑名單機制，能快速屏蔽故障機和測試機，提高使用者操作效率。能提前發現ip沖突等網絡問題，并定期解決。
6.2. 穩定性排程政策
通過如下圖所示的各種排程政策來確定系統的穩定性。
6.2. 大促穩定性
在類似雙11這種大型促銷的活動中，由于負載超出平時數倍，會出現各種資源競争異常的情況。zeus通過對應用部署的自動洗牌，定點遷移，容器核心的調整等方式確定大促的穩定運作，不出現資源競争的問題。
7. 運維自動化
zeus能夠自動化的處理各種軟硬體故障，大大降低人工幹預的程度，進而提高了運維自動化程度。zeus大大提升了應用擴容的成功率，為彈性伸縮的自動化運作也提供了可靠的保證。
zeus還提供了多元度的運維工具，可以讓運維人員輕松的對資源進行控制和管理，提升了運維自動化程度。
阿裡中間件技術部是集團生态系統的技術基石，為淘寶、天貓、聚劃算、b2b、ae、淘寶旅行等業務群提供可靠、高效、易擴充的技術基礎服務
我們的使命：做分布式架構基礎設施，建設支撐百萬筆交易的分布式架構能力，建設支撐百萬台伺服器和超萬個系統的服務能力
我們的願景：打造世界一流的中間件産品，打造世界一流的高可用架構基礎設施，打造世界一流的企業級網際網路架構平台
歡迎加入我們的團隊，請聯系： shutong.dy[at]alibaba-inc.com 叔同
阿裡中間件技術部落格，請通路： http://jm.taobao.org/
關注了解更多技術内容：
附參考文獻
[1]http://news.oneapm.com/cloud-oneapm/
[2]http://2016.qconbeijing.com/presentation/2878
[3]http://www.linuxjournal.com/content/containers%e2%80%94not-virtual-machines%e2%80%94are-future-cloud]
[4]http://www.innoarchitech.com/in-depth-look-container-technology-caas-next-big-thing-tech/
[5]http://news.oneapm.com/cloud-oneapm/
[6]http://searchservervirtualization.techtarget.com/feature/five-cons-of-container-technology
[7] abhishek vermay, luis pedrosaz,madhukar korupolu, david oppenheimer, eric tune, john wilkes. large-scalecluster management at google with borg
[8]http://ju.outofmemory.cn/entry/21397
[9]http://www.cngulu.com/2870.html [10]http://www.umbrant.com/blog/2015/mesos_omega_borg_survey.html