阿里妹導(dǎo)讀：TPP(Taobao Personalization Platform, 也稱阿里推薦平臺 ) 平臺承接了阿里集團(tuán)300+重要個性化推薦場景，包括手淘首頁猜你喜歡、首圖個性化、購物鏈路等。除了提供應(yīng)用層面的支持和封裝，還肩負(fù)著機(jī)器分配和維護(hù)各場景運行穩(wěn)定的重任。

理想情況下，TPP平臺上的場景owner不需要關(guān)注底層的資源分配情況，平臺盡可能的提高CPU利用率，同時保證平臺上場景的穩(wěn)定。QPS（每秒查詢率）增加的時候擴(kuò)容，QPS減少的時候縮容，未來這些在夜間被拿掉的機(jī)器可以用來混部離線任務(wù)等；另外，在2016年雙11的時候，總的機(jī)器數(shù)目不足以維持所有的場景以最高性能運行，需要有經(jīng)驗的算法同學(xué)判斷場景的優(yōu)先級，從低優(yōu)先級的場景上拿出來機(jī)器，補(bǔ)充到高優(yōu)先級的場景中保證成交額。這些平臺穩(wěn)定性工作都是需要繁瑣的人工調(diào)度，會有如下的缺點：

人力成本巨大：人肉無法監(jiān)控和處理所有的場景；
反應(yīng)時間較長：從發(fā)現(xiàn)場景出問題，找出可以勻出機(jī)器的不重要場景，到加到重要場景所需要的時間相對過長，而程序天然的有反應(yīng)時間短的優(yōu)勢；
人力無法全局高效的調(diào)度資源， 而程序可以更敏感的發(fā)現(xiàn)場景的問題，更全面的搜索可以拿出來機(jī)器的場景，并可以準(zhǔn)確計算拿出機(jī)器的數(shù)目，有更好的全局觀。

基于如上的兩點：日常的時候提高資源利用率，大促的時候解放人力，TPP智能調(diào)度系統(tǒng)就產(chǎn)生了。TPP智能調(diào)度系統(tǒng)以每個集群（一組機(jī)器，承載一個或多個場景）的CPU利用率，LOAD，降級QPS，當(dāng)前場景QPS，壓測所得的單機(jī)QPS為輸入，綜合判斷每個集群是否需要增加或者減少機(jī)器，并計算每個場景需要增減機(jī)器的確切數(shù)目，輸出到執(zhí)行模塊自動增減容器。 TPP智能調(diào)度系統(tǒng)有如下的貢獻(xiàn)點：

日常運行期間，保證服務(wù)質(zhì)量的情況下最大化資源利用率；
大促運行期間，能夠更快速、更準(zhǔn)確的完成集群之間的錯峰資源調(diào)度；
支持定時活動事件的錄入，如紅包雨、手淘首頁定時的Push，程序自動提前擴(kuò)容，活動結(jié)束自動收回；
對重要場景提前預(yù)熱，完成秒級擴(kuò)容。

該系統(tǒng)由TPP工程團(tuán)隊和猜你喜歡算同學(xué)聯(lián)合搭建而成，從2017年9月開始規(guī)劃，到10月1日小批量場景上線，到10月13日三機(jī)房全量上線；經(jīng)過一個月的磨合，參加了2017年雙11當(dāng)天從 00:15 %到 23:59的調(diào)度，峰值QPS達(dá)到百萬級別。在日常運行中，集群平均CPU利用率提高3.37 倍， 從原來平均8%到27%；在大促期間，完成造勢場景，導(dǎo)購場景和購后場景的錯峰資源調(diào)度，重要服務(wù)資源利用率保持在 30% ，非重要服務(wù)資源利用率保持在50%, 99%的重要場景降級率低于2%。同時TPP智能調(diào)度系統(tǒng)的”時間錄入”功能支持定時活動，如首頁紅包的提前錄入，提前擴(kuò)容，活動結(jié)束收回機(jī)器，改變了以前每天需要定時手動分機(jī)器的情況。

問題定義與挑戰(zhàn)

