阿里妹導讀：菜鳥方舟(ark)是面向菜鳥所有研發的資源管理和運維平臺，負責對菜鳥的基礎設施資源進行管控，以支撐日常和大促的資源需求。彈性調度是菜鳥方舟的一個重要組成部分，也是方舟的一個重要的功能特性。
通過彈性調度，能夠使應用在業務壓力上升時及時擴充資源，而在業務壓力下降時對資源進行釋放，從而實現在保證穩定性的前提下盡可能地提升資源使用效率。在未來引入離線任務進行混部，或者細粒度資源計價方式后，這種模式將會大幅度降低菜鳥整體IT成本。今天，我們來細細聊聊菜鳥方舟彈性調度系統背后的技術，希望對你有所啟發。

為什么菜鳥需要彈性調度？

在彈性調度出現之前，菜鳥整體資源使用率都處于一個比較低的水平，這是因為：

1.在線應用一般是通過單機性能壓測，并且結合經驗預估業務流量的方式來確定所需容器數量。這種方式很大程度上會受到評估者主觀因素的干擾，在估算業務流量時也通常會保留較大的冗余。

2.以往的模式下，一個應用分組的擴縮容操作頻率很低，這使估算業務流量時，需要以每天的峰值流量以及未來一段時間（通常以月為單位）內業務的發展情況來作為評估標準。而一般峰值流量出現時段可能只占全天時間的一小部分，非峰值時段就出現大量的資源浪費。

從接入的彈性應用分組表現來看，容量評估不準確是非常普遍的現象，而且與實際偏差值非常大。彈性調度作為一種在線動態評估系統運行狀態并且做出擴縮容決策的系統，它讓應用的開發者以及運維人員對資源的關注點，從具象化的容器數轉換成抽象程度更高的“目標”（例如合理的資源使用率目標，服務的合理rt目標），降低了人工評估時不可避免引入的主觀因素影響。另外，結合方舟平臺提供的可靠、高效的擴縮容能力，對應用分組的擴縮容操作時效性可以達到分鐘級，從而真正意義上實現資源的“按需使用”。對于菜鳥來說，彈性調度是提升資源使用率最為行之有效的一種方式。

為什么菜鳥更適合落地彈性調度？

彈性調度雖然能夠帶來較大的使用收益，但并不是適用于所有的公司或組織，而其之所以能夠成功在菜鳥進行落地，主要取決于以下幾點原因：

菜鳥的業務特點決定系統是協調商家，cp，消費者之間的信息流轉，而且物流訂單流轉的長鏈路多交互的特點也決定了信息流大于實操流即可，所以我們的系統面臨導購秒殺型的脈沖峰值菜鳥方舟彈性調度系統場景微乎其微。

菜鳥在2017年年初全面實現容器化并且接入混合云架構體系后，已經完成了資源管理從“面向機器”到“面向應用”的轉變，應用的部署、擴縮容等核心運維流程得到了極大的簡化和提效。方舟平臺作為容器資源管控平臺，在經歷了2017年618、雙十一等大促活動的考驗后，其穩定性已經得到了充分的驗證，這就為彈性調度的落地創造了充分的技術基礎。

菜鳥的核心應用絕大多數都屬于無狀態的在線計算應用，每天業務壓力峰谷值差距明顯，這就為彈性調度的落地提供了足夠的業務場景基礎。

彈性調度并不是一項獨立的工程，需要很多基礎服務進行協助，并且依賴于統一、規范的系統環境。而菜鳥的應用遵從阿里集團規范，彈性調度可以直接讀取alimonitor、鷹眼、alimetrics等工具提供的監控運維數據，并且核心應用所使用的技術棧基本上得到了收斂，這就位彈性調度的落地提供了充分的環境基礎。

基于如上四點，菜鳥才能以較小的成本快速實現了彈性調度。

與同類產品有什么區別？

在集團內部已經有不少團隊開發了針對某個業務域的彈性調度產品，而業內部分公有云服務商也提供了彈性伸縮服務，菜鳥彈性調度所面對的問題以及對應的產品思路上與這些同類產品有什么區別呢？

