面向容器技術資源調度關鍵技術對比

資源分配理念看已有調度器

在資源調度器中，資源分配理念：拍賣、預算或搶佔，每每是混合運用。資源分配理念，折射出了資源調度器所在的生態系統或者說周邊配合系統的成熟度、運行習慣。例如，Google從最先的廣告拍賣機制起，拍賣的理念在Google內部就造成了一種經驗、選擇的愛好或者內部的默契，那麼資源競拍被分配出來的結果，你們很容易達成一致、理解。而國內企業，每每是預算驅動，周邊系統的運行習慣，更趨向預算、採購，誰預算誰使用。這種環境下，資源被誰使用基本能夠預見，成本也是比較容易找到歸屬者。在拍賣機制下資源搶佔，初始分配是不大會發生，只有在運行時發生資源不夠用的時候出現，低優先級的任務被Kill。在預算機制下，資源分配初期、運行時過程當中，都會發生搶佔。不一樣哪一種分配背後共同追求的資源流動性是一致的。拍賣的另一種好處是便於資源流動起來，不只是資源利用率提高，更是資源投入產出比的最大化。而預算每每是一次性的，重點業務資源優先保障，使得適應性、靈活性、激勵業務效率提高變得不如拍賣。

 

不一樣策略落地在架構、數據、API層面有着很是多的共同之處。從中不難發現Borg是始祖，後來的Mesos、Omega、Kubernetes、Zeus等都延續着Borg的某些重要特徵，而又隨技術發展，引入新的特徵。針對每一個系統的具體分析，能夠參照Google、Baidu上經過關鍵詞查詢出來的相關文章或者各系統發表過的論文及官方文檔[1,2,3,4,5,6,7]。

 

1.1架構層面

Borg

調度器架構圖如圖1所示[2]，是Google建造的一個主控制核心，管理公司全部的數據庫。兩級優先級：服務性的高優先級和批處理的低優先級。兩階段調度：找到可行的節點，而後爲最終放置對這些節點評分。

圖1 Borg架構圖

 

Borglet向Master彙報狀態，從而master確認borglet是否存活，以及是否須要執行Borglet上的任務遷移等操做。任務、資源的狀態數據更新是週期性的，而不是變化通知機制。

 

Job使用BCL來描述，經過RPC命令tool提交到Borg master。Borg大量的調度任務屬於Jobs，可是集羣70%左右的CPU是給service的。

 

Borg 一層框架，在框架上跑Schedule。框架是Borglet和BorgMaster之間進行狀態通訊，確保資源存活性、任務運行時數據收集，同時PAXOS協議，確保多master數據一致性，支持併發和容災。而Schedule與BorgMaster進行數據讀寫，實現資源的分配和回收管理等。

 

Mesos

Twitter研發的超級網絡系統，Mesos的出現比YARN早,引入兩級調度的理念。兩級調度經過一個名爲資源邀約的新API發起，邀約是有時間限制的，激勵應用程序去實現快速地調度。Mesos[3]裏面並無拍賣的影子，更注重公平性，容許短任務預留一些資源。時間期限就是資源的共享的生命週期。在Mesos中，資源邀約是悲觀的或獨佔的。若是資源已經提供給一個應用程序，一樣的資源將不能提供給另外一個應用程序，直到邀約超時。

 

Borg和Mesos並不僅是能讓他們的服務器羣智能化處理他們的數據，他們還讓管理集羣就像操做一臺機器同樣處理全部的數據[7]。

 

Omega

重點在介紹基於狀態的資源管理組件，Omega[4]的資源管理器基本上，只是一個記錄每一個節點狀態的關係數據庫，使用不一樣類型的樂觀併發控制解決衝突。這樣的好處是大大增長了調度器的性能（徹底並行）和更好的利用率。

Omega採起多版本控制的、樂觀鎖機制在遇到偶爾的資源衝突時候。全部資源狀態存儲在基於PAXOS協議實現的事物系統中，外部調度器訪問並執行資源調度。

 

Kubernetes