TPP智能調(diào)度系統(tǒng)要解決的問題為： 如何在機(jī)器總數(shù)有限的前提下，根據(jù)每一個場景上核心服務(wù)指標(biāo)KPI（異常QPS等）和場景所在集群物理層指標(biāo)KPI(CPU,IO等)，最優(yōu)化每一個場景機(jī)器數(shù)目，從而使得總體資源利用率最高。

更加直白一點，就是回答如下的問題：

怎么判斷一個集群需要擴(kuò)容？擴(kuò)多少的機(jī)器
簡單的CPU超過一定的水位并不能解決問題。不同的場景的瓶頸并不完全一致，有IO密集型的（如大量訪問igraph），有CPU密集型的，一個場景可能在cpu不超過30%的情況下，就已經(jīng)出現(xiàn)了大量的異常QPS，Load很高，需要增加機(jī)器。
如何給不同的場景自適應(yīng)的判斷水位？
有的場景30% CPU運行的很好，但是有的場景10%可能就出問題了。
如何防止某些實現(xiàn)有問題的場景，不停的出現(xiàn)異常，不斷觸發(fā)擴(kuò)容，從而掏空整個集群，而實現(xiàn)效率較高的場景反而得不到機(jī)器，引發(fā)不公平。
如何用一套算法同時解決日常運行和大促運行的需求
當(dāng)總的機(jī)器數(shù)目有限的情況下，如何分配不同場景之間的機(jī)器，最大化收益（有效pv）。如何用程序?qū)崿F(xiàn)從某些場景拿機(jī)器去補(bǔ)充重要場景的運行。
對于運行JVM的容器，當(dāng)一個新加容器在到達(dá)100%服務(wù)能力之前需要充分預(yù)熱，預(yù)熱過程會有異常QPS的產(chǎn)生。算法一方面要盡可能少的減少擴(kuò)縮容的次數(shù)，另外一個方面，要盡可能快的發(fā)現(xiàn)擴(kuò)容的需求，實現(xiàn)較高的擴(kuò)容recall。如何在這兩者之間做tradeoff？

系統(tǒng)架構(gòu)

TPP智能調(diào)度涉及TPP的各方各面，其架構(gòu)圖如下所示，包括數(shù)據(jù)輸入、算法決策和決策執(zhí)行三個方面，但是為了更靈敏的、更及時的發(fā)現(xiàn)超載的場景并進(jìn)行擴(kuò)容，需要自動降級、秒級擴(kuò)容、單機(jī)壓測qps預(yù)估功能的保證。另外還有一些功能性的開發(fā)，如業(yè)務(wù)算法配置參數(shù)分離、調(diào)度大盤監(jiān)控、烽火臺規(guī)則運行平臺等的支持。最底層的更加離不開容器化的全量部署 ，使得加減機(jī)器，快速部署環(huán)境成為了可能。

算法介紹

智能調(diào)度的算法是在其他模塊都具備的情況下，才能夠穩(wěn)定有效的運行。因此在介紹智能調(diào)度算法之前，先對算法依賴的每個部分進(jìn)行簡要的介紹如下。

算法依賴模塊簡要介紹

KMonitor數(shù)據(jù)接入

KMonitor是基于optsdb on druid架構(gòu)的監(jiān)控系統(tǒng)。支持從Hippo,amon和Log文件收集監(jiān)控數(shù)據(jù),并可以在grafana上展示或是通過api接口獲取。 TPP調(diào)度系統(tǒng)對Kmonitor的使用包括兩部分:通過tpp的log文件注冊tpp服務(wù)的狀態(tài)信息和調(diào)度系統(tǒng)從Kmonitor獲取狀態(tài)信息。 目前注冊的狀態(tài)信息包括容器內(nèi)的cpu/load等系統(tǒng)狀態(tài)和每個場景的pv/latency等業(yè)務(wù)信息. 通過使用kmonitor提供的多租戶功能, tpp獨立部署了一套租戶系統(tǒng), 可以支持信息匯報延遲不超過5s。調(diào)度系統(tǒng)獲取這部分信息后作為計算的數(shù)據(jù)輸入。

Fiber秒級擴(kuò)容

