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

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

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

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

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

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

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

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

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

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

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

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

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

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

在集團(tuán)內(nèi)部已經(jīng)有不少團(tuán)隊(duì)開發(fā)了針對(duì)某個(gè)業(yè)務(wù)域的彈性調(diào)度產(chǎn)品，而業(yè)內(nèi)部分公有云服務(wù)商也提供了彈性伸縮服務(wù)，菜鳥彈性調(diào)度所面對(duì)的問題以及對(duì)應(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)用。因此，不同于針對(duì)某個(gè)特定的業(yè)務(wù)域的彈性調(diào)度，菜鳥彈性調(diào)度在進(jìn)行設(shè)計(jì)時(shí)不能進(jìn)行過多的業(yè)務(wù)假設(shè)，在設(shè)計(jì)調(diào)度算法和策略模式時(shí)必須考慮到足夠的通用性；在配置上需要給予使用者充分的個(gè)性化能力以應(yīng)對(duì)不同的業(yè)務(wù)場(chǎng)景；在系統(tǒng)結(jié)構(gòu)設(shè)計(jì)時(shí)，需要考慮到策略橫向擴(kuò)展能力，當(dāng)有新的特殊業(yè)務(wù)場(chǎng)景出現(xiàn)時(shí)，能夠進(jìn)行快速線性擴(kuò)展。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

機(jī)房均攤規(guī)則；

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

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

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

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

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

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

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

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

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

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

決策策略

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

資源安全策略

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

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

資源優(yōu)化策略

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

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

時(shí)間策略

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

服務(wù)安全策略

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

選擇qps還是rt？

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

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

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

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

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

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

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

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

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

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

下游分析

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

一些其他的專項(xiàng)問題

如何處理毛刺？

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

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

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

如何計(jì)算擴(kuò)容和縮容數(shù)量？

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

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

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

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

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

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

如何應(yīng)對(duì)大促的場(chǎng)景？

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

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

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

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

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

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

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

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

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

未來發(fā)展

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

總結(jié)

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

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