做爲Docker生態圈中重要一員，由Google開源，整個設計重點之一在於方便分佈式複雜應用的部署和管理[5,6]。Kubernetes吸取了Borg使用過程當中大量的實踐經驗，固然整個系統由於涵蓋的功能較多，延續Borg完備、複雜性，相對Mesos等稍微簡單些。Kubernetes面向雲端，須要考慮的功能點很是多。例如網絡、負載均衡、資源管理、高可用、鏡像更新、存儲、安全、監控等。Kubernetes架構如圖2所示。

圖2 Kubernetes架構圖

 

總結：主動、定時彙報的框架，仍是變動通知的框架比較適合呢？狀態基於PAXOS協議分佈式事務一致性，仍是集中數據庫存儲？基於實踐的成本、簡單性、階段目標出發，變動通知和數據庫能夠精簡系統、快速搭建原型。若是要應對百萬級服務器，那麼PAXOS協議、定時彙報應該就是標配的技術方案了。通知模式，消息重發（發的頻率、次數）、消息處理（髒數據、臨界數據）、數據補償等須要仔細設計，避免時不時的消息數據錯誤致使資源使用不一致，引起後續解救。PAXOS協議腦裂是一個潛在的風險，可是，相對通知模式仍是顯得優雅和透明些。

 

兩級調度：第一級選擇機器（也就是業務編排），第二級分配容器資源。或者第一級選資源，第二級業務編排組織。這個過程，局部最優能夠加速資源調度性能，全局最優能夠獲取最佳的資源位。具體場景具體選擇，而且均可以做爲參數傳入調度器。

 

兩種或多種優先級：高優先級、低優先級，分別對應在線服務、監控服務、運維服務，離線短週期Jobs、批量Jobs等。業務優先級的定義和變動，須要業務層面全局的評估和系統自動化更新，並及時反饋到調度器中。業務方都趨向把本身的業務定位高優先級。肯定不可搶佔業務。

 

併發支持的程度和粒度，面向鏈路也就是隊列，仍是面向資源狀態。每次申請資源全局最優仍是局部最優，一旦發生衝突，樂觀鎖仍是悲觀鎖。實踐經驗，先解決業務需求，求得生存，而後優化性能。

 

在整個架構以外，模擬器也是很是重要的子系統。尤爲是資源調度器這種基礎的服務系統，資源一旦分配錯誤或者不可用，形成的影響很是大。整個結構友好的支持模擬數據進行算法驗證必不可少。老是假設，容器技術、生態的其餘產品都是可信賴、高可用、跨語言API服務的。

 

1.2數據層面

Borg

在Google已經運行了10多年，是一個效率極高的系統。典型的Borgmaster使用10至14個內核和50GB內存，數據主要集中在內存。1分鐘啓停1萬個task進程。99%的Web UI響應時間小於1s，95%的polling borglet時間小於10s。針對成千上萬節點，每分鐘調度的速率爲10K任務。典型調度時間是25秒左右（這依賴於具體節點的本地化。下載二進制佔這個時長的80％，Torrent和樹協議用於分發二進制文件）。單個cell內部98%機器都是混跑(prod/non-prod, long-running service/batch jobs)，整個Borg系統中83%的機器是混跑。意味着Google資源共享不是簡單的固定配額共享，又或者整機交付的共享，而是實時動態的共享。

 

在混部CPI方面，增長做業會致使其餘做業進程CPI增長0.3%（CPI越大表示程序執行越慢），機器CPU使用率每增長10%會致使做業進程CPI增長2%。混跑集羣平均CPI 1.58，專用集羣1.53。另外Borglet的CPI：混跑1.43，專用1.20。結論：CPI差異不大，所以混跑並不會顯著的下降程序運行時間！

 

資源利用率主要的度量指標是單元壓縮。也就是一個業務單元使用的資源最小化程度。

 

一個典型的cell中，prod做業調度佔70% CPU，55%Memory，實際使用佔60% CPU，85% Memory。經過Borglet的週期性、實時計算，調整資源實例的配額，從而進行資源壓縮。

 

配置或者Jobs調度參數等都以JSON或者YAML格式實現。

 

Google的效率，從Google一個PE能夠運維上萬臺服務器，可見至關先進了。

 

成本計費方面：將Job的提交、配置、具體每一個task的資源使用狀況都保存到一個數據庫中，並提交SQL查詢，供計費、debug、錯誤分析、容量規劃。

 

Mesos