2017年TPP全部集群運行在Fiber之上，Fiber是在Hippo機(jī)器調(diào)度系統(tǒng)的一種封裝，其優(yōu)勢在于能夠?qū)⑷萜鞯募虞d、預(yù)熱、上線維持在秒級別，而之前直接從Hippo調(diào)度機(jī)器，加載方案到正常上線需要10分鐘級別。Fiber本身可以配置buffer，每個一定時間將重要的P1場景加載到buffer中的機(jī)器上并定時預(yù)熱，通過實踐驗證，在提前有buffer預(yù)熱的情況下，從智能擴(kuò)縮容發(fā)出擴(kuò)容指令開始到機(jī)器完全掛上去，能夠在10s內(nèi)完成。

自動降級

自動降級是2017年TPP雙11的另外一個創(chuàng)新，其主要的思想是判斷當(dāng)天集群總的超時QPS的比例，如果從全局上統(tǒng)計超過用戶設(shè)置的閾值（如3秒鐘區(qū)間統(tǒng)計值超過1%），則將出現(xiàn)超時的容器集體降級。 所謂降級是指方案的一個新的配置，高級別的運行配置保證更好的展示效果，但是單容器能夠服務(wù)的QPS較少；低級別的運行配置會使得展示效果打折扣，但是單容器能夠服務(wù)的QPS會更多。舉個例子：首頁猜你喜歡L0的配置是訪問RTP，利用深度模型進(jìn)行item的打分，L1則會關(guān)閉RTP訪問的開關(guān)，從而節(jié)省CPU，服務(wù)更多的QPS，但是可能從業(yè)務(wù)上來看，展示的item的相關(guān)度會打折扣。

自動降級主要用在如下兩個方面：1. 雙11在0點峰值附近的時候，整個集群機(jī)器嚴(yán)重不足，可以通過集體配置降級，保證全部用戶能夠正常訪問，即使服務(wù)質(zhì)量稍有下滑，但是和超時相比，是可以忍受的； 2. 是和智能擴(kuò)縮容相關(guān)的。智能擴(kuò)縮容的出現(xiàn)，使得一天中集群的機(jī)器數(shù)目會發(fā)生更頻繁的變化，而JVM容器本身存在預(yù)熱的問題，當(dāng)一個新的容器掛載到線上知道100%預(yù)熱完成之前，就會出現(xiàn)嚴(yán)重的超時。有了自動降級之后，可以通過砍掉一部分二方服務(wù)的rt，使得即使預(yù)熱的QPS也不會嚴(yán)重超時，從而消減了擴(kuò)容瞬間對線上QPS的影響。當(dāng)然不同的場景其預(yù)熱過程要詳細(xì)的優(yōu)化，有CPU密集的、IO密集的、以及緩存型的，其預(yù)熱過程得有所不同。

自動壓測

場景壓測在每天夜里定時執(zhí)行，獲取場景的單機(jī)性能。對于具備降級配置的場景，會壓測每一套降級配置的性能。針對每個場景，當(dāng)場景owner將場景加入日常壓測列表，自動壓測程序?qū)诿客砹璩?:00調(diào)用API，獲得壓測列表，創(chuàng)建待壓測場景的影子場景，申請壓測發(fā)生容器，調(diào)用壓測接口逐漸增加qps，直至容器超出負(fù)載（系統(tǒng)load，cpu，業(yè)務(wù)異常率等）。目前CPU上限為100%，異常率的上限為5%。 該運行結(jié)果就可以作為TPP智能調(diào)度的輸入，作為每個場景在某個特定的級別（L0、L1、L2或者L3）的單機(jī)服務(wù)能力。壓測結(jié)果如下所示：

調(diào)度算法

在上述模塊穩(wěn)定保障下，智能調(diào)度算法形式化為資源調(diào)度優(yōu)化問題：

利用每個集群當(dāng)前的運行狀態(tài)計算每個場景需要的機(jī)器數(shù)目 Ni, 需要加機(jī)器為正值，需要縮容為負(fù)值。

確定每個機(jī)器的擴(kuò)縮容的數(shù)目，尋找最優(yōu)解，優(yōu)化目標(biāo)為，即使得CPU盡可能的均衡并接近集群目標(biāo)負(fù)載，如OptimalCPU=40%為集群最佳狀態(tài)：