首先，菜鳥彈性調度所期望覆蓋的應用范圍是菜鳥所有的無狀態核心應用，這些核心應用所涉及的業務鏈路、邏輯特性、資源傾向性、業務流量特性等都存在非常大的差異性，很難抽象出一種通用的業務模式來描述這些應用。因此，不同于針對某個特定的業務域的彈性調度，菜鳥彈性調度在進行設計時不能進行過多的業務假設，在設計調度算法和策略模式時必須考慮到足夠的通用性；在配置上需要給予使用者充分的個性化能力以應對不同的業務場景；在系統結構設計時，需要考慮到策略橫向擴展能力，當有新的特殊業務場景出現時，能夠進行快速線性擴展。

其次，在應對復雜場景時，系統越是通用，所帶來的配置選項也就越多，公有云上的彈性調度服務通常提供非常多的配置參數，正是因為他們希望通過這種“把問題拋給用戶”的方式，來抵消問題的復雜性，讓使用者自己為自身的穩定性和成本負責。這種彈性調度帶來的穩定性風險和成本節約效果完全依賴于用戶本身對于這項技術的了解。與之不同，我們作為菜鳥的基礎技術團隊，我們把自己的角色定義為穩定性和成本問題的解決者，而不是向我們的用戶拋去更多的問題，我們希望提供給菜鳥所有應用owner的不僅僅只是像公有云上彈性這樣的一種新的資源管理功能，而是替我們的用戶解決降低成本、提升穩定性。因此，在產品設計之初時，我們就希望絕大多數應用分組能夠做到一鍵接入彈性，把絕大多數應用的配置問題在使用者感知之前就進行解決，將策略參數配置納入到我們的核心職責范圍內。而對于那些具有特殊性要求的應用，為其提供輔助性建議，幫助其進行少量的配置即完成彈性能力的引入。

彈性調度應用現狀

截止到目前為止，菜鳥已經基本實現了對容器數量15臺以上（接入前）的無狀態應用分組進行彈性接入，接入應用分組的整體全天CPU平均使用率達到20%以上（計算方法為取分組CPU使用率與分組容器數的加權平均值）。每天擴縮容總容器數在3000臺以上。在2017年雙十一時，彈性調度作為輔助手段從11月12日0點起對部分應用分組進行縮容，使菜鳥占用物理CPU核數與包裹數的比例得到顯著下降。

以下圖一展示的是一個應用分組一天當中CPU使用率與容器數的變化曲線對比；圖二展示的是該應用分組某個核心服務同時段流量變化曲線：

菜鳥方舟彈性調度方案介紹

彈性調度的基本模式

如前文所言，方舟的彈性調度希望提供給用戶的不只是一種彈性操作集群資源的能力，而是要對所有用戶的成本和穩定性優化這件事負責。由于目標應用在各方面差異性很大，所涉及的配置項數以千計并且一直處于動態變化狀態，全靠我們人工進行配置管理非常不現實。

由此，方舟彈性調度提出了一種閉環反饋式的模式（如上圖所示）。彈性調度基礎能力基于應用分組運行情況和不同應用分組的策略配置參數，做出擴縮容決策，并通過方舟的容器操作服務調整集群容器數量；應用分組集群受到集群容器數量變化的影響，會產生不同的表現行為（例如擴容時集群平均CPU使用率會發生變化，服務rt會在一定范圍內下降等）；應用分組的表現在以實時數據提供給彈性決策的同時，也會進行歷史數據的離線存儲（Alimonitor/EagleEye等集團標準監控系統都提供了這樣的數據服務）；自動策略配置會周期性獲取這些歷史數據，并依照一定的算法，對不同的應用分組進行不同的策略配置，從而再次影響到彈性調度策略的決策。

這種模式的優越性在于：

1.具備一定程度的自我進化能力。當應用分組剛剛接入彈性時，其大多數的策略參數都為默認值；而當彈性運行一段時間后，結合自動評估方式，各種參數會得到不斷的修正以達到更好的彈性效果。以服務安全策略為例：服務安全策略在實時決策階段概括起來就是對當前服務rt于服務的sla閾值進行比較，剛剛接入彈性時，服務的sla是基于服務接入彈性前的歷史rt來得到的，一般來說非彈性狀態下服務rt的表現，與彈性狀態下服務rt的表現是有很大的區別的，可能一開始由于服務sla設置得不合理（一般來說是過小），會出現“多擴”的現象，由服務rt違反sla引起的擴容會占到整體擴容原因的大多數。這種現象會被每天定時執行的分析任務捕捉到，判斷出sla設置得不合理，結合最近幾天的運行狀態，重新計算服務sla，由此提高閾值設置的合理性；