更關注資源公平性，簡化了Borg的複雜性，作得至關薄，只有10K行代碼。

 

Omega

典型的集羣利用率約爲60％。秒級的調度時間是典型的。

 

Kubernetes

Google開源的Golang語言實現的、支持Docker容器的新一代資源調度器。和Borg Omega同樣，都有一個共享的持久化狀態存儲模塊，用於實現資源狀態一致性。Borg的Job Conf裏有230個參數，用戶tune代價大、易出錯，Kubernetes作了參數的自動化適應。

 

總結：數據也就是資源狀態以及調度分佈數據，持久化DB仍是Paxos協議實現的分佈式事務存儲，沒有最好，只有更好。不過，提供API查詢，特別是頁面可視化操做，都是必須的。有時候對資源分配的結果，也是須要可解釋的，這依賴數據可視化、中間過程透明化。

 

流程或者分配或者運行時或者異常故障等數據的沉澱，用於故障分析、完善周邊系統、動態修正實例配額、容量水位、容量准入。數據沉澱並分析是很是有價值的。

 

成本計算基於調度器歷史過程申請資源的使用規模和時間，仍是基於業務預算的資源，仍是最後落地的流程記錄數據，不論哪一種方式，對資源的粒度和時間片的統一界定很是重要。

 

全部對數據的操做在資源調度器層，儘可能限制在原子層面，流程或者業務數據一致性交給上層或者業務發起端控制。這樣，資源調度器層基本無狀態、原子更新，分佈式一致性就比較簡單、集中。業務需求，交給業務處理。若是業務層校驗或者其餘要求，資源不知足需求，要麼業務層自我修復，要麼業務層要向鏈路下游層層回滾，最終確保資源調度器資源申請和使用最終一致性。不然，資源數據不一致引起資源超賣或者資源提早「用完」，而實際有資源的尷尬。

 

1.3 API 層面

Borg

緩存的機器分數、每種任務類型計算一次的可行性，在作調度決策時，不要試圖全局最優。複雜的規範語言。整個master是一個API server，其餘的調度、admission管理都是做爲服務，以client訪問API server，對外提供豐富的生態工具，例如腳本、web管理頁面、控制檯命令等。經過Http 協議實現的序列API，執行容器到資源分配管理的幾乎所有操做。支持以標籤形式動態調整應用的屬性，從而影響Jobs調度策略。

 

Mesos

Mesos API[3]包括Scheduler Http、Executor Http、internal C++ API。Mesos已經開始引入更多Kubernetes的概念來支持Kubernetes API [3]。仔細的比較Mesos、Kubernetes二者的生態、開源社區發展，二者之間的競爭是明顯的。虛擬機友好化、容器類（例如Docker）友好化的API或者二次開發，成爲業界選擇的焦點。Mesos目前對計算集羣支持的比較友好，而Kubernetes對虛擬機，尤爲是雲端支持的更友好。

 

Omega

Omega 基於Borg發展起來的Google新一代系統，Omega論文並無給出詳細API說明。Omega重點在對比過去的架構和新架構的優點，API猜想基本延續了Borg的相關功能。當對比討論Omega的時候，Mesos已經開源，許多概念已經在Mesos中實現了。當討論Kubernetes的時候，天然想到Mesos的衝擊力，並隨着Docker容器技術的興起、雲計算的發展，人們開始忘記Omega，彷佛只有Mesos和Kubernetes，以及共同的祖先Borg。

 

Kubernetes

Kubernetes[5]重新開始，爲不一樣調度器組件提供一套乾淨的API。Kubernetes作了參數的自動化適應。採用專門的RESTFULL API 提供服務。Kubernetes是用Golang語言寫的，它輕量、模塊化、可移植還有擴展性。

 

總結：參數JSON格式化、請求跨語言支持RESTFULL API，或者自定義一種描述語言。從面向機器到面向應用，調度器承擔的責任由薄到厚。不過，多語言、跨平臺支持能力，特別是參數和響應格式的統一是基本要求。

API完整定義了調度器的功能邊界、服務規範程度、迭代升級效率、以及和周邊生態系統的交互形式等。從已知的序列資源調度器來看，Http協議、JSON格式參數和響應，沒有理由不遵照。