約束條件為：

所有的Ci+Ni總和小于集群總的機(jī)器數(shù)
有多個不同的場景，每個場景的優(yōu)先級為P1到P3之一，每個場景都可能工作在L0到L3，所有工作在非L0的都可以被降級。
先滿足高優(yōu)先級場景，再滿足低優(yōu)先級場景。
所有P1場景的擴(kuò)容需求必須要被滿足。

智能調(diào)度算法核心要解的問題是：盡可能的通過給不同的場景加減機(jī)器，改變所有場景的CPU的值，將所有集群的CPU調(diào)節(jié)到目標(biāo)CPU（人工設(shè)定優(yōu)化目標(biāo)）的周圍， 并且盡可能的均衡。如兩個場景，目標(biāo)CPU為40%。將其調(diào)節(jié)為38%、42%，肯定要比10%、70%要好。這個均衡的程度是由優(yōu)化目標(biāo)來決定的。

在最開始算法考察的過程中，還考慮過別的一些算法，比如分層的背包方法，包的容量是“總的機(jī)器池子的quota”，每個集群是要放在書包里面的物品，放到里面會消耗一定的機(jī)器，消耗了背包的“空間”， 但是同時加了機(jī)器，CPU降低會帶來一定的增益：優(yōu)化目標(biāo)變小。暴力搜索也是可以在有限時間解這個問題的。

但是我們最后還是采用了一種樸素的做法，盡可能的模擬人進(jìn)行調(diào)度的方法，對需要機(jī)器的場景排個序，用不重要場景的機(jī)器拿出機(jī)器去補(bǔ)充重要P1場景。可以根據(jù)人為的經(jīng)驗去靈活調(diào)整擴(kuò)縮容次序，因為在實際運行過程中，可解釋性永遠(yuǎn)比最優(yōu)化更重要，你給一個場景加了機(jī)器，減了機(jī)器，需要給人家解釋清楚。而不是說，給某個集群拿掉10臺機(jī)器是因為集群總的負(fù)載均衡度上升了0.01。
更加詳細(xì)的介紹智能調(diào)度的算法如下。我們直接計算每一個集群CPU到達(dá)最優(yōu)解需要的機(jī)器數(shù)Ni, 如果Ni>0，表示需要擴(kuò)充機(jī)器降低CPU到目標(biāo)CPU，如果Ni < 0, 表示可以拿掉機(jī)器提高場景CPU到目標(biāo)CPU。有如下的幾種情形：

如果所有Ni的和 < 空閑機(jī)器, 即集群空閑的機(jī)器數(shù)目加上可以縮出來機(jī)器大于所有要機(jī)器的數(shù)目，那所有的需要擴(kuò)容的都可以到達(dá)目標(biāo)CPU，所有縮容的直接拿掉機(jī)器CPU升高到目標(biāo)CPU，也就是優(yōu)化目標(biāo)達(dá)到最小值0。

如果所有Ni的和 > 空閑機(jī)器, 即擴(kuò)容需求不能得到完全滿足。這時調(diào)度算法會選擇滿足限制條件，并且使得優(yōu)化目標(biāo)函數(shù)變化最小的梯度方向進(jìn)行變動。 具體方法是：將所有的非P1場景通過降級或者提高目標(biāo)CPU水位，使其需要的機(jī)器變少，甚至可以拿出機(jī)器。然后進(jìn)行如下迭代：每次選擇能夠拿出機(jī)器最多的場景，將其機(jī)器加到需要機(jī)器最少、優(yōu)先級最高的場景上，使其CPU達(dá)到目標(biāo)CPU。然后將擴(kuò)容被滿足的場景從list中移除。重復(fù)如上步驟，直到所有能夠拿出的機(jī)器被用完。“優(yōu)化目標(biāo)函數(shù)變化最小的梯度”是這樣體現(xiàn)的：盡可能少的降級非P1或者提高非P1場景的水位，盡可能多的滿足P1場景。