2.以更高的抽象層次來進行海量參數的配置，以解決普遍問題。還是以服務rt的sla閾值為例，當我們把配置視角關注到一個具體服務時，我們可能會糾結于一個服務它所對應的具體業務邏輯是什么、它涉及的調用鏈路是什么、上游服務對它的容忍性等等細節問題，那么這樣一來，面對菜鳥不同應用提供的成千上萬個服務，逐一配置根本不可能做到（注：每天都會服務會上線和下線，服務的業務邏輯也可能發生變化，配置是需要進行經常性更新的，這無疑使人工配置更加變得不現實）。而自動策略配置邏輯以更高的抽象層次來看待各項參數，對于服務rt，基于一個普遍適用的假設：“服務rt在一天當中的絕大多數時間都是處于合理狀態”，并且通過概率分布計算（服務rt真正的分布情況也可以通過歷史數據統計得到），可以得到一個數學意義上的sla閾值（以正態分布為例，求得一段時間內服務的平均rt和rt分布標準差，即能得到在不同概率下應該設置的閾值）。

如上圖的正態分布曲線，我們如果把閾值定為平均rt + 2個標準差，那么依照概率粗略計算，我們假設一天當中有將近33分鐘服務處于rt過高狀態（1440分鐘 * （1 - 0.9544）/ 2），由此就得到了一個數學上合理的閾值（這部分邏輯只是服務安全策略邏輯的一小部分，具體在后文介紹該策略時具體說明）。這樣一來，對于各式各樣的服務，只要能獲取到它的歷史監控數據，就能自動、快速地得到這個數學上的閾值。

彈性調度的架構體系

這部分就不在此做過分冗余的解讀了，本文的其他部分或多或少會涉及到。

為什么采用三層決策的模式？

首先介紹一下方舟彈性調度的三層決策：

1.第一層是策略決策，策略決策層由多個不同的策略組成，并且支持快速擴展。策略之間邏輯完全隔離，每個策略計算完成后都會獨立輸出動作（擴容、縮容、不變）和數量。為了能夠適應不同應用之間的異構，每個應用分組也可以根據實際情況啟動或關閉不同的策略。

2.第二層是聚合決策，聚合決策收集第一層所有策略的決策結果，并依據聚合規則得到一個合并后的<動作，數量>組。這一層的規則十分簡單：當同時存在擴容和縮容決策結果時，以擴容為準，忽視縮容結果；當存在多個擴容結果時，以擴容數量最多的結果作為最終結果；當存在多個縮容結果時，以縮容數量少的結果作為最終結果。

3.第三層是執行決策，這部分決策主要會考慮到一些規則，最終告訴擴縮容服務：要不要擴縮，要擴縮多少個容器，如果是縮容那么要縮容哪幾個具體容器，如果是擴容那么具體的容器規格、擴容到的機房等。執行決策進行判斷時需要考慮到的規則非常復雜，這里簡單羅列一些相對重要的規則：

機房均攤規則；

當前應用分組的擴縮容狀態規則，例如如果本次為擴容：如果正在擴容，當本次擴容目標數量大于正在擴容的目標數量時，取差值再次發起一個擴容，由此實現并行擴容；當本次擴容目標數量小于正在擴容的目標數量時，忽略本次的擴容請求；若正在進行縮容，則立即停止縮容，并根據目標容器數和當前容器數發起擴容。

模式規則：彈性調度目前支持全自動擴縮模式、人工審批模式兩種，如果當前分組為人工審批模式，那么本次決策會需要管理員進行審批。

最大值最小值保護規則：應用分組可以配置最大值最小值，執行決策會保證由彈性調度發起的擴縮任務，不會使最終容器數超過最大值或小于最小值。

此外，執行決策層對于單個分組來說是強一致的，并且第二層輸出的決策結果，是集群需要達到的目標容器數量，這種設計是前兩層能夠做到完全無狀態且冪等的重要因素。

三層決策器使每一層只需要關注自己本身的決策邏輯，分離了“變與不變”的業務邏輯，對擴縮容的最終確定進行層層驗證，是實現“覆蓋菜鳥大多數應用”目標的基礎。

如何做到計算的無狀態、冪等和高可用？

1.方舟彈性調度深度依賴了ISS，ISS作為一款經歷過大促考驗，并且為菜鳥很多核心業務提供異步任務調度服務的高可用中間件，在功能、性能和穩定性上都非常可靠。方舟彈性調度對于在線數據的獲取采用了“短頻周期性主動拉取”的模式，通過ISS提供的周期性異步任務調用功能，為每個應用分組在接入彈性時自動注冊一個獨立的ISS周期任務。ISS在發起任務時，會在目標集群中隨機進行選取，并且對任務執行時的生命周期進行管理，支持任務的重試。此外，ISS的客戶端也提供資源保護能力，當集群中的某個進程壓力過高時會更換目標機進行重試。

