servicemodejob（又名：onlinejob）是fuxi提供的一套準實時計算架構，通過毫秒級的排程開銷和網絡shuffle模式為小job提供更高的性能。目前odps對内生産叢集約1/3的job通過servicemodejob進行處理，對其中小job比較多的叢集，這個占比會提高到70%。
由于同一套servicemode服務會有多個project的job共用。需要對各個project的job進行資源隔離和彈性排程，servicemode提供了一套面向多租戶（quota group）的完整解決方案。
servicemodejob多租戶功能需要解決以下幾個使用者場景：
不同project作業之間的資源隔離和分組計費功能
在不同時段，各個project對servicemode服務的使用需求不同，需要提供分時quota的功能
servicemode服務的worker數可能會預先指定，構成一個sharedworkerpool，各個quota組的配置情況需要與worker數保持對應。
根據目前服務的剩餘資源和各quota組的使用情況，對各組job進行彈性排程，并支援配置基線作業優先級，保證生産基線job。
鑒于servicemode服務all-or-nothing的排程政策，在quota組作業排程過程中需要盡可能減小資源排程碎片，提高資源使用率。
針對上述的幾個使用者場景，我們逐一對功能點進行展開。
每個租戶根據自己的需要，配置相應的quota group。一個quota group包含｛maxquota,minquota｝兩個配置。maxquota表示這個組最大能夠持有的資源，minquota表示這個組最低期望獲得的資源。由于各租戶在不同時段對servicemode的使用需求不同，是以租戶的配置是随時段改變的。
各租戶的配置資訊将組合成一張出資表，servicemode服務将根據出資表中的各組設定進行job排程和資源配置設定。一個典型的出資表如下所示：
整個出資表是一個多級map結構。第一級的key是時段，“0-9”表示0點到9點的配置，"default"表示預設配置。第二級的key是各個quotagroup的名字。最後是各個組在不同時段的配置。"groupid‘是quotagroup的辨別id，用于和fuximaster角色同步校驗quotagroup的配置。送出到servicemode上的job，隻有所屬的group在該時段有對應的出資才會得到排程。如例子中的group3僅在"0-9"時段有出資，是以在其他時段group3的作業不會得到排程。
一個組的minquota配置的越大，排程過程中越容易拿到資源；maxquota配置的越大，在空閑資源比較多時排程彈性會越大。在排程過程中，會保證每個組minquota的資源需求和maxquota的彈性收縮。具體的排程算法将在後續section進一步展開。
線上叢集在servicemode服務打開quota模式以後，可以根據每個quotagroup的usedquota情況進行分組的計費。如下圖所示：
線上叢集的servicemode服務worker數目一般都進行了預先指定。這也是一個分時段的配置，我們稱之為workerspans配置，例如下面的配置表示0-9點的worker數是15000個（workerspansnum=15000workerspansnum=15000），其他時段是5000個。
出資表中每個時段的totalminquota=∑nn=1(minquota)totalminquota=∑n=1n(minquota)，在設定時必須保證workerspansnum>=totalminquotaworkerspansnum>=totalminquota，而workerspansnum−totalminquotaworkerspansnum−totalminquota即是該時段的sharedworkerpool。這批sharedworker将在排程過程中作為額外的彈性資源配置設定給需要的quotagroup，是以workerspansnum<=totalmaxquota=∑nn=1(maxquota)workerspansnum<=totalmaxquota=∑n=1n(maxquota)。
在實際的場景裡，sharedworkerpool是一個動态grow/shrink的池子。比如大部分組的資源請求都很少，隻有一個組的資源請求>minquota且<=maxquota，這個時候所有的空閑資源都可以認為是sharedworkerpool。
每個quota group實際使用的資源稱為usedquota，根據它和maxquota，minquota的關系，會有以下幾種組狀态。
當一個組的狀态處于normal時，系統會優先對該組進行排程。如果目前沒有來自于normal組的請求，會排程處于overused狀态的組job。而對于drawback組，系統不會響應該組的任何資源請求，直到該組的的job進入終态釋放資源後，組狀态遷移回overused或normal，才會重新開始排程。
每個quota group在排程過程中會對應一個排程隊列，每個排程隊列内部會基于組狀态，作業優先級和送出時間等規則進行排序（排序的規則後面一節會具體展開）。排程規則的僞代碼如下：
無論是quota group組内的排序還是挑選topjob都依賴在上文中提到的排序規則。排序規則首先應該考慮的是作業的優先級。但在作業優先級相同的情況下，由于servicemode系統的all-or-nothing排程特性，如果僅僅考慮送出時間可能會産生比較大的排程碎片，使一些規模比較小的job出現等資源逾時的現象（等資源時間超過10秒鐘）。
是以，我們結合每個job的規模和送出的時間，提出了submitwindow的方法來解決這一問題。根據每個job送出的時間，以5秒（可配參數）為一個時間間隔，将job劃分到不同的submitwindow中。submitwindow靠前的job會優先被排程，而對于submitwindow相同的job，job的request資源數目越少的排程優先級越高。
目前，servicemode多租戶功能已經上線了多個生産叢集。從實際的上線效果看，多租戶功能達到了資源隔離和分組計費等重要作用。我們統計上線前後一個月時間内servicemode服務上作業的“等資源逾時次數”（即等待資源的時間超過10秒鐘），如下圖。資料顯示quota有助于保障各個租戶能更及時地拿到資源，11日更新後等資源逾時次數大幅下降，從更新前平均2363次下降到1636次，下降幅度31%。從等資源逾時job/總送出job數的占比情況分析，也能得出這一結論。
藍色線：等資源逾時failed的job數目
紅色線：等資源逾時failed的job數/總送出job數 占比值
歡迎加入“數加·maxcompute購買咨詢”釘釘群（群号： 11782920）進行咨詢，群二維碼如下：