摘要： 本文主要概述阿里巴巴Zeus資源調度系統的背景和實現思路。 本文主線：問題、解決方案、依賴基礎知識、工程實踐、目標、經驗分享。立足企業真實問題、常規解決策略，引出依賴的容器技術、實踐方案，所有這些落實到工程實踐，要解決那些問題、實現哪些目標、技術大趨勢的影響。最后給出阿里巴巴的實踐經驗。本序列文章並不是突出架構上重大突破，畢竟這個領域已經發展了10多年了。而是，實踐過程中的一些細節、一些特殊場景下的特殊處理方法，作為一種新的認知素材。依賴的容器或周邊系統，都不會進行深入的分析，圍繞資源調度概括性地做一些總結和補充些細節描述。
關鍵詞：容器技術 資源調度
1. 什么是宙斯（Zeus）
宙斯是阿里巴巴開源的一款分布式Hadoop作業調度平台，支持多機器的水平擴展。Zeus是一款完全分布式的調度系統，，支持多機器的水平擴展，一台機器為一個節點，由master節點分發任務至不同的worker,實現任務的分布式調度。目前支持的任務類型主要由hive腳本和shell腳本。Zeus不僅僅可以執行獨立任務調度，還支持任務之間依賴調度。這就使得zeus完全不同於傳統的任務調度系統中，任務只能單個任務之間調度，這也是zeus的設計中一大亮點。
2. Zeus的架構設計
軟件架構設計
集群架構設計
3. Zeus核心模塊分析
宙斯核心模塊分為zeus-schedule,zeus-web,即宙斯調度層和宙斯web層，其中zeus-schedule負責的主要功能是RPC通信與任務調度，zeus-web提供一種web層的交互.后面將開始源碼解讀。
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還提供了多維度的運維工具，可以讓運維人員輕松的對資源進行控制和管理，提升了運維自動化程度。
轉載：https://blog.csdn.net/iie_libi/article/details/71597971，原文鏈接：https://blog.csdn.net/Pengjx2014/article/details/78380300
8. 參考鏈接
[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-scale cluster 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