2.方舟彈性調度的在線計算數據源自于內嵌式監控系統alimetrics。alimetrics是伴隨web容器的一種嵌入式metrics系統，包含非常豐富的監控項。當需要獲取應用分組的細粒度監控數據時，這種數據查詢、讀取、傳輸壓力是被分攤到每一個目標容器的，而非一個集中式的數據中心，這種設計使得數據源不存在單點，數據源的可靠性和壓力容忍能力相比于依賴一個中心式的數據服務來說，要優越很多。

3.為了過濾毛刺，所有計算都基于或大或小的滑動時間窗口。通過alimetrics獲取較短時間窗口（1小時以內）數據時能擁有非常高的性能，并且對應用的干擾非常小，這樣就降低了計算的重試成本。基于這一能力，彈性調度的計算任務可以在每次執行時重新獲取一個時間窗口內的全部監控數據，而不需要在自身內存中維護一個滑動窗口，這是彈性調度計算無狀態的基礎；

4.彈性調度三層決策器中，第三層與其他兩層部署在不同的集群中。由于無論應用分組狀態如何，第一層和第二層都要進行短頻周期性計算，而只有在需要進行擴縮容時（只占一天中很小的一部分）才會將任務發往第三層，因此將強一致性的范圍限定在第三層，在保證可靠性的同時，對性能影響最少。而第二層輸出到第三層的決策數量，以“目標容器數”而非“擴縮容數量”的形式給出，這樣一來，即使在同一時刻對于一個應用分組有多個彈性決策任務在執行，向第三層輸出多個決策結果，也不會影響最終的擴縮容行為。

決策策略

方舟彈性調度的決策策略支持快速橫向擴展，目前已經包含多個決策策略，部分策略處于測試驗證狀態，這里對幾個最為核心，同時也是最早上線運行的策略進行介紹：

資源安全策略

資源安全策略關注的是系統資源使用情況。目前，基于以往的運維經驗以及菜鳥的業務特點，資源安全策略關注CPU、LOAD1和Process Running隊列三個系統參數。當其中有一項以上，在近期時間窗口內的集群平均（為了消除毛刺和流量不均帶來的影響）違反上限閾值時（支持個性化配置），發起擴容。當存在多項違反時，取需要擴容數量最大的一項為當前策略決策結果（數量計算方法在后面給出）。

上圖是一個資源安全策略得到擴容結果時的資源使用情況。

資源優化策略

資源優化策略同樣關注的是系統資源的使用情況，但是它的存在是為了在系統空閑時回收資源。同樣關注上述三個系統參數，當這三項同時低于下限閾值時，發起縮容。注意，由于第二層決策器的存在，當有其他決策器要求擴容時，資源優化策略產生的縮容需求就會被抑制。

上圖是一個資源優化策略得到縮容結果時的資源使用情況。

時間策略

目前的彈性決策模式是后驗的，即在發生閾值違反后，才發起擴容。對于有些業務來說，存在有規律的流量突然上揚，例如一些定時計算任務。自動策略配置基于應用的歷史流量變化情況，當判定流量變化為周期性變化，且變化幅度過大，后驗式彈性無法及時跟上時，會為這個分組生成一個時間策略配置，即在每天的指定時間段內，將集群容器數維持在一個指定數量之上。由于第二層決策器的存在，當其他策略在這個時間段內判斷需要的容器數，大于配置的指定數量，那么以較大的一項作為結果；而在這段時間內，由于時間策略會持續生成擴容結果（如果數量已經滿足，那么生成擴容決策，但數量為0），其他的縮容決策結果會被持續抑制。

服務安全策略

服務安全策略是目前最為復雜的一個策略，目前，服務包含消息隊列Consumer、RPC服務、HTTP服務三種。每天有至少一半以上的擴容任務是由服務安全策略發起的。

選擇qps還是rt？

很多的彈性調度系統會選擇服務的qps作為最重要的一個考慮因素，但是我們在經過前期的一系列思考討論后，決定放棄qps而使用rt，主要出于以下幾點原因：

