本文以資源配置設定理念，拍賣、預算、搶占出發，引出borg、omega、mesos、kubernetes架構、資料、api的特點比較。然後梳理資源共享各種不同共享形式的内容，接着對比任務類型，最後回到資源使用率和基于資料預測角度，看相關系統是如何運用和實作各自場景目标。最後給出阿裡巴巴電商線上服務資源排程器zeus關鍵技術内容。
進入這個領域的門檻不在具體某個技術，而業務場景和技術選型的映射比對，特别是周邊系統的完善程度，決定了如何選擇方案、如何制定落地計劃。本文不是為了全面分析某個排程器，也不是全面對比某個關鍵點在不同排程器之間特色，而是基于筆者的了解，闡述在一個新場景下，如何設計或者完善一個資源排程器，從已有排程器系統吸取架構或子產品經驗，最低成本實作貼合自身業務場景的資源排程器。例如吸取排程器二層架構模式、資料集中管理方式、統一restfull api、資源分時共享政策、在離線任務類型抽象等。
1 從資源配置設定理念來看已有排程器
在資源排程器中，資源配置設定理念：拍賣、預算或搶占，往往是混合運用。資源配置設定理念，折射出了資源排程器所在的生态系統或者說周邊配合系統的成熟度、運作習慣。例如，google從最早的廣告拍賣機制起，拍賣的理念在google内部就形成了一種經驗，那麼資源競拍被配置設定出來的結果，大家很容易達成一緻。而國内企業，往往是預算驅動，更趨向預算、采購，誰預算誰使用。這種環境下，資源被誰使用基本可以預見，成本也是比較容易找到歸屬者。在拍賣機制下資源搶占，初始配置設定是不大會發生，隻有在運作時發生資源不夠用的時候出現，低優先級的任務被kill。在預算機制下，資源配置設定初期、運作時過程中，都會發生搶占。拍賣的另外一種好處是便于資源流動起來，不僅是資源使用率提升，更是資源投入産出比的最大化。而預算往往是一次性的，重點業務資源優先保障，使得适應性、靈活性、激勵業務效率提升變得不如拍賣。
不同政策落地在架構、資料、api層面有着非常多的共同之處。從中不難發現borg是始祖，後來的mesos、omega、kubernetes、zeus等都延續着borg的某些重要特征，而又随技術發展，引入新的特征。針對每個系統的具體分析，可以參照各系統發表過的論文及官方文檔[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 資料層面
在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、錯誤分析、容量規劃。
更關注資源公平性，簡化了borg的複雜性，做得相當薄，隻有10k行代碼。
典型的叢集使用率約為60％。秒級的排程時間是典型的。
google開源的golang語言實作的、支援docker容器的新一代資源排程器。和borg omega一樣，都有一個共享的持久化狀态存儲子產品，用于實作資源狀态一緻性。borg的job conf裡有230個參數，使用者tune代價大、易出錯，kubernetes做了參數的自動化适應。
總結：資料也就是資源狀态以及排程分布資料，持久化db還是paxos協定實作的分布式事務存儲，沒有最好，隻有更好。不過，提供api查詢，特别是頁面可視化操作，都是必須的。有時候對資源配置設定的結果，也是需要可解釋的，這依賴資料可視化、中間過程透明化。
流程或者配置設定或者運作時或者異常故障等資料的沉澱，用于故障分析、完善周邊系統、動态修正執行個體配額、容量水位、容量準入。資料沉澱并分析是非常有價值的。
成本計算基于排程器曆史過程申請資源的使用規模和時間，還是基于業務預算的資源，還是最後落地的流程記錄資料，不論哪種方式，對資源的粒度和時間片的統一界定非常重要。
所有對資料的操作在資源排程器層，盡量限制在原子層面，流程或者業務資料一緻性交給上層或者業務發起端控制。這樣，資源排程器層基本無狀态、原子更新，分布式一緻性就比較簡單、集中。業務需求，交給業務處理。如果業務層校驗或者其他要求，資源不滿足需求，要麼業務層自我修複，要麼業務層要向鍊路下遊層層復原，最終確定資源排程器資源申請和使用最終一緻性。否則，資源資料不一緻引發資源超賣或者資源提前“用完”，而實際有資源的尴尬。
1.3 api 層面
緩存的機器分數、每種任務類型計算一次的可行性，在做排程決策時，不要試圖全局最優。複雜的規範語言。整個master是一個api server，其他的排程、admission管理都是作為服務，以client通路api server，對外提供豐富的生态工具，例如腳本、web管理頁面、控制台指令等。通過http 協定實作的序列api，執行容器到資源配置設定管理的幾乎全部操作。支援以标簽形式動态調整應用的屬性，進而影響jobs排程政策。
mesos api[3]包括schedulerhttp、executor http、internal c++ api。mesos已經開始引入更多kubernetes的概念來支援kubernetes api [3]。仔細的比較mesos、kubernetes兩者的生态、開源社群發展，兩者之間的競争是明顯的。虛拟機友好化、容器類（例如docker）友好化的api或者二次開發，成為業界選擇的焦點。mesos目前對計算叢集支援的比較友好，而kubernetes對虛拟機，尤其是雲端支援的更友好。
omega 基于borg發展起來的google新一代系統，omega論文并沒有給出詳細api說明。omega重點在對比過去的架構和新架構的優勢，api猜測基本延續了borg的相關功能。當對比讨論omega的時候，mesos已經開源，許多概念已經在mesos中實作了。當讨論kubernetes的時候，自然想到mesos的沖擊力，并随着docker容器技術的興起、雲計算的發展，人們開始忘記omega，似乎隻有mesos和kubernetes，以及共同的祖先borg。
kubernetes[5]從新開始，為不同排程器元件提供一套幹淨的api。kubernetes做了參數的自動化适應。采用專門的restfull api 提供服務。kubernetes是用golang語言寫的，它輕量、子產品化、可移植還有擴充性。
總結：參數json格式化、請求跨語言支援restfullapi，或者自定義一種描述語言。從面向機器到面向應用，排程器承擔的責任由薄到厚。不過，多語言、跨平台支援能力，特别是參數和響應格式的統一是基本要求。
api完整定義了排程器的功能邊界、服務規範程度、疊代更新效率、以及和周邊生态系統的互動形式等。從已知的序列資源排程器來看，http協定、json格式參數和響應，沒有理由不遵守。
所有api的互動，建議異常資訊貫穿整個鍊路，并且添加各個鍊路的辨別，這樣在一個生态型的資源排程體系内，進行故障排查或者調試業務過程，具有非常大的便利性。
2 從資源共享來看已有排程器
資源共享的過程離不開兩個次元：資源粒度、時間片。資源的效率=Σ(線上資源粒度時間片使用率) -Σ(資源離線粒度*時間片)。資源效率包括兩部分，線上部分和離線部分，離線部分主要是機器故障到恢複的過程，優化這部分資源效率，提升伺服器線上率。軟硬體故障通用措施有：故障預警、故障檢測、故障自動修複、故障自動化處理流程等。效率簡單的按照線上減去離線，隻是為了描述：減少離線的浪費，有利于總體資源效率的提升。實際計算出來的數值不一定和真實作狀相一緻的含義。下面章節提到的資源共享，主要是線上資源部分。
不論哪種資源共享形式都沒有好壞之分，隻有合适與不合适服務的業務場景，并且最終有無實作資源的充分利用。往往是多種方式存在于一個大的系統裡面。可能針對這個場景是固定配額，另外一個場景是動态配額，對于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掉、被遷移的次數。在資源緊張的情況下，可以快速從預留的資源池，快速的影響資源請求。從彈性效率看，對于批量的、針對線上服務的容量水位控制，加速一次批量的成功率，特别是大資源坑位的快速傳遞，資源預留也是非常好的措施。從容災的角度，不同機房考慮其他機房整體不用的時候，承擔其他機房遷移過來的流量，相應的資源預留也有必要的。
資源預留的客觀性需求，必然犧牲一部分資源的使用率。恰當的預留規模就顯得非常必要了。至于預留多少，沒有絕對的名額。不同于銀行存款準備金率，該數值直接影響資金的流動。資源預留更多的是效率、應急響應所需。
3 從任務類型來看已有排程器
資源排程器服務的任務類型，主要分為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核，盡量不要使用這些計算資源服務應用。畢竟和系統中斷搶資源，非常不明智的。
基于linuxcgroup 實作的cpu共享：cpu子系統和cpu set兩種方式，針對運作時的搶占效果的好壞，需要通過真實場景觀察确定。因為業務特征對效果有一定影響。業務對時間的敏感性，磁盤io、網絡io的隊列技術，就需要慎重使用。
4 資源使用率和預測運用
資源使用率在第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層解決。從最初的小型機、商用資料庫、專有叢集等，到分布式普通機器，自研發系統，不同階段的技術形态和投入是不一樣的。整個鍊路層面，層層把控資損，其實最後落到資源排程器層面的影響相對較少。
另外一個角度就是業務成本效益，總是期望将業務收益最大、故障影響最敏感的系統，獨立部署，資源優先保障。例如廣告系統。
4.6 快速恢複
在有限資源的系統裡面，或者高負載運作系統裡面，局部故障的影響會被放大。在大規模的資源系統裡面，每個應用的執行個體規模比較大，重新開機或者上下線執行個體，幾乎沒有絲毫影響。失敗的流量占比幾乎可以忽略，失敗的請求重新配置設定到其他結點，對其他結點的壓力增長也是微小的。但是，幾乎每個結點壓力都達到門檻值90%左右的話，那麼，即使是很少量的結點故障，影響也會放大。例如，秒殺或者搶購商品，執行個體的穩定性要求非常高。很難做到機器100%無故障，除了業務容量備援之外，故障快速恢複可以減輕故障影響。
和資損類似，故障快速恢複落到資源排程器層面的責任或者壓力，其實非常微弱，甚至可以忽略，除非是特殊的業務。針對故障實體機承載的執行個體重新開機速度的分布，進行有效的控制，可以從微觀層面，提升故障的快速恢複能力。
5 阿裡電商排程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做到了這一點，并且扛住了嚴酷的流量考驗。實作了交易上雲的關鍵技術的突破。未來，在雲端的交易更加普遍，雲端資源排程的技術、經驗更加豐富。在技術、經驗完善後，電商會分享給業界，讓大家享受雲帶來的低成本、便捷、高效。
<a href="https://mp.weixin.qq.com/s/eo5jadjfz4_pfkjocnwdbg">原文連結</a>