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

為什么菜鳥需要彈性調(diào)度？

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

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

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

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

為什么菜鳥更適合落地彈性調(diào)度？

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

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

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

菜鳥的核心應(yīng)用絕大多數(shù)都屬于無狀態(tài)的在線計算應(yīng)用，每天業(yè)務(wù)壓力峰谷值差距明顯，這就為彈性調(diào)度的落地提供了足夠的業(yè)務(wù)場景基礎(chǔ)。

彈性調(diào)度并不是一項獨立的工程，需要很多基礎(chǔ)服務(wù)進行協(xié)助，并且依賴于統(tǒng)一、規(guī)范的系統(tǒng)環(huán)境。而菜鳥的應(yīng)用遵從阿里集團規(guī)范，彈性調(diào)度可以直接讀取alimonitor、鷹眼、alimetrics等工具提供的監(jiān)控運維數(shù)據(jù)，并且核心應(yīng)用所使用的技術(shù)棧基本上得到了收斂，這就位彈性調(diào)度的落地提供了充分的環(huán)境基礎(chǔ)。

基于如上四點，菜鳥才能以較小的成本快速實現(xiàn)了彈性調(diào)度。

與同類產(chǎn)品有什么區(qū)別？

在集團內(nèi)部已經(jīng)有不少團隊開發(fā)了針對某個業(yè)務(wù)域的彈性調(diào)度產(chǎn)品，而業(yè)內(nèi)部分公有云服務(wù)商也提供了彈性伸縮服務(wù)，菜鳥彈性調(diào)度所面對的問題以及對應(yīng)的產(chǎn)品思路上與這些同類產(chǎn)品有什么區(qū)別呢？

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

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

彈性調(diào)度應(yīng)用現(xiàn)狀

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

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

菜鳥方舟彈性調(diào)度方案介紹

彈性調(diào)度的基本模式

如前文所言，方舟的彈性調(diào)度希望提供給用戶的不只是一種彈性操作集群資源的能力，而是要對所有用戶的成本和穩(wěn)定性優(yōu)化這件事負責。由于目標應(yīng)用在各方面差異性很大，所涉及的配置項數(shù)以千計并且一直處于動態(tài)變化狀態(tài)，全靠我們?nèi)斯みM行配置管理非常不現(xiàn)實。

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

這種模式的優(yōu)越性在于：

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

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

如上圖的正態(tài)分布曲線，我們?nèi)绻验撝刀槠骄鵵t + 2個標準差，那么依照概率粗略計算，我們假設(shè)一天當中有將近33分鐘服務(wù)處于rt過高狀態(tài)（1440分鐘 * （1 - 0.9544）/ 2），由此就得到了一個數(shù)學(xué)上合理的閾值（這部分邏輯只是服務(wù)安全策略邏輯的一小部分，具體在后文介紹該策略時具體說明）。這樣一來，對于各式各樣的服務(wù)，只要能獲取到它的歷史監(jiān)控數(shù)據(jù)，就能自動、快速地得到這個數(shù)學(xué)上的閾值。

彈性調(diào)度的架構(gòu)體系

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

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

首先介紹一下方舟彈性調(diào)度的三層決策：

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

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

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

機房均攤規(guī)則；

當前應(yīng)用分組的擴縮容狀態(tài)規(guī)則，例如如果本次為擴容：如果正在擴容，當本次擴容目標數(shù)量大于正在擴容的目標數(shù)量時，取差值再次發(fā)起一個擴容，由此實現(xiàn)并行擴容；當本次擴容目標數(shù)量小于正在擴容的目標數(shù)量時，忽略本次的擴容請求；若正在進行縮容，則立即停止縮容，并根據(jù)目標容器數(shù)和當前容器數(shù)發(fā)起擴容。

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

最大值最小值保護規(guī)則：應(yīng)用分組可以配置最大值最小值，執(zhí)行決策會保證由彈性調(diào)度發(fā)起的擴縮任務(wù)，不會使最終容器數(shù)超過最大值或小于最小值。

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

三層決策器使每一層只需要關(guān)注自己本身的決策邏輯，分離了“變與不變”的業(yè)務(wù)邏輯，對擴縮容的最終確定進行層層驗證，是實現(xiàn)“覆蓋菜鳥大多數(shù)應(yīng)用”目標的基礎(chǔ)。

如何做到計算的無狀態(tài)、冪等和高可用？

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

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

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

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

決策策略

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

資源安全策略

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

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

資源優(yōu)化策略

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

上圖是一個資源優(yōu)化策略得到縮容結(jié)果時的資源使用情況。

時間策略

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

服務(wù)安全策略

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

選擇qps還是rt？

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

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

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

很多核心應(yīng)用是跨業(yè)務(wù)鏈路的，服務(wù)千姿百態(tài)。一個數(shù)據(jù)查詢服務(wù)和一個涉及業(yè)務(wù)操作的服務(wù)很可能出現(xiàn)在同一個應(yīng)用分組上，此時，總qps這個概念變得毫無意義，而獲取不同服務(wù)單個請求與資源的關(guān)系根本不可能。

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

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

閾值比較與多服務(wù)投票

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

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

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

下游分析

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

一些其他的專項問題

如何處理毛刺？

彈性調(diào)度需要保證擴容足夠及時，但又要對系統(tǒng)的毛刺有足夠的耐受能力，否則會造成誤擴、誤縮。毛刺在實際環(huán)境中是普遍現(xiàn)象，不僅流量不均、網(wǎng)絡(luò)抖動等環(huán)境問題會導(dǎo)致毛刺的發(fā)生，監(jiān)控統(tǒng)計系統(tǒng)潛在的異常和bug也有可能會誘發(fā)毛刺。

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

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

如何計算擴容和縮容數(shù)量？

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

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

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

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

如何實現(xiàn)鏈路容量的彈性？

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

如何應(yīng)對大促的場景？

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

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

彈性調(diào)度如何推動業(yè)務(wù)本身的演進？

彈性調(diào)度推動業(yè)務(wù)本身的演進是我們一直以來的目標，對我們來說，只有這樣才可以形成真正意義上的業(yè)務(wù)閉環(huán)。這種推動主要是采用數(shù)據(jù)分析的方式進行，目前彈性調(diào)度會產(chǎn)出以下幾種數(shù)據(jù)：

rt|資源相關(guān)性，反映了服務(wù)rt和CPU等系統(tǒng)資源使用率的相關(guān)程度，相關(guān)程度越高，則服務(wù)使用情況對資源越敏感，使用彈性調(diào)度的收益也越明顯；

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

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

應(yīng)用啟動時效，一個擴容任務(wù)直到應(yīng)用實例啟動完成，能夠?qū)ν庹７?wù)才認為成功，應(yīng)用啟動時間越短，那么彈性調(diào)度對其擴容也就越及時，當出現(xiàn)流量洪峰時也能最快速度進行保護；

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

未來發(fā)展

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。