1.qps是一個服務的變量，它的變化受限于使用者的使用情況。你可以判斷對于xx業務，在當前時刻的qps是否合理，但是對系統來說，只要能夠承載，服務成功率和rt在合理范圍內，qps取任何值都是合理的。換句話說，當前總qps可以作為業務健康度判斷依據，但不能作為系統（狹義）健康程度的判斷依據（單機最大可承受qps與之不同，注意區別）。rt和服務成功率才是一個服務最為根本的表現特性。

2.通過當前qps和單機最大可承受qps來得到當前容器數，在資源完全隔離，且每個query使用的資源近乎相等時才成立。而對于菜鳥的應用來說：

很多核心應用是跨業務鏈路的，服務千姿百態。一個數據查詢服務和一個涉及業務操作的服務很可能出現在同一個應用分組上，此時，總qps這個概念變得毫無意義，而獲取不同服務單個請求與資源的關系根本不可能。

目前的容器隔離效果并不是特別完美，在全鏈路壓測時經常出現同物理機容器使用同構資源互相爭搶的現象，這就使線上實際運行環境與單機性能壓測的環境無法做到相同，單機性能壓測數據的參考意義值得懷疑。

服務可能隨時都在變化，而單機性能壓測并不能在每次發生變化時及時跟進，時效性無法保證。

閾值比較與多服務投票

如何為海量服務的rt自動配置閾值已經在前面的例子中已經對此做過介紹，此處不再進行贅述。但是需要注意的是：由于這種閾值設定只是數學上的“合理閾值”，還需要其他手段進行修飾。因此我們又引入一個假設：如果是資源不足引起的rt違反閾值，那么該分組中所有的服務都會受到影響。這是因為應用分組內服務之間所使用的資源是沒有隔離的，他們使用同一個系統環境（受到影響并不意味著所有服務都會違反閾值，不同的服務所依賴的資源種類并不相同，對資源短缺的耐受能力也不相同）。

因此，我們采用了一種“多服務投票”模式來進行rt判斷。每個服務分別進行獨立的閾值比較，當rt違反閾值的服務占總服務的比例達到一定程度時，才做出擴容決策，服務安全決策的擴容數量由閾值違反程度（按違反百分比來計算）最高的服務決定。

從實際運行的情況來看，當采用“只要有服務違反閾值就進行擴容”的方式運行時，出現誤擴、多擴的頻率非常高，而引入這種“多服務投票”模式后，誤擴、多擴基本上被消除了（實際上人工判斷一個擴容是否為誤擴、多擴時也常常采用這種模式，發現多個服務的rt同時飆高時，則認為擴容合理）。此外，一個應用分組所提供的服務越多，這種模式運行的效果越好。

下游分析

并不是所有的rt違反閾值情況都需要擴容，如果是所依賴的中間件或下游服務導致的rt升高，擴容并不能解決問題，甚至還有可能造成更壞的影響（例如db線程池滿）。因此，服務安全策略在進行計算時，如果發現一個服務違反了它的閾值，會先查詢它的下游依賴服務、中間件調用rt是否違反各自的sla，只有在服務自身違反閾值，但下游服務和中間件沒有違反閾值時，才會參與擴容投票。離線任務基于歷史數據計算服務的sla時，同時也會計算它的依賴服務與中間件的閾值，其中鏈路結構數據來自于鷹眼的離線數據。

一些其他的專項問題

如何處理毛刺？

彈性調度需要保證擴容足夠及時，但又要對系統的毛刺有足夠的耐受能力，否則會造成誤擴、誤縮。毛刺在實際環境中是普遍現象，不僅流量不均、網絡抖動等環境問題會導致毛刺的發生，監控統計系統潛在的異常和bug也有可能會誘發毛刺。

為此，方舟彈性調度在進行任何計算時，都會引入時間窗口數據作為計算源頭，而每塊時間的數據內，包含的是一個集群所有容器的數據：

計算時，對于每個所需的監控項，會去掉時間窗口內的最大值和最小值，然后求取平均，以此來抹去毛刺帶來的影響。另外，時間窗口的大小對于去毛刺以及及時性也會有很大的影響。目前，方舟彈性調度中存在5分鐘和10分鐘兩種不同規格的時間窗口。對于可能會導致擴容的策略來說，選取較小的時間窗口，而對于可能會導致縮容的策略來說，選取較大的時間窗口（我們希望擴容相對于縮容來說，更加激進）。

如何計算擴容和縮容數量？