第2步可能有兩種結(jié)果，所有P1的擴(kuò)容需求被滿足，算法有解。否則算法無解，優(yōu)化目標(biāo)也沒有指導(dǎo)意義了，只能盡可能的滿足部分P1, 不能滿足的P1只能被降級。這種無解的情況只有在大促次峰值附近出現(xiàn)過極少數(shù)時間。

上述算法的復(fù)雜度為O（m） , m 為被調(diào)度的集群的個數(shù)，量級為1000，因此每次都能很快得出近似最優(yōu)解，計算開銷很小。

除了上述的尋找最優(yōu)值的算法，智能調(diào)度算法還有兩個關(guān)鍵模塊需要介紹：收斂邏輯和Ni的計算。

收斂邏輯

智能調(diào)度算法運行的控制邏輯是，設(shè)置迭代間隔，如每隔5秒進(jìn)行一次迭代。每一輪迭代中，拿到場景實時的狀態(tài)信息，場景“過載”了給擴(kuò)容，場景“空載”了給縮容，不論是擴(kuò)容還是縮容，在擴(kuò)的過程中，要時刻監(jiān)控關(guān)鍵指標(biāo)是否到了目標(biāo)區(qū)域，從而結(jié)束本輪迭代。這類控制邏輯，最重要的是要保證是收斂的，即不論怎么調(diào)整，最終會較快達(dá)到穩(wěn)態(tài)； 同時，不論系統(tǒng)何時、何種程度偏離穩(wěn)態(tài)，都是可以自己重新恢復(fù)到穩(wěn)態(tài)。

線上實驗表明，目前最可靠的收斂方式是為集群設(shè)置穩(wěn)態(tài)區(qū)間。如設(shè)置的區(qū)間為[20%,40%]， 如果cpu超出穩(wěn)態(tài)區(qū)間，大于40%，則加機(jī)器，等到下一輪迭代，判斷cpu是否在穩(wěn)定區(qū)間，如果是則停止調(diào)節(jié)；如果加機(jī)器加過頭了，cpu跌出了20%， 則減機(jī)器，讓cpu回升，經(jīng)過多輪迭代，最終達(dá)到穩(wěn)態(tài)。理論上，穩(wěn)態(tài)區(qū)間設(shè)置越大，收斂的速度會越快，基本不會出現(xiàn)擴(kuò)容擴(kuò)過頭的情況，在比較好的計算所需機(jī)器的算法支持下，一次就可以收斂。但是過寬的穩(wěn)態(tài)區(qū)間會使得資源利用率較低，有可能集群是在下線水位運行。

另一個極端就是穩(wěn)態(tài)區(qū)間設(shè)置成為一個值，指哪打哪，比如目標(biāo)cpu設(shè)置成為30%，如果CPU大于30%，就會擴(kuò)容，如果CPU小于30%，縮容。這樣的好處是，集群CPU肯定在30%附近波動，平均下來，集群CPU達(dá)到目標(biāo)值30%，但是這樣的缺點就是頻繁的增減機(jī)器，增加機(jī)器并不是沒有開銷，運行JVM的容器存在預(yù)熱問題，冷機(jī)器上線會增加異常QPS的比例，是得不償失的。經(jīng)過實際運行，我們選定optimalCPUDrift=2， 也就是在目標(biāo)CPU的+2和-2的區(qū)間都是穩(wěn)態(tài)，既能使得集群CPU達(dá)到目標(biāo)值，同時又能避免頻繁擴(kuò)縮容。

Ni計算公式

Ni表示一個場景機(jī)器數(shù)目的變動，Ni>0表示需要機(jī)器，Ni<0表示可以被縮容。Ni有兩種計算方式：

第一種計算方法是根據(jù)單機(jī)壓測的QPS來計算，非常直觀，因為單機(jī)QPS是通過線下不停的增加流量，一直到該單機(jī)CPU到達(dá)100%或者異常QPS超過5%，但在真實使用的過程中發(fā)現(xiàn)，線下的壓測數(shù)據(jù)通常和線上真實能夠服務(wù)的qps不太一樣，主要原因有兩個：一個是線上有可能是多個場景公用一個物理機(jī)，互相影響；另外一個是線下壓測只能是天級別的數(shù)據(jù)，但是有可能當(dāng)一個場景發(fā)生了方案更改，其服務(wù)能力也會發(fā)生變化，而壓測數(shù)據(jù)還是歷史值。

