5 月 30 日， 字節跳動技術沙龍 | 基礎架構專場 進行了在線直播。我們邀請到了字節跳動基礎架構團隊資深研發工程師邵偉、江帆和大家進行分享交流。
本次沙龍給大家分享的主題是《大規模混合部署項目在字節跳動的落地實踐》，希望這次的分享能夠帶給大家一些我們對混部的思考。
沙龍分享的內容將會圍繞以下問題來進行：
- 首先是字節跳動爲什麼想要開啓混部，它產生的背景是什麼樣的，字節內部的業務形態有什麼樣的特徵使我們能夠開啓大規模的混部？
- 我們具體做了哪些事情來支持混部的順利開啓和落地，在其中遇到哪些問題和挑戰？
- 以及，在字節內部，混部有哪些典型的應用場景，分別是爲了解決什麼問題，帶來了哪些收益等等。
爲了更好地回答這些問題，本次沙龍將分爲兩個議題，分別圍繞上層控制邏輯和底層隔離技術進行展開。
以下是字節跳動基礎架構團隊資深研發工程師邵偉的分享主題沉澱，《自動化彈性伸縮如何支持百萬級核心錯峯混部》。
演講內容大綱：
- 背景介紹
- 彈性伸縮
- 混部實踐
下面我會首先着重介紹第一個議題，也就是《自動化彈性伸縮如何支持百萬級核心錯峯混部》，而關於底層隔離技術的分享將在稍後給大家帶來。
首先了解下今天分享的大綱，在第一部分中，會對字節私有云平臺的整體現狀，和上面所託管的服務做一個簡單的介紹，在這部分中將重點回答爲什麼需要對服務開啓彈性伸縮，它跟混部間的關係是什麼。第二部分的內容主要涉及到在控制層上如何實現大規模服務彈性伸縮，以及相關的基礎組件如何才能支撐彈性伸縮的穩定性。最後，會介紹一下，我們在彈性伸縮的基礎上逐步推動大規模混部上量的過程，以及具體落地的一些場景，還有對應的演進思路。
背景介紹
字節內部的私有云平臺叫做 TCE，它底層使用 K8S 作爲編排調度的系統，目前字節內部幾乎所有無狀態服務都是以容器的形式部署和運行在 TCE 之上，這些無狀態服務主要包括典型的微服務，還有像推薦和廣告等在類的偏算法型的服務。其中，微服務對於資源的申請比較簡單，只涉及到 CPU 和 內存等，而算法類服務對穩定性要求更爲嚴格，所以對資源有很更多定製化的需求，例如內存帶寬、numa 節點的綁定等。這些無狀態服務都是以 K8S Deployment 的形式進行多實例部署和管理的，每個實例通常會以 RPC 或 HTTP 的形式對外提供訪問接口，並在上層通過 consul 或 lb 提供統一的外部訪問入口和負載均衡的能力。這些特徵使得這些無狀態服務的實例天然是可以在集羣的不同節點上進行動態遷移的，並且服務實例的資源利用情況跟流量的變化呈現正向的關係，這就爲服務副本數的動態控制和調整提供了基礎。
由於 TCE 上接管的服務數量非常衆多，所以集羣的規模也相應變得非常龐大，截止到目前爲止，TCE 已經部署在中國、新加坡、美東等三個區域，底層搭建和託管的 K8S 集羣數量超過了 40 個，總計包括約幾十萬臺服務器資源；從應用規模上來說，TCE 上部署的服務數量也超過了 4w 個，對應的 Deployment 和 Pod 總量則分別超過了 30 萬和 300 萬個。隨着業務的不斷髮展，集羣規模還在處於不斷增長的過程中。如此龐大的集羣規模帶來的問題就是資源成本的不斷攀升，所以對於管理資源的架構團隊而言，需要回答的一個核心問題就是如何才能儘可能的提高集羣整體資源利用率。
爲這個目標，我們對業務的流量特性進行了分析。首先我們觀察到在線業務的一個非常重要特性就是天級利用率具有很強的穩定性，在沒有特殊變更的情況下，在線業務每天的流量幾乎不會發生變化。從這張圖中可以看到，服務天級利用率在一週的時間維度上具有相同的波動曲線。而且通常來說，業務會傾向於申請比自己實際需要更多的資源，這樣對服務本身的好處是可以在最大程度上保證流量服務的穩定性，但是造成的問題就是，始終有部分資源是業務即使在高峯期也永遠用不上的，即圖中紅線和綠線之間的 Gap 就是一定程度上的資源浪費。
基於這一特性，我們可以採取的方式就是在合理範圍內儘可能地把圖中的綠線往下拉，具體的做法就是根據服務在過去一週中峯值利用率的最大值，動態調整服務的資源申請量，從而回收和再利用一定的冗餘資源。當然我們會在峯值利用率的基礎增加一定的 buffer 以適應服務 burst 的行爲。這個策略就是服務級別的動態超售，超售對於微服務的資源回收具有非常明顯的效果。
除此之外，我們發現在另外一些場景下仍然存在非常多資源的浪費，這就涉及到在線業務的另外一個特點，即在線業務的流量具有明顯波峯波谷的潮汐變化。舉個例子來說，幾乎所有的用戶都會在晚高峯的時段刷抖音，這樣就會導致抖音相關服務的整體流量都上漲到一個比較高的水平。而到了凌晨，因爲大家刷抖音的次數和頻率又會下降，所以此時業務訪問的流量會出現比較明顯的波谷。這種潮汐現象對頭部服務而言會非常明顯，尤其是像抖音和推薦這類服務，它們波峯波谷間利用率的差距可能達到 40% 這種水平。業務部署時，爲了使得其資源總量能夠扛過晚高峯，必須按照晚高峯的流量預估申請資源，造成當業務處於流量低谷時，很多資源被浪費掉，並且這部分資源無法通過超售的當時進行回收。面對這種情況，如果能夠通過彈性伸縮，在業務處於低谷時，通過回收業務副本數的方式來回收這部分資源，然後在業務處於峯值時，重新恢復業務的副本數，那麼我們就能夠在保證服務的 SLA 幾乎不受影響的前提下，回收大量在線低谷時段的彈性資源。
當我們通過彈性伸縮回收了在線低谷時的資源後，下一步需要做的事情就是將這部分彈性資源進行二次的分配和利用，不然集羣整體的利用率並沒有因爲服務彈性伸縮而得到本質的提升。但我們面臨的事實是，所有在線業務的低谷時段幾乎吻合，因爲凌晨的時候所有在線 app 都會面臨使用頻次減少的情況，所以無法通過擴容在線的方式喫掉這部分資源量。但是我們發現，字節內部也有很多離線的任務同樣需要資源進行調度，例如視頻轉碼和模型訓練等，而且這些任務對資源的需求相對來說沒有特定的時間約束，所以天然能夠利用閒置資源，於是我們就開啓了在離線混部出讓在線閒置的資源給離線使用。
後來我們進一步發現，因爲總體資源量的限制，部分在線服務在流量高峯期時經常由於沒有足夠的資源供給，處於常態降級的狀態，這種降級狀態對業務來說其實是有損的。如果能夠在這個時候將離線的資源通過混部的形式出讓給在線使用，那麼在線服務也能夠從混部中得到收益。更進一步來說，如果能夠在資源層面徹底打通在離線之間的壁壘，那麼我們就能夠通過更加靈活的手段來優化混部的策略，真正實現資源和調度的融合，從而從更大程度上提升在離線集羣整體的利用率，關於這一點，我們會在第二個 topic 《在高服務器利用率和毫秒級 QoS 之間需求折中》中進行更爲詳細的闡述。
下面我們可以簡單總結一下我們對於提升集羣利用率的探索，我們主要使用了三種不同的手段相互配合來提升利用率，分別是：通過超售的方式回收業務申請的冗餘資源，通過彈性伸縮回收在線業務波谷時段的冗餘資源，最後在彈性伸縮的基礎上通過通過混合部署實現在離線之間資源的靈活拆借。其中，彈性伸縮和混部的控制邏輯是第一個子議題中分享的重點，下面我會進一步分享這兩個方面的實現細節。
彈性伸縮
在介紹實現細節之前，首先需要認識下服務彈性伸縮的大致過程，整體思路比較簡單，服務 owner 可以根據服務自身特性配置資源利用率的閾值，這個閾值表徵的就是理想狀態下服務利用率應該達到的水平。當然這裏閾值的概念可以是物理的資源，例如 CPU 和 內存的使用情況，也可以是邏輯上的資源，例如服務請求的 QPS 等。理論上任何能夠反應出服務當前負載狀況的指標都可以作爲控制擴縮容行爲的數據源。在有了資源利用率閾值後，彈性伸縮控制面會不斷地去輪詢該服務所有副本的平均資源利用率，然後和閾值進行對比。如果實際平均利用率低於閾值，那麼就說明服務的實例數太多，存在一定冗餘，此時可以通過減少一定副本數的操作來使得每個實例均攤的資源使用量增大，直到資源的實際使用情況接近閾值。同理，如果服務的平均利用率大於閾值，那麼就需要通過增加副本數的手段來緩解每個實例的資源壓力。
通過彈性伸縮的流程可以看到，整個控制邏輯中最重要的就是穩定性，對於在線業務來說，我們需要保證它們被縮容的實例在流量上漲之後能夠被迅速地擴容，不然就有可能造成單實例流量過高影響服務的 SLA，嚴重時可能會導致服務不可用，甚至影響到整個請求調用鏈路。所以我們需要底層系統提供一整套的機制進行穩定性保證，主要包括幾個方面：
首先集羣本身在規模逐漸變大的過程中，需要具有較強的擴展性和可用性，只有這樣才能支持頻繁的擴縮容行爲，同時保證擴縮容的效率，彈性資源的規模才能夠上得去。
然後是需要有一套集羣維度的監控體系，爲彈性伸縮提供穩定實時的利用率數據，根據彈性伸縮的過程可以知看出，控制面強依賴於從監控系統中獲取服務的實時資源利用率情況，我們需要儘可能避免利用率採集出錯或者延遲太高，導致服務在需要擴容時擴不上去的問題。
最後，我們需要有一套 Quota 系統保證業務在伸縮的過程中，集羣整體的資源量是可控的，不能出現在波谷時將服務的副本數縮容後，它所對應的 Quota 被別的服務佔用且無法歸還的情況。
下面針對這三個方面，我們將分別介紹下 TCE 在提升整個底層系統穩定上所做的工作。
第一個，對於集羣自身穩定性的優化，我們投入了很多精力提升調度的效率和響應的速度，同時避免集羣雪崩的風險。這一塊涉及到的內容比較細節和繁多，而且有些性能問題是由於 TCE 特殊的使用方式帶來的，所以在這裏不會一一進行分享，而是挑兩個來進行說明。我們會對 APIServer 中的請求進行分級，這個優化的實現實際上也是參考了社區的相關 KEP，希望做這個優化的背景是在一些特殊的異常情況下，APIServer 中會收到大量的請求而出現 429，此時彈性伸縮的控制面請求如果也因爲 429 而出現大規模異常的話，將導致服務無法被正常擴容。爲了規避此類風險，我們會將關鍵鏈路上的請求設置爲更高優先級，從而保證對這類請求的優先響應。另外一個比較有重要的點就是，我們在多個 member K8S 集羣上構建了聯邦層，當某個 member 集羣出現問題時，可以在上層中實現將服務副本數重新在其他集羣上拉起，來規避單集羣雪崩對在線服務的影響。當然集羣穩定性的構建會是一個非常持久的話題，需要持續投入精力不斷推進。
第二個是監控體系的構建，我們知道 K8S 有一套原生的監控系統 Metrics Server，但是 TCE 中沒有采用，主要是基於這樣一些考慮。首先， Metrics Server 只能代理實時數據不存儲歷史數據，如果希望在彈性伸縮中根據歷史數據做一些更平滑的策略無法得到更好的滿足。其次，由於我們做了多個集羣的聯邦，所以需要在聯邦層上得到服務資源使用情況的匯聚數據。最後，不是隻有彈性伸縮依賴監控系統，業務也需要實時通過字節內部的監控管理系統查詢業務的實時數據和歷史數據，還有前文所說的超售也需要獲取到相關的統計數據才能進行資源回收，所以監控系統內還需要將數據同步到字節內部的離線分析系統。爲了更好支持這些特殊的邏輯，TCE 借鑑 Metrics Server 實現了一套監控系統，主要包括以下的組件，其中 SysProbe 是內部的資源採集 Agent，負責提供單機上 Pod 聚合數據，Metrics Agent 通過輪詢收集每臺機器上的數據，然後通過 Proxy 寫入到 Store 中，Store 是一個基於內存的數據庫。
第三，在提高整個數據採集鏈路的高可用和高性能方面，我們也做了一定的優化，例如對所有組件都採用多實例 stand by 的方式部署。監控數據存儲時使用多分片，分片信息在 etcd 中維護，由專門的組件 configServer 進行同步；Proxy 從 Store 中讀寫數據時採用 quorum 機制保證數據的準確性；Store 自身支持故障恢復和數據同步；每個 Store 實例都在內存中以 podName 爲 key 構建 B 樹以提高查詢效率，並對數據內容進行壓縮來降低存儲壓。同時 Store 還支持一些控制面計算邏輯的下發，例如直接返回服務的平均利用率等信息，由於 TCE 中的部分服務可能規模非常龐大，單 deployment 副本數可以達到 5000 +，所以計算邏輯放在 metrics 系統中實現能夠大大降級數據傳輸的量和延遲。目前這套監控系統單次查詢延遲在 30ms 左右，單次採集延遲在 60s 左右，基本能夠滿足彈性伸縮的需求
最後一個關鍵的底層支撐系統就是 Quota 系統，同樣的，K8S 原生也提供了簡單的 Quota 實現，但是由於字節內部的服務有特定的組織形式，組織內部存在着比較複雜的嵌套關係，套用原生的 Quota 系統會非常難以維護，同時也無法對計算類服務所需求的定製化資源進行更好地支持，所以 TCE 從零開始構建了自己的 Quota 計量體系。具體來說，字節中的服務大致會按所屬的業務劃分到不同組中，我們使用 CRD 對象來記錄各個組中所有服務的總體資源可用量和使用量的信息，然後通過旁路的 Controller 不斷輪詢更新對象的內容。當業務方對服務副本數進行修改時，APIServer 的請求處理鏈中會通過 validation webhook 對該服務的資源進行校驗和准入控制。尤其需要說明的是，當服務開啓彈性伸縮後，Quota 系統將通過擴容的實例數上限進行資源的預留，從而保證資源彈性伸縮過程中資源量可控。
在有了底層系統爲彈性伸縮的穩定性背書後，就可以真正開始介紹對應的控制流程了。彈性伸縮的控制鏈路可以結合這張圖進行理解，這裏 AppScaling Controller 會起到類似原生 HPA Controller 的作用， 它會以 30s 的粒度同步每個服務的配置，並通過 Metrics Proxy 讀取 Deployment 下所有 pod 的利用率數據，據此調整實例數。TCE 中沒有使用原生的 HPA，而是使用了自定義的 CRD HPAExtension，這樣我們可以具體更強的控制能力，同時補充一些內部需要的特性。
目前我們支持根據 CPU、內存、GPU 等多個資源維度進行彈性伸縮，另外我們還補充了一些新的特性，這裏會挑一些重點特性進行介紹。例如我們支持根據時間段設置不同的配置、支持設置服務級別的對利用率小幅波動的容忍度、支持單步擴縮容的步長。關於這個配置的背景主要是因爲一些算法相關的服務在啓動和退出時需要進行數據的同步操作，如果單次擴縮容實例數較多，可能會對底層的存儲組件造成較大的瞬時壓力，所以需要將一次較大的擴縮容行爲拆分爲多次較小擴縮容行爲來做一個緩衝，使得服務副本數的變化更加平滑。另外一個比較重要的點是我們會使用每個服務小時級別的歷史數據作爲保底的策略，以應對監控系統異常的情況，這裏我們還是利用了服務天級的利用率比較穩定的特性，萬一監控系統出現問題導致無法獲取監控數據時，控制面可以使用該服務昨天相同時段的利用率數據來作爲指導擴縮容的兜底策略。
我們結合一個線上開啓彈性伸縮的服務看一下對應的效果，其中上面這張圖展示的是服務實例數的變化曲線，下面這張圖則展示的是 CPU 平均利用率的變化曲線，圖中也同樣標註了用戶在不同時間段的配置，例如最大擴容副本數、最小可縮容副本數、利用率閾值等。從圖中可以看到，在一天的絕大部分時間段裏，服務的 CPU 利用率基本維持在給定閾值的範圍內小幅波動，這也是我們希望看到的最顯著的效果。另外，由於該服務配置的最小可縮容副本數較高，所以在夜間低峯時，服務利用率仍然會降到低於閾值的水平，對於較爲 critical 的服務，這種策略爲服務提供了一定兜底的能力，在一定程度上是可以接受的，當然對於這部分資源浪費，我們仍然可以通過常態混部的手段進一步壓榨和利用。最後，該服務晚高峯時的副本數已經擴到了上限，但是利用率仍然高於給定的閾值，出現這種情況一般有兩種可能，一種是服務配置的資源利用率閾值不夠合理，另一種就是服務的流量確實出現了增長，可擴容的上限已經不能夠滿足業務的需求，無論是哪種情況，TCE 都會給對應的服務 owner 發送報警，告訴他需要對彈性伸縮的配置進行一定的調整以適應流量的變化和特性。
混部實踐
在開啓了大規模彈性伸縮後，TCE 中的在線服務也就具備了生產和使用彈性資源的能力了。正如背景裏介紹中提到的，爲了能夠充分地使用彈性資源，我們採取的方案是和離線的作業進行混合部署。最開始開展混部項目的時候，我們底層的隔離能力還沒有非常完善，所以我們採取的是 0/1 的方式進行混部。具體來說，就是把在線服務波谷時產生的彈性資源摺合成同等資源規模的整機出讓給離線使用，使得同一時段不會同時有在線服務和離線任務跑在同一臺機器上，減少在離線之間的互相影響，然後當在線波峯來臨時進行回收。爲了實現這個邏輯，我們引入了集羣部署水位的概念，結合這張圖可以對部署水位和資源出讓的過程有更加清晰的瞭解。
初始情況下，在線服務沒有進行彈性伸縮，集羣中整體的資源部署處於滿載狀態。當在線服務的波谷來臨後，幾乎所有服務都會因爲彈性縮容而導致副本數降低。從整體上看，集羣裏節點上的 Pod 會變得非常稀疏，集羣整體資源部署水位也隨之降低。當集羣的部署水位低於設置的閾值後，控制面會通過一定規則選取部分在線節點，將該節點上的 Pod 驅逐到別的節點上，並標記該節點不可調度，最後通過某種機制將該節點加到離線的集羣中實現資源的出借。同理，當在線服務的波峯來臨後，會發生一個逆向的控制過程，控制面在通知並確保離線任務撤離後，重新將節點加回到在線集羣中設置爲可調度狀態，實現資源的回收。在實際操作中，TCE 集羣的水位閾值通常會定義在 90% 的水平上，這就意味着集羣在常態下會始終維持在一個接近滿載的部署狀態中，從而能夠最大限度地提升資源利用率。
錯峯控制面最主要的職責就是控制節點的動態出讓和回收，即節點的動態伸縮。爲了使得節點出讓的過程更加透明，我們使用一個狀態機來描述節點的轉移狀態，其中 Online 和 Offline 分別表示節點處於在線使用和離線使用的狀態。而當節點被選擇進行出讓和回收時，會分別先進入到 OnlineToOffline 或 OfflineToOnline 的中間狀態。在此狀態下在離線都無法調度新的任務到節點上來，控制面會負責清理殘留的在線的 Pod 和離線任務，並執行用戶所配置的 hook 函數，只有當這些工作都處理完成後，纔會真正完成節點的出讓和回收邏輯。控制面會不斷循環檢查各個節點的狀態並驅動狀態轉換的過程，同時儘可能地保證出讓過程的平滑和穩定，尤其是減少對於離線業務的影響，這個主要是因爲離線任務通常運行的時間稍長一些，頻繁殺死和重跑任務相對來說影響較大，所以控制面需要引入提前通知的機制，在提前通知的時間窗口內，離線調度器不會再調度新的任務，同時儘可能保證那些已經被調度的任務順利跑完，從而將任務殺死率維持在一個可接受的範圍內。
當開啓了基於在線部署水位的混部之後，我們使得彈性資源得到了有效的利用，但是正如背景介紹中所講的那樣，由於整體資源的緊缺，部分關鍵在線服務在高峯期會存在資源缺口，所以不得不一直處於一定程度的降級狀態，並且這個資源缺口的量相對來說比較穩定，所以我們需要通過一種有保障的方式進行彈性資源的供給，使得業務從常態降級的狀態中解脫出來。在這樣的背景下我們開啓了基於定時定量的錯峯混部模式。在該模式下，我們能夠通過定時定量的方式，在在線流量高峯期將離線整機加入到在線集羣中，然後按照在線服務各自的資源需求進行擴容，等流量高峯過了之後，在線服務縮容歸還整機給離線。
至此，我們其實實現的是一套基於兩階段的混部模式，即白天離線出讓定量資源滿足在線業務高峯期的資源缺口，夜間在線通過基於資源利用率的方式進行彈性伸縮，出讓閒置資源支持離線的訓練。對於在線和離線雙方來說，它們實際每天使用的資源總量並沒有發生任何變化，只是我們通過分時的方式，在滿足在離線各自資源需求的同時，實現了資源動態靈活的配比。
前面的講述過程中遺留掉的一個重要問題就是在離線之間如何做到資源的互通，爲了對這個問題進行解釋，我們首先需要對參與混部的離線方做一個簡單的分類。目前來說，混部離線方主要包括兩類，一類是基於 YARN 進行任調度的模型訓練任務，一類是基於 Mesos 進行任務調度的視頻轉碼任務。這些離線調度器的單機 Agent 都是以 K8S Daemon 的形式部署在 TCE 集羣裏的。在在離線資源共享的方案中，K8S 會作爲資源的主導方，負責實時告知這些 Agent 它們可以使用的資源。
當節點處於在線使用的狀態下，K8S 看到的是整機資源都被在線使用，所以會通過暴露一個查詢接口來告知離線可用資源量爲 0，此時離線就不會往節點上任務調度任務。而當節點被選擇出讓後，控制面會通過在 Node 對象上注入特定的 label，將節點標記爲在線不可用。此時對於 K8S 來說，效果等同於該節點中在線可用的資源量變爲 0，所以它會通知節點上的離線 Agent 可用資源量是整機的資源。這裏需要提到的是，對於 YARN 和 Mesos 使用彈性資源來說會有一些區別。通常來說，YARN 上跑的模型訓練任務運行時間會比較長，任務殺死後重啓的成本相對較高，所以 YARN 在自己的調度隊列中會區分彈性資源和常駐資源。而對於 Mesos 來說，視頻轉碼主要以短視頻爲主，通常一個任務運行的時間在幾十秒左右，重跑代價較小，所以彈性資源和常駐資源的使用方式目前是無差別的。
到這裏關於 0/1 混部的控制邏輯已經梳理得比較清楚了。下面我們可以結合一個更爲具體的例子來介紹一下混部的落地場景。我們知道在春節等活動中，在線業務的流量隨時可能會出現激增，例如在搶紅包等環節，如果在線業務根據流量激增時的資源預估提前進行資源申請，可能會一些問題：首先通常來說，活動場景下整體資源都會處於比較緊張的狀態，在線集羣本身很可能沒有更多額外的資源提供 buffer。另外資源預估通常不夠準確，而且按照峯值進行資源預留會導致常態情況下存在大量的資源浪費。所以最好的解決方式就是使用彈性資源來填充這個隨時可能出現的資源缺口。
具體的做法是在離線集羣中也搭建一套 K8S 集羣，並且在該集羣中複製在線 K8S 集羣中的服務，我們稱這些被複制的服務爲“影子服務”。在常態情況下，“影子服務”的副本數都是 0，並且對業務來說是不可見的，所以不會對離線任務的運行產生任何影響。在此基礎上，我們可以根據流量預估提前定義一個離線資源出讓的比例和“影子服務”彈性伸縮的規則，當然這個配置也是可以隨時變更的。當在線服務流量出現激時，我們就能夠通過一鍵的方式，下線掉離線任務並擴容在線“影子服務”，從而有效地緩解在線流量的瞬時壓力。而當在線激增的流量下去之後，我們又可以通過一鍵的方式，將影子服務縮容並重新將節點加回到離線中。通過這種方式，我們有效支持了多次活動場景下，在線服務臨時的資源需求。
目前的混部已經在很大程度幫助我們提升了集羣整體的資源效率，並支持了不同多種資源需求場景，但仍然存在着一些比較關鍵的問題。無論是水位模式還是錯峯模式，它們的問題都在於需要進行節點的驅逐，使得在離線不會同時跑在一臺機器上，這樣在保證安全的情況下卻使得碎片資源無法得到更加高效的利用，所以隨着我們隔離能力的逐步完善，我們逐步嘗試將在離線同時運行在一臺機器上，通過隔離技術和資源動態分配的策略實現資源層徹底融合。
此外，混部整個控制鏈路自身也存在一定的缺陷，首先是資源出讓方和使用方存在一定意義上的靜態綁定關係，由 A 出讓的彈性資源如果分配了給 B 使用後，如果 C 和 D 也想共享使用這些資源，需要通過管理員從整體上重新規劃這部分資源的分配比例，隨着混部規模的擴大和接入業務方的增多，相應的運維成本也會變得非常高。其次，由於我們現階段沒有統一的一層來記錄彈性資源的具體情況，所以就無法給出一些全局維度的可觀測數據，繼而也就無法回答出“在全天的時間維度上我們還有哪些時段各有多少資源可以申請和使用”等類似的問題。最後一個痛點就是缺乏對彈性資源標準化的審計能力，進而導致我們無法進行有效的成本覈算。
爲了解決以上這些問題，我們後續會朝着資源出讓和使用更加解耦的方向進行演進，具體來說，我們將會使用資源市場來統一對彈性資源的管理。在資源市場中，我們會抽象出資源池的概念統一所有彈性資源的入口，無論是在線服務，還是離線任務，都能將出讓的資源寫入到對應的資源池中，這樣資源出讓方將不再關注自己彈性縮容出來的資源流量問題。然後我們會在資源池的基礎上構建分時分級的 Quota 系統，作爲彈性資源的統一出口，以及成本覈算的基。在 Quota 系統中，常駐資源將永遠是有保障的，而彈性資源將是會以儘可能滿足的形式進行供給，Quota 系統需要保證每時每刻常駐資源和彈性資源的總量不超過資源資源上限。資源使用方也不再關心彈性資源是從哪裏來的，他們可以像使用常駐資源一樣申請對彈性資源的使用。最後我們會對彈性資源的使用方進行分級，這樣就可以在常態資源無法滿足的情況下，通過殺死優先級較低的服務，實現對常駐資源有保障這一語義的支持。
以上就是今天我分享的主要內容，謝謝大家。
本文轉載自公衆號字節跳動技術團隊（ID：toutiaotechblog）。
原文鏈接：