在確定了是否要擴縮后，第二步便是確定擴縮容數量。首先介紹縮容，由于縮容速度相對于擴容較快，且縮容慢不會影響穩定性，所以方舟彈性調度的縮容采用一種“小步快跑”的方式，只要決定縮容，那么固定縮容的容器數量為集群當前容器數量的10%。

擴容數量的判斷相對于縮容來說要復雜得多，我們這里以最為常見的閾值比較類策略的數量決策為例。首先，定義一個大的原則：每次擴容數量最大不得超過集群當前容器數的50%，在這個范圍內，對閾值違反的程度越高，擴容的容器數量越多。因此我們在這里引入sigmoid函數，通過一定的轉換使其計算結果在0~0.5之間，將閾值違反程度百分比作為入參代入sigmoid函數（當然，會進行一些參數的調整），從而得到擴容的百分比。

sigmoid函數是一個在0~1之間變化的曲線，常用于數據的歸一化計算。對于f(x)=sigmoid(x) - 0.5來說，當x > 0時，該函數的取值在0 ~ 0.5之間。

對于像CPU使用率這種數據來說，有一個區別是該項的取值最大不會超過100，存在一個上限；而諸如服務rt這類的數據則不存在上限。那么顯然，完全用同一個公式會導致CPU觸發的擴容數量小于服務rt觸發的擴容數量。此時，只需要設置一個目標，例如我們希望當CPU使用率達到80%，即違反程度為 （80% - 閾值）/ 閾值時，擴容比例接近50%，基于這個目標對f(x)進行逆運算就能得到系數a，使進行針對CPU的擴容數量計算時代入這個系數a，就能得到所期望的結果。

如何實現鏈路容量的彈性？

只要鏈路上所有應用分組都接入了彈性，那么已經可以認為此鏈路的容量也具備彈性。

如何應對大促的場景？

方舟通過“容器計劃”和彈性調度進行配合的方式，為大促提供了完整的資源管理解決方案。容器計劃可以讓各個應用Owner在指定的大促時間段內（包括壓測和大促時段）提出容量申請。當接入彈性的應用分組在進入大促時間段內，彈性調度的擴縮容模式會立即轉變成人工確認模式，并且將會把集群容器數擴容到容器計劃所申請的數量。當大促時間段結束時，非彈性的應用分組將會直接縮容回原有容器數量；而彈性應用分組則會通過彈性策略進行緩慢資源回收。

在大促時間段內，盡管彈性調度沒有自動進行擴縮容，但是擴縮容決策依然在進行中。彈性調度會持續向管理員或大促決策小組發出容器擴縮容建議，一方面在流量超出預期、資源不足時及時發出警告并且提供建議的擴容數量，也能協助管理員對一些資源進行及時的回收，幫助進行縮容決策。

彈性調度如何推動業務本身的演進？

彈性調度推動業務本身的演進是我們一直以來的目標，對我們來說，只有這樣才可以形成真正意義上的業務閉環。這種推動主要是采用數據分析的方式進行，目前彈性調度會產出以下幾種數據：

rt|資源相關性，反映了服務rt和CPU等系統資源使用率的相關程度，相關程度越高，則服務使用情況對資源越敏感，使用彈性調度的收益也越明顯；

中間件穩定性，反映了由中間件rt超出閾值引起的服務rt違反。由于服務rt的升高直接影響到了服務的可用性，因此當這項數據過高時，會建議檢查中間件的使用情況，進行優化；

下游穩定性，反映了由下游服務rt超出閾值引起的服務rt違反。當這項數據過高時，會建議當前應用推動下游服務穩定性升級，或者推動下游彈性化；

應用啟動時效，一個擴容任務直到應用實例啟動完成，能夠對外正常服務才認為成功，應用啟動時間越短，那么彈性調度對其擴容也就越及時，當出現流量洪峰時也能最快速度進行保護；

限流配置合理性。我們發現不少接入的應用在服務rt都處于正常范圍，且系統資源使用率極低的情況下居然觸發了自身所配置的限流值，對于這種情況，會建議應用進行合理的業務分析和測試來調整限流值配置。

未來發展

目前，方舟的彈性調度還處于一個發展成長的過程中，對于一些應用的調度效果還要進行進一步的提升。我們也期待更多了解容器、調度、中間件技術的的童鞋加入，一起并肩作戰。簡歷投遞郵箱：jian.weng@alibaba-inc.com 我們翹首以盼～

總結

以上是生活随笔為你收集整理的首次公开！菜鸟弹性调度系统的架构设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。