第二種計算方法采用的是當(dāng)前實時的結(jié)果，較為準(zhǔn)確。唯一的缺點的是會受到噪音CPU的影響，如剛擴(kuò)上去的機(jī)器，由于預(yù)熱的原因，CPU會瞬間飆高，等完全預(yù)熱了之后CPU才會降下來，這種問題的解決方法剛加上去的機(jī)器在預(yù)熱期間不輸出CPU的數(shù)據(jù)，免得影響Ni的計算。

擴(kuò)容的觸發(fā)條件

有了計算Ni的方法了之后，下一步需要關(guān)注的就是何時觸發(fā)擴(kuò)容，然后計算Ni。 目前智能調(diào)度算法的觸發(fā)條件有兩個：

1、當(dāng)目前1分鐘的平均CPU不在穩(wěn)態(tài)區(qū)間中。 此時：

當(dāng)一個場景降級的QPS比例大于一定閾值，目前線上取5%。由于降級觸發(fā)的擴(kuò)容，其：

最終的：

其他功能

負(fù)載均衡： 保證一個場景中多個容器之間的負(fù)載均衡，使得調(diào)度算法能夠工作在場景粒度，而不是容器粒度，減少需要調(diào)度的規(guī)模。
監(jiān)控大盤：監(jiān)控網(wǎng)頁、方面及時掌握智能調(diào)度的進(jìn)展
規(guī)則運行保障：通過crontab功能定時調(diào)度智能擴(kuò)縮容的運行。
擴(kuò)容原因透出：每次擴(kuò)容都有相應(yīng)的原因，供場景owner查看。
紅包雨：對于QPS增長特別快，幾乎直線拉升的增長受限于擴(kuò)容的速度。如果預(yù)先能夠知道活動發(fā)生的時間區(qū)間，可以通過提前錄入預(yù)估QPS，智能調(diào)度算法提前給其擴(kuò)容。
除了大盤，還進(jìn)行了機(jī)器的熱點和調(diào)度可視化，能夠在雙11當(dāng)天更方面的監(jiān)控集群的運行狀態(tài)。下圖中一個格子表示一個集群，顏色表示CPU水位，大小表示擁有機(jī)器數(shù)目。當(dāng)有場景被擴(kuò)容或者縮容時也會可視化出來。

線上性能實驗

日常模式

下圖取了10月1日（智能調(diào)度上線前）和11月6日（智能調(diào)度上線后）24小時內(nèi)首頁猜你喜歡的機(jī)器數(shù)、CPU利用情況對比（其中機(jī)器數(shù)和QPS做了歸一化處理）：

從上圖中可以看出，在運行了智能調(diào)度(紅色線)之后，CPU利用率從原來持續(xù)低于15%，平均CPU利用率8%提高到平均27%。值得指出的是，為了保護(hù)場景，智能調(diào)度設(shè)置了最小機(jī)器數(shù)的保證，數(shù)目為max {3臺機(jī)器，過去24小時機(jī)器平均值}，所以在凌晨1點到凌晨7點，即使QPS變?yōu)閭€位數(shù)， 場景機(jī)器沒有被完全拿空。如果有離線在線混部的需求，可以把凌晨的機(jī)器保護(hù)去掉，讓這些機(jī)器回歸機(jī)器池子，部署機(jī)器學(xué)習(xí)訓(xùn)練模型。

同時我們可以看出來，運行了智能調(diào)度之后，日常的機(jī)器數(shù)是原來固定分配機(jī)器的1/3，極大的節(jié)省了機(jī)器資源。

智能調(diào)度和固定機(jī)器相比，缺點就是會在一天中，比較頻繁的發(fā)生機(jī)器數(shù)目的變動，但是通過圖(d)的統(tǒng)計，可以看出超時qps能夠持續(xù)小于千分之2，處在可以接受的范圍內(nèi)。

大促模式