全部API的交互，建議異常信息貫穿整個鏈路，而且添加各個鏈路的標識，這樣在一個生態型的資源調度體系內，進行故障排查或者調試業務過程，具備很是大的便利性。

 

資源共享看已有調度器

資源共享的過程離不開兩個維度：資源粒度、時間片。資源的效率=Σ(在線資源粒度*時間片*利用率) -Σ(資源離線粒度*時間片)。資源效率包括兩部分，在線部分和離線部分，離線部分主要是機器故障到恢復的過程，優化這部分資源效率，提高服務器在線率。軟硬件故障通用措施有：故障預警、故障檢測、故障自動修復、故障自動化處理流程等。效率簡單的按照在線減去離線，只是爲了描述：減小離線的浪費，有利於整體資源效率的提高。實際計算出來的數值不必定和真實現狀相一致的含義。下面章節提到的資源共享，主要是在線資源部分。

 

不論哪一種資源共享形式都沒有好壞之分，只有合適與不合適服務的業務場景，而且最終有無實現資源的充分利用。每每是多種方式存在於一個大的系統裏面。可能針對這個場景是固定配額，另一個場景是動態配額，對於A業務是集羣獨佔，對於B業務是混合部署。

 

語言的差別也會影響共享方式。例如Java語言，對內存資源就無法作到不重啓而動態調配內存。C++語言能夠根據進程歷史內存消耗，動態地釋放內存給鄰居進程。而CPU、NETIO、DISKIO等，能夠動態的分配資源佔比。例如Borg，CPU、NETIO、DISKIO看做可壓縮資源，而Memory size、Disk Size不可壓縮資源。若是不可壓縮資源（如Mem，disk空間）緊張，Borglet當即開始殺進程，從低優先級開始直到資源不緊張。若是可壓縮資源（CPU，IO帶寬）緊張，Borglet開始約束進程的資源使用，優先保障latency-sensitive的進程（如long-running service)。若是仍然緊張，Borgmaster開始遷移走一些task進程。能夠看出，Borglet不是固定配額給service和jobs，而是動態統一控制共享。運行時CPU等資源調配在Borglet端能夠直接執行的，而不是外界主動發起、觸發BorgletAPI執行相應操做。

 

2.1固定配額：悲觀

固定配額，是指實例啓動前和運行期間，實例佔用的資源規格保持不變。或者物理機或者集羣在混部過程，對某一類型的任務分配固定的資源佔比。例如，單實例2個CPU邏輯核、4G Memory 空間、20G Disk 空間，磁盤IOPS、網絡IOPS 最大100MB/s 等。例如物理資源層面，整個資源70%給在線服務，30%給離線服務。在線部分分配多個實例或者離線部分啓動多少JOB，資源總和不超過各自的比例上限。一般固定配額主要使用場景是在線Service。在線Service類型任務每每是long time running, 服務響應時間優先。在線服務即便須要資源壓縮，每每也是實例數量層面，也就是容量水位層面進行控制，幾乎不會執行動態的實例規格調整。不過也有例外，若是經過一段時間的數據收集處理，發現實例規格縮小或者放大，資源利用率更高或者響應時間更好，那麼，會執行新的規格升級。

 

2.2動態配額：樂觀

動態配額，是指實例運行期間，CPU或Memory或NETIO等根據實時運行需求，進行動態的調配，只要所在物理機資源夠用。動態配額模型，一旦支持動態的增長，也就意味着支持動態的減小，也就是一旦資源不夠用的時候，高優先級任務繼續運行，低優先級任務逼迫釋放資源，甚至Kill進程或者服務，進行硬降級。或者中止服務的某些子功能，釋放部分資源，進行軟降級。不難發現，動態配額每每是混部場景，而且被Kill的也是離線的JOBs。這帶來另一個問題，離線JOBs管理模塊，可以及時知曉JOBs的全局狀態，並及時從新在新的位置啓動Job，確保任務的整體Job數量和計算能力。

 

前面提到，可壓縮資源能夠作到平滑伸縮，不可壓縮資源每每須要實例重啓。對於C、C++ 伸縮更方便，伸縮時間片能夠更小，而對於Java，成本相對較高，須要從新啓動JVM，伸縮時間片更大。

 

