概述
1. 背景
隨著業(yè)務(wù)形態(tài)發(fā)展，更多的生產(chǎn)力集中到業(yè)務(wù)創(chuàng)新，這背后要求研發(fā)能力的不斷升級(jí)。阿里文娛持續(xù)傾向用更加高效、穩(wěn)定、低成本的方式支持快速軟件交付，保障高可用。于是運(yùn)維力從 “HaaS”（Handwork as a Service）到“PaaS”再到“SaaS”（System as a Service），運(yùn)維生產(chǎn)力從 Ops 到 DevOps 再到 NoOps。
在傳統(tǒng)應(yīng)用容量管理模式下，應(yīng)用、集群容量評(píng)估缺乏有效數(shù)據(jù)依據(jù)與支撐，往往犧牲效率或成本來平衡經(jīng)驗(yàn)決策風(fēng)險(xiǎn)，另一方面，人肉決策和執(zhí)行難以滿足業(yè)務(wù)對(duì)穩(wěn)定性和效能的追求。因此，阿里文娛急需一個(gè)能夠把優(yōu)酷所有應(yīng)用的容量管理起來的能力。
2. 目標(biāo)
整體目標(biāo)分成 2 個(gè)階段，一是摸清各應(yīng)用容量水平，二是為所有應(yīng)用賦予彈性伸縮的能力， 最終直觀看到各應(yīng)用及總體資源使用率的明顯提升。
技術(shù)挑戰(zhàn)與解法
1. 單機(jī)性能
既然談到容量問題，已知的壓測(cè)方案有鏈路壓測(cè)方案、模擬流量壓測(cè)方案等。為什么還要 自研一套基于單機(jī)引流的壓測(cè)方案來評(píng)估應(yīng)用容量水平？
1）更接近日常真實(shí)水平；
2）無(wú)人工決策，純機(jī)器決策單機(jī)性能瓶頸；
3）全自動(dòng)，比如配置成發(fā)布結(jié)束后進(jìn)行單機(jī)性能壓測(cè)。
2. 彈性
彈性指標(biāo)選擇：僅靠集群 CPU 水位彈性確實(shí)可以解決絕大多數(shù)類型應(yīng)用，但若基于集群QPS 水位則可更精準(zhǔn)的進(jìn)行彈性伸縮。
1）多維度彈性指標(biāo)，同時(shí)也需要支持自定義指標(biāo)；
2）多方位彈性方案，使用條件編排策略來達(dá)到多個(gè)彈性指標(biāo)之間的協(xié)同。
技術(shù)方案
1. 全自動(dòng)單機(jī)性能探索
與各接入層對(duì)接，自動(dòng)配置權(quán)重完成單機(jī)引流，配合性能拐點(diǎn)算法支撐，完成自動(dòng)識(shí)別性 能拐點(diǎn)并終止壓測(cè)，最后一并記錄單機(jī)能力值。并允許每天定時(shí)壓測(cè)、發(fā)布結(jié)束壓測(cè)來感知每 天、或每次發(fā)布給單機(jī)性能帶來的變化，使用戶更親近自身應(yīng)用的容量水平。
2. 彈性伸縮
與底層交付系統(tǒng)聯(lián)動(dòng)，打造從規(guī)劃，交付，計(jì)費(fèi)，彈性水平擴(kuò)展、回收、資源排布調(diào)度全 生命態(tài)面向業(yè)務(wù)需求的自驅(qū)動(dòng)統(tǒng)籌調(diào)度資源管理系統(tǒng)。一方面，業(yè)務(wù)資源統(tǒng)一平臺(tái)構(gòu)建與維護(hù)， 挖掘空閑資源，共享彈性計(jì)算力，整體提高部署密度，降低業(yè)務(wù)單位成本；另一方面，面向不 同應(yīng)用場(chǎng)景，自動(dòng)化容量管理，按需分配，保證應(yīng)用服務(wù)可用性，提高容量運(yùn)維效能。
3. 方案結(jié)合
全自動(dòng)單機(jī)性能探索與彈性伸縮的結(jié)合框架，如下圖：
1）應(yīng)用接入：無(wú)縫接入；
2）單機(jī)性能壓測(cè)自定義配置：無(wú)需再定義配置過多配置，默認(rèn)“智能探索”可以支持大部分 場(chǎng)景；
3）單機(jī)引流：從集群中其他機(jī)器的流量引流至被壓測(cè)機(jī)器；
4）智能拐點(diǎn)識(shí)別：使用時(shí)間序列數(shù)據(jù)趨勢(shì)轉(zhuǎn)折點(diǎn)提取算法，進(jìn)行拐點(diǎn)識(shí)別；
5）單機(jī)性能預(yù)測(cè)：詳見技術(shù)細(xì)節(jié)；
6）基礎(chǔ)彈性配置：詳見技術(shù)細(xì)節(jié)。
技術(shù)細(xì)節(jié)
1. 單機(jī)引流權(quán)重優(yōu)化
1）調(diào)整權(quán)重就是調(diào)整單機(jī)流量，且權(quán)重越高，單機(jī)流量越高；
2）增加自動(dòng)化調(diào)整權(quán)重策略方法。權(quán)重優(yōu)化：用于已經(jīng)識(shí)別出拐點(diǎn)，保證下一次壓測(cè)接近 MAX 權(quán)重保持平緩；權(quán)重遞增：用于未觸發(fā)拐點(diǎn)，保證下一次壓測(cè)能引更多的流量。
2. 響應(yīng)時(shí)間拐點(diǎn)識(shí)別
使用算法：箱線圖。基于 IQR 定制多組 k 的箱線圖上限的異常提取，上限=Q3+k*IQR 實(shí)現(xiàn)。而效果能夠定位到多數(shù)拐點(diǎn)，并且一般拐點(diǎn)前的一個(gè)時(shí)間點(diǎn)的值為單機(jī)能力值。
3. 成功率拐點(diǎn)識(shí)別
0 錯(cuò)誤代表 100%成功率
成功率拐點(diǎn)識(shí)別相比響應(yīng)時(shí)間拐點(diǎn)識(shí)別更加嚴(yán)格。雖然同樣是“基于 IQR 定制多組 k 的箱 線圖”實(shí)現(xiàn)，但此時(shí) k 必須收緊，因?yàn)槌晒β手笜?biāo)較為敏感，稍有波動(dòng)就應(yīng)該終止壓測(cè)。
4. 拐點(diǎn)提取參考了“時(shí)間序列數(shù)據(jù)趨勢(shì)轉(zhuǎn)折點(diǎn)提取算法”文章
比如在 3 個(gè)連續(xù)點(diǎn) Xi、Xi+1、Xi+2 的判定上，它們的發(fā)展趨勢(shì)共有 9 種情況：當(dāng) Xi+2-Xi>0， 即圖 a，b，e 這 3 種情況屬于總體趨勢(shì)上升，當(dāng) Xi+2-Xi<0，即圖 f，g，i 這 3 種情況屬于總體 趨勢(shì)下降，當(dāng) Xi+2-Xi=0，即圖 c，d，h 這 3 種情況屬于總體保持不變。
而我們通過“基于 IQR 定制多組 k 的箱線圖”可以識(shí)別出上升和下降 2 種拐點(diǎn)，分別對(duì)應(yīng) 不同的場(chǎng)景，如響應(yīng)時(shí)間拐點(diǎn)識(shí)別（上升拐點(diǎn)識(shí)別），成功率拐點(diǎn)識(shí)別（下降拐點(diǎn)識(shí)別），而 k 的定義方式也參考近期數(shù)據(jù)。
比如某個(gè)應(yīng)用日常響應(yīng)時(shí)間穩(wěn)定在 100-200ms 和某個(gè)應(yīng)用日常響應(yīng)時(shí)間穩(wěn)定在 2-3ms 的 k值是不一樣的，不合適的 k 用在 2-3ms 的這種數(shù)據(jù)上會(huì)導(dǎo)致異常識(shí)別較為頻繁及不準(zhǔn)確。
5. 單機(jī)性能預(yù)測(cè)方案
單機(jī)性能與什么有關(guān)，系統(tǒng)指標(biāo)？如果是 JAVA 應(yīng)用還和 JVM 相關(guān)指標(biāo)有關(guān)？而應(yīng)用本身 有會(huì)有各種池的限制，如 JVM 相關(guān)池、TOMCAT 相關(guān)池、DB 相關(guān)池、Redis 相關(guān)池、隊(duì)列相 關(guān)池等，這些都可以作為預(yù)測(cè)單機(jī)性能的特征。先基于 PCA 抽象出 N 個(gè)特征，也稱降維，可 將兩兩線性相關(guān)的因素進(jìn)行整合或排出，降維后建立線性回歸模型，而擬合度較高的模型將予 以采納并進(jìn)行預(yù)測(cè)。同時(shí)預(yù)測(cè)參數(shù)也需要實(shí)事求是，比如日常 CPU 區(qū)間為 2-60%，那預(yù)測(cè)參數(shù) 可以為 80%，此時(shí)若超過 100%那將毫無(wú)意義。
6. 流量驅(qū)動(dòng)彈性方案
基于 CPU 指標(biāo)的彈性伸縮：比如 CPU 超過 60%則執(zhí)行彈性擴(kuò)容，CPU 低于 20%則執(zhí)行彈 性縮容。擴(kuò)容與縮容允許按機(jī)器數(shù)比例進(jìn)行伸縮：如按 5%的機(jī)器數(shù)進(jìn)行彈性擴(kuò)容。定義彈性區(qū) 間：如 10-20，機(jī)器數(shù)會(huì)在 10-20 區(qū)間變動(dòng)。
一般低峰期會(huì)處在最低機(jī)器數(shù)區(qū)域，高峰則會(huì)處在最高機(jī)器數(shù)區(qū)域，基于外掛單機(jī)能力模 型。允許基于 QPS 水位指標(biāo)進(jìn)行彈性，可隨 QPS 增加而增加機(jī)器數(shù)，反之則減少機(jī)器數(shù)。
總結(jié)
自動(dòng)化容量管理與彈性伸縮的深度結(jié)合解決了當(dāng)前容量預(yù)估的問題，使得資源能夠被合理使用。一方面，用戶專注業(yè)務(wù)層，做基于業(yè)務(wù)需求的容量規(guī)劃、交付和維護(hù)，革命性改變生產(chǎn)關(guān)系，提高研發(fā)迭代效率；另一方面，更加細(xì)粒度的彈性伸縮，比如小時(shí)、分鐘的資源的快速流轉(zhuǎn)，資源粒度分解到具體硬件計(jì)算垂直伸縮，也是一種更優(yōu)的解決方案，使得彈性更加迅速能做到秒級(jí)能力，進(jìn)一步壓縮集群密度，降低單位成本。