在上圖中，我們選擇了四個場景，記錄了它們在雙11當(dāng)天24小時的CPU、集群機(jī)器數(shù)、QPS（對數(shù)刻度）、超時QPS比例的變化圖。從上面第二個子圖可以看出來四個場景明顯的錯峰資源調(diào)度，藍(lán)色線在10點需要機(jī)器，但是后面機(jī)器貢獻(xiàn)出來提供給綠色的場景來使用。此外，從第二張子圖可以看出來，在雙11當(dāng)天有明顯的脈沖流量，自動擴(kuò)縮容保證了這些脈沖流量，同時保證了超時qps低于千分之6（如子圖4）。值得指出的是，2017年為自動擴(kuò)縮容運行的第一年，為了保證11日當(dāng)天的成交額，沒有將CPU水位調(diào)到很高，后來微調(diào)了集群的CPU水位，在所有P1水位在35%時，還能保證所有P1場景降級率均低于2%。

總結(jié)

智能調(diào)度系統(tǒng)作為集團(tuán)雙11推薦場景的重要基礎(chǔ)設(shè)施保障，在2個月的時間中工程、測試團(tuán)隊聯(lián)合算法同學(xué)完成了從架構(gòu)設(shè)計、算法調(diào)試、功能上線測試到雙11當(dāng)天百萬級的QPS的資源調(diào)度。從雙11凌晨00：15分接手機(jī)器調(diào)度開始，智能調(diào)度系統(tǒng)在24小時中做到了對上層應(yīng)用開發(fā)同學(xué)的透明化，保證他們能夠投入最大精力沖成交，完全不用擔(dān)憂資源不夠的問題。

智能調(diào)度系統(tǒng)全程無需人工干預(yù)和拆借機(jī)器，完成造勢場景，導(dǎo)購場景和購后場景的錯峰資源調(diào)度，P1場景資源利用率保持在 30% ，非P1資源利用率保持在50%, 所有P1場景降級率低于2%。即使大促當(dāng)天各種突發(fā)和變動的流量，超時率仍能夠控制在千分之六以內(nèi)，實現(xiàn)了讓工程和算法同學(xué)”零點高峰瞪大眼睛認(rèn)真看，雙11當(dāng)天買買買” 的愿望。

未來改進(jìn)

現(xiàn)在智能擴(kuò)縮容在定時脈沖QPS增加（如雙11當(dāng)天0點的QPS，定時的紅包雨），以及日常的QPS連續(xù)光滑變化的情況下有解 （定時脈沖QPS通過場景owner提前錄入活動預(yù)估QPS和持續(xù)時間，算法提前擴(kuò)容），但是在不定時的脈沖QPS增加的情況下不能很好的解決，主要受限于機(jī)器的加載速度和預(yù)熱速度，當(dāng)瞬間需要大量機(jī)器時候，提前預(yù)熱在buffer池子中的機(jī)器會被掏空，相當(dāng)于發(fā)生cache miss，得從hippo拿hippo機(jī)器，擴(kuò)容速度跟不上。如何能夠在有限buffer池子的情況下，盡可能的減少cache miss是未來的一個優(yōu)化點。
智能擴(kuò)縮容在擴(kuò)較多機(jī)器的瞬間，雖然通過自動降級的解決方案，能夠消除超時QPS，但是會有一定程度的降級QPS，如何能夠?qū)⒅悄軘U(kuò)縮容和RR層的流量調(diào)度結(jié)合起來，更穩(wěn)妥的進(jìn)行預(yù)熱，保證更加平滑的擴(kuò)容，同時保證預(yù)熱速度是未來的一個優(yōu)化的方向。

寫在最后
感謝桂南、天民、野蔓、永叔對項目的大力支持；
感謝TPP各場景的算法同學(xué)在智能調(diào)度運行過程中提出的寶貴的改進(jìn)和指導(dǎo)意見；
感謝項目所有參與人員: 劍豪，玉景，巫宸，麒翔，七炎，千鹍，唯勤，林謙，劍持，成都，振之，曲竹，聿劍，畫帆，薦軒

總結(jié)

以上是生活随笔為你收集整理的技术如何秒懂你？阿里百万级QPS资源调度系统揭秘的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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