更大粒度的動態化，例如對在線service所在的實例集羣，進行批量下線，批量釋放整機資源交給離線或者其餘服務系統。時間片到了，離線任務被遷走，在線服務實例啓動。這種方式隔離比較完全，在線和離線之間幾乎沒有影響。特別是在線、離線底層基礎環境不統一的時候，能夠作到升級解耦。而對於基礎環境統一的系統，也能夠方便在線、離線各自對物理機層面的參數調整、充分挖掘物理機資源效率。

 

在一個大的資源體系內，可能A集羣是更大粒度的動態化，B集羣是小粒度的動態化。依賴周邊工具系統很是成熟，才能作到快速在線、離線環境隔離、環境上下文切換。而且調度系統可以瞬時感知並支持集羣容量變化。很好的實施大粒度變化，更依賴周邊系統工具。

 

2.3分時租約共享

時間片的選擇，不是孤立的，每每和必定的資源共享粒度緊密相關。分時租約，在Mesos裏面就是邀約方式，時間片到了，資源就強制釋放。租約的優點在於，時間片的長度已知。對於離線任務，吞吐量優先的場景，那麼能夠充分利用Jobs的運行時間，合理調配，充分進行資源的併發調度，提高吞吐量，包括錯開時間片內的峯值消耗。相似於流水線做業，讓CPU、IO、DISK合理發揮做用。

 

2.4分時隨機共享

分時隨機共享，能夠看做分時租約的通常化場景。隨機對資源粒度、時間片、上下文切換的能力要求更高。從Borg論文看，分時隨機共享，更多的是離線任務共享在線服務所在資源，資源一旦不夠用的時候，離線任務將被Kill。而在線任務壓力較低時候，IO等資源能夠向離線任務傾斜而不影響在線服務的前提下。C++這種語言實現的任務特別適合，對JVM這種，只能在CPU層面實現隨機調整。

 

不論時間片的大小、時機的選擇，都須要一個強大的容器技術來實現資源的快速隔離、敏感的資源監控系統，進行資源消耗的追蹤、預測、調配。更上一層任務管理系統，可以感知任務的存活和進度，並進行任務層面的調度。

 

2.5資源預留

資源預留，能夠減小任務被Kill掉、被遷移的次數。在資源緊張的狀況下，能夠快速從預留的資源池，快速的影響資源請求。從彈性效率看，對於批量的、針對在線服務的容量水位控制，加速一次批量的成功率，特別是大資源坑位的快速交付，資源預留也是很是好的措施。從容災的角度，不一樣機房考慮其餘機房總體不用的時候，承擔其餘機房遷移過來的流量，相應的資源預留也有必要的。

 

資源預留的客觀性需求，必然犧牲一部分資源的利用率。恰當的預留規模就顯得很是必要了。至於預留多少，沒有絕對的指標。不一樣於銀行存款準備金率，該數值直接影響資金的流動。資源預留更多的是效率、應急響應所需。

 

任務類型看已有調度器

資源調度器服務的任務類型，主要分爲Jobs、Services。Jobs的特色：短週期，也有長的運行1天甚至1個禮拜的，大部分運行週期是分鐘級別；批量提交、運行；吞吐量優先；CPU、IO密集型；優先級相對低些；失敗後能夠從新分配；函數式的過程，也就是屢次運行結果，只要輸入不變，結果也一致的。Service的特色：長週期，也有運行1天甚至1個禮拜的；活動營銷型服務；大部分運行週期是季度或者年的，提交後就一直運行；服務響應時間敏感；CPU、IO密集型都有；優先級特別高。有些基礎類型或者管控系統，有時候也做爲service任務看待，這些系統不容許被搶佔。例如，基礎存儲系統、監控運維繫統、權限風控系統等，這些沒有直接服務外面客戶，但對業務穩定性、可用性相當重要。作到任務資源不搶佔，也就是固定配額模式，帶來好處：業務之間彼此的影響相對比較小。很差地方：資源分配不合理或者突發需求更多資源的時候，資源浪費或者資源吃緊。在一個大的資源調度管理生態系統中（周邊依賴很是多的工具、平臺，而不是僅僅一個調度器就搞定），搶佔必然發生的，搶佔的對象、範圍、頻率、時機，在不一樣的場景下，以不一樣策略應對。

 

3.1分配時搶佔

分配時搶佔，例如在不一樣優先級別任務共同部署在一個集羣的時候，當出現更高優先級任務實例須要資源時候，空閒資源又不足以應付，此時，低優先級任務實例將被Kill，釋放資源。或者直接疊加到低優先級任務所在資源位置上。分配時搶佔每每是約定的規則下執行的。爲了最小化應用之間的影響，搶佔儘可能不集中在一個點或者一個應用或者一個業務層面，風險分散式折中。任務能被Kill，默認要求被kill應用是無狀態的，這樣資源夠用的時候，能夠自動恢復。另外搶佔以後，即便從資源配額角度看，實例資源的訴求都知足，從業務穩定性、綜合負載均衡看，熱點儘可能避開。在高負荷運做的集羣，添加資源或者釋放資源都須要綜合評估。

 

3.2運行時搶佔

運行時搶佔，多半犧牲離線JOBs，若是離線JOBs沒有，那麼偶爾會犧牲在線低優先級Service。運行時搶佔，對容器技術要求比較高，須要快速資源釋放、從新分配。在計算密集型場景下，CPU動態調配確實帶來很是好的效果。若是整個宿主機資源已經吃緊，再怎麼調配CPU，也不能緩解壓力。在線Service內存、磁盤空間大小每每不是瓶頸，磁盤IO、網絡帶寬的使用，能夠進行軟降級。

 

對於被系統中斷等使用的CPU核，儘可能不要使用這些計算資源服務應用。畢竟和系統中斷搶資源，很是不明智的。

 

基於Linux cgroup 實現的CPU共享：CPU子系統和CPU set兩種方式，針對運行時的搶佔效果的好壞，須要經過真實場景觀察肯定。由於業務特徵對效果有必定影響。業務對時間的敏感性，磁盤IO、網絡IO的隊列技術，就須要慎重使用。

 

資源利用率和預測運用

資源利用率在第2部分已經提到，與資源粒度、時間片、利用率、服務器在線率等都有關聯。這些抽象層面背後，還有那些方面須要仔細實施，以確保最終的效率、利用率的提高。下面列舉部分信息以下。

 

4.1負載預測

負載預測，預測的實時性、準確性，應用實例規格的優化、運行時動態資源的分配、全局熱點把握，都是相當重要的前置技術。

 

負載數據主要包括CPU利用率、Memory消耗、Disk消耗，磁盤IO、網絡IO，甚至DB IO等。從這些歷史數據中，多維度對應用、應用實例層面分別給出面向不一樣時間片大小的預測值，實際上是很是具備挑戰的事情。數據規模、採集的併發實時性，噪聲和突發流量甚至限流等，都對模型的響應時間、模型的準確率提出了很高的要求。由於錯誤的預測可能致使意想不到的調度影響。

 

負載預測和業務QPS、RT關聯起來，甚至和能源消耗、成本關聯起來，除了趨勢評估，還能夠幫助決策。由此對數據的協同分析，也須要專業的團隊進行跟進。[12,13,14,15,16,17]

 

4.2遷移最少

在資源調度系統甚至任何系統中，都會存在例外，存在系統規則或者模型沒法應對或者以前沒有預估到的案例。遷移最少，大型資源池調度過程當中，也是須要考量並優化的點。遷移成本，包括遷移的次數、遷移的規模、遷移的影響。

 

物理機故障不可避免，按照萬分之三的機率計算，一萬臺服務器，天天大約3臺服務器觸發硬件故障，這些硬件故障上面的實例要麼直接不工做，要麼重新建立。無狀態的，直接擴容，有狀態的涉及到數據搬遷。

 

集羣碎片整理或者負載整理，都須要對實例進行上線、下線操做。遷移的過程，其實就是服務資源「暫停」服務的過程。遷移次數、規模不得不考慮。

 

有時候就是純粹的資源替換，由於網絡或者機型或者業務須要，作到遷移最少，在資源預算或者業務規劃時候必須考量。看起來不是資源調度器的責任，可是，初期須要資源調度器的建議，從而下降二次梳理成本。

 

對於依賴性的JOBs,在業務開始時候，就應該考慮依賴關係。典型的數據搬遷、服務調用，作到同一機架或者交換機都帶來性能提高。一種遷移最少的方案參考論文[10]。

 

4.3等待最短

在微觀層面，資源調度器資源調度，特別是大規模Jobs調度，排隊以及排隊開銷客觀存在。排隊的長度和公平性，有時候很矛盾的。下降排隊時間，一方面提高業務體驗，另一方面資源分配效率更高，資源在線工做時間片更多，資源利用率也就更好。

 

各類應對等待的隊列算法，例如輪詢、帶權值、優先級，都有各自的優缺點。具體場景須要具體選擇[8,9]。

 

4.4碎片最少

碎片最少是默認的，實際選擇執行的路徑有所不一樣。空閒優先，也就是鋪開優先。另一種是飽和優先，也就是緊湊優先。在相同資源、相同碎片的時候，是優先向空閒結點部署，仍是將已有結點打飽和，沒有絕對的標準。方便大規格資源的申請，那麼打飽和比較穩當，這樣相同碎片量的狀況下，大塊資源比較多。

 

在計算碎片的時候，須要綜合評估CPU、Memory、Disk等維度，一般CPU是核心競爭資源，優先評估CPU的碎片。確保CPU關鍵資源的充分利用，CPU資源在容器或者實例層面，很容易動態調整而不須要從新實例化等。一些碎片最少的算法參考論文[11]。

 

若是實際分配過程當中，確實存在碎片沒法分配出一個資源位，那麼能夠將餘下的CPU核綁定到已知實例上。雖然CPU資源利用起來了，若是上層流量均衡調度，那麼，這種相對其餘實例多出的CPU資源，能夠提高響應時間，可是並無提高QPS，只對穩定性有幫助。

 

4.5資損最少

VM代價計算模型當中，除了資源粒度、時間片等因素外，還須要考慮資損，尤爲是電商交易類在線服務。服務器狀態異常或者故障，有時候會有形成用戶或者商家或者企業的財務損失。儘管業務架構層面會極大程度規避這種狀況的出現，實際過程當中，若是把資損最少融入常規調度策略中，那麼，一旦發生局部集羣的大面積故障，資損理論上就降到最低。在已知的資源調度器中，代價更多的集中在資源自己，也就是IAAS層考量，而把業務層的需求，例如，資損最少交給PAAS或者SAAS層解決。從最初的小型機、商用數據庫、專有集羣等，到分佈式普通機器，自研發系統，不一樣階段的技術形態和投入是不同的。整個鏈路層面，層層把控資損，其實最後落到資源調度器層面的影響相對較少。

 

另一個角度就是業務性價比，老是指望將業務收益最大、故障影響最敏感的系統，獨立部署，資源優先保障。例如廣告系統。

 

5.6快速恢復

在有限資源的系統裏面，或者高負載運做系統裏面，局部故障的影響會被放大。在大規模的資源系統裏面，每一個應用的實例規模比較大，重啓或者上下線實例，幾乎沒有絲毫影響。失敗的流量佔比幾乎能夠忽略，失敗的請求從新分配到其餘結點，對其餘結點的壓力增加也是微小的。可是，幾乎每一個結點壓力都達到閾值90%左右的話，那麼，即便是不多量的結點故障，影響也會放大。例如，秒殺或者搶購商品，實例的穩定性要求很是高。很難作到機器100%無端障，除了業務容量冗餘以外，故障快速恢復能夠減輕故障影響。

 

和資損相似，故障快速恢復落到資源調度器層面的責任或者壓力，其實很是微弱，甚至能夠忽略，除非是特殊的業務。針對故障物理機承載的實例重啓速度的分佈，進行有效的控制，能夠從微觀層面，提高故障的快速恢復能力。

 

阿里電商調度Zeus實踐

在第一部分的架構、數據、API分析總結裏面，已經把阿里的一些實踐經驗概要描述了一下。本部分從總體上對Zeus進行概要總結。

 

5.1上下游架構

阿里電商業務的複雜程度，很難用一個圖或一句話描述清楚。從資源調度的層面看，阿里的在線服務資源調度系統Zeus依賴或者配合的系統，多達十幾個。每個被依賴的系統，除了服務資源調度器以外，還服務其餘場景。下面以Zeus實際運做過程當中關聯或者依賴的視角，給出總體抽象架構示意圖，如圖3所示。

圖3阿里在線資源調度架構圖

 

Zeus向下，依託阿里自有IAAS服務，例如核心的容器技術，運維監控的底層通道系統。對上，銜接運維發佈系統、監控視圖、環境巡檢、打標系統等等。Zeus提供資源調度過程和結果的可視化數據視圖。對接成本容量管控，在資源申請、回收、成本覈算等整個資源生命週期，提供相關數據服務。

 

經過模擬演練，配合流量壓測、追蹤調度系統，提早發現不合理部署並自動調配。作到大促高峯流量場景下，業務的高可用，低成本開銷。

 

5.2調度策略

基於預算的統籌安排，這意味着資源存在某種程度的「邊界」：就是「預算」。超出預算就變得很被動。爲了提高資源利用率，負載均衡，須要跨資源邊界的共享，以雙贏合做方式來推進。而Google Borg的競拍模式，從一開始資源是面向全部組織業務、相對公平的。兩種模式選擇都不是憑空的，都是伴隨企業自身技術發展、貼合各自實際業務特徵產生的。沒有優劣，只有合適與否。

 

Zesu支持在線、離線混合部署。一種，在離線任務固定配額，在單機或者集羣層面固定配額，此時，在離線之間的資源爭搶是能夠預知的，或者說資源的邊界不打破，理論上就不存在資源的干擾。這種模式，有實踐過。另一種，在線離線任務的運行時資源搶佔，當在線任務資源緊張，單節點離線任務就須要釋放CPU或者磁盤IO或者網絡帶寬資源。

 

搶佔發生的時刻，除了初始分配、也包括運行時時刻。例如，在線和離線之間搶佔，甚至包括在線任務之間的資源搶佔。

 

另一種搶佔，或者說資源傾斜，或者說業務管理需求吧。在線任務又細分中間件基礎服務、運維監控基礎服務、安全風險控制等業務模塊，這些重要的業務資源優先保障，不被搶佔。

 

對待碎片，整體上碎片最少。候選資源結點排序上，鋪開優先和緊湊優先都有。看具體資源池和對應業務的需求而定。用於特殊場景下，甚至存在運行時動態肯定資源的策略，例如秒級別響應資源服務需求。

 

故障預警、故障檢測、環境巡檢、打標、提高資源在線率、流程數據一致性等，也有相應的策略。例如：基於Golang實現的隊列，支持配置的批量更新、採集等。基於Golang 協程和Map，實現多級併發的機器選擇和計算得分排序等。

 

5.3利用率和預測

資源利用率相對阿里過去有很多提高，每一年節約成本億爲單位。相對業界，特定的資源池利用率達到甚至超過業界水平，整體打平的利用率，與業界還有一些差距。這些差距和業務場景、內部依賴配合的系統工具的成熟度、發展計劃都有關聯。

 

預測目標是某種程度把整個系統的流轉過程，數據化、模型化、自動化。預測的能力某種程度決定了資源調度系統最終能達到的理想狀態。在阿里內部，針對在線或者離線任務的負載預測、容量水位預測、全鏈路模型等，都有相關的團隊在負責，並經歷了幾屆雙11的考驗，愈來愈穩定、高效、準確。具體預測模型、算法上面，延續着業界已公開的論文，並結合阿里業務場景，作適合業務發展須要裁剪實踐。

 

5.4雲端調度

隨着雲計算的發展，電商混合雲部署架構的成熟。幾乎全部企業將來都面臨雲端調度的問題。在雲端的資源調度、混合雲調度，對系統的協同能力、快速上下線能力提出了更高的要求。2015年雙11，充分利用了阿里雲的公共雲計算資源來分擔一部分流量，阿里、淘寶、支付寶在今年雙11作到了這一點，而且扛住了嚴酷的流量考驗。實現了交易上雲的關鍵技術的突破。將來，在雲端的交易更加廣泛，雲端資源調度的技術、經驗更加豐富。在技術、經驗完善後，電商會分享給業界，讓你們享受雲帶來的低成本、便捷、高效。

 

來源：http://www.youruncloud.com/docker/1_73.html