vivo版本發(fā)布平臺(tái)：帶寬智能調(diào)控優(yōu)化實(shí)踐-平臺(tái)產(chǎn)品系列03
一、背景
伴隨著互聯(lián)網(wǎng)地興起，很多企業(yè)都經(jīng)歷過(guò)互聯(lián)網(wǎng)野蠻生長(zhǎng)的一段歲月。然而，在互聯(lián)網(wǎng)市場(chǎng)逐步成熟穩(wěn)定之后，各大企業(yè)在業(yè)務(wù)上的增長(zhǎng)速度逐漸放緩，也紛紛開始“對(duì)內(nèi)挖掘成本方面”的產(chǎn)出，對(duì)成本做更加精細(xì)化的管控，提升企業(yè)的競(jìng)爭(zhēng)力。
特別是隨著“互聯(lián)網(wǎng)寒冬”的來(lái)臨，“冷氣”傳導(dǎo)到各行各業(yè)，“降本增效”的概念也紛紛被重新提起。有拉閘限電的，扣成本扣細(xì)節(jié)；也有大規(guī)模裁員一刀切的，淘汰部分業(yè)務(wù)，壓縮人力；還有些團(tuán)隊(duì)直接組建橫向團(tuán)隊(duì)，通過(guò)頂層思維，在不影響團(tuán)隊(duì)運(yùn)作的情況下，專攻核心成本技術(shù)難題，保障降本效果。
本文，基于作者在CDN帶寬利用率優(yōu)化方面的實(shí)踐，跟大家分享一下我們的降本思路和實(shí)操方法。“降本增效”作為持續(xù)的創(chuàng)新方向，并不局限于某個(gè)部門，企業(yè)價(jià)值鏈的任何一個(gè)環(huán)節(jié)都可能會(huì)成為突破點(diǎn)。作為技術(shù)開發(fā)人員，我們則更多的需要“從各自負(fù)責(zé)的業(yè)務(wù)方向出發(fā)”，對(duì)公司成本有觸點(diǎn)的業(yè)務(wù)進(jìn)行分析和挖掘，針對(duì)性的從技術(shù)的角度出發(fā)，技術(shù)攻關(guān)，深入探索，降本增效，為公司帶來(lái)真實(shí)價(jià)值。
通過(guò)本文，你可以：
1）打開思路，為“降本增效”提供可能的思考方向，助力大家挖掘輕量化但是價(jià)值大的目標(biāo)。
2）一覽無(wú)遺，了解我們CDN帶寬利用率優(yōu)化的核心方法。
名詞解釋：
【CDN】?jī)?nèi)容分發(fā)網(wǎng)絡(luò)。
本文的CDN專指靜態(tài)CDN，動(dòng)態(tài)CDN主要是對(duì)路由節(jié)點(diǎn)的加速，帶寬成本規(guī)模相對(duì)小的多。通俗的解釋：CDN廠商在各地部署了很多節(jié)點(diǎn)，緩存你的資源，當(dāng)用戶下載時(shí)，CDN網(wǎng)絡(luò)幫用戶找到最近的一個(gè)節(jié)點(diǎn)，通過(guò)這個(gè)節(jié)點(diǎn)用戶下載速度大大提升。
【CDN帶寬利用率】
帶寬利用率=真實(shí)帶寬/計(jì)費(fèi)帶寬，可以理解為投入產(chǎn)出比一樣性質(zhì)的東西。為何要提升利用率？打個(gè)比方：你不會(huì)愿意花一億夠買價(jià)值一千萬(wàn)的東西，如果你的利用率只有10%的話，你其實(shí)就做了這樣一件不合邏輯的事。
【愚公平臺(tái)】通過(guò)帶寬預(yù)測(cè)和削峰填谷，大幅度提升企業(yè)總的CDN帶寬利用率的平臺(tái)。
二、“尋尋覓覓”找降本
作為CDN的使用大戶，在CDN帶寬成本指數(shù)級(jí)增長(zhǎng)的情況下，筆者有幸見(jiàn)證并參與了我司CDN降本的每一個(gè)環(huán)節(jié)，從最初基于各自業(yè)務(wù)CDN帶寬利用率的優(yōu)化到后來(lái)基于可控帶寬調(diào)控的思路。本章，我們來(lái)聊聊我們CDN降本的幾個(gè)重要階段，并跟大家分享一下，為什么我會(huì)選擇CDN帶寬利用率這一個(gè)方向去研究？
2.1 CDN帶寬計(jì)費(fèi)模式
首先，不得不講下我們的計(jì)費(fèi)模式，峰值平均值計(jì)費(fèi)：每天取最高值，每月取每日最高值的平均值作為計(jì)費(fèi)帶寬。
月度計(jì)費(fèi)=Avg(每日峰值)
該計(jì)費(fèi)模式意味著：每日峰值越低，成本越低。帶寬的利用率決定了成本。由此，我們從未放棄過(guò)對(duì)帶寬利用率的追求，下面看看我們都有哪些優(yōu)化帶寬利用率的經(jīng)歷吧。
2.2 CDN降本三部曲
我們CDN降本優(yōu)化主要分為三個(gè)階段。三階段各有妙用，在當(dāng)時(shí)的環(huán)境下，都有相當(dāng)不錯(cuò)的戰(zhàn)果。并且均是基于當(dāng)時(shí)的情況，探索出來(lái)的相對(duì)合理的優(yōu)化方向。
2.1.1 局部?jī)?yōu)化
局部?jī)?yōu)化是基于我司的主要CDN使用情況而產(chǎn)生的一種思路。作為手機(jī)生產(chǎn)制造廠商，我們的靜態(tài)CDN使用場(chǎng)景的核心業(yè)務(wù)是應(yīng)用分發(fā)類，如：應(yīng)用商店app分發(fā)，游戲中心app分發(fā)，版本自升級(jí)分發(fā)。歸納一下，核心六大業(yè)務(wù)占據(jù)了我司帶寬的90%以上，只要把這六大業(yè)務(wù)的帶寬利用率提升上去，我們的帶寬利用率就可以得到明顯的提升。
基于這樣一個(gè)情況，CDN運(yùn)維工經(jīng)常找到核心業(yè)務(wù)，給一個(gè)帶寬利用率的指標(biāo)，讓各業(yè)務(wù)把帶寬利用率提升上去。歸納一下，核心思路就是：找到核心CDN使用業(yè)務(wù)方、分別給他們定好各自的利用率指標(biāo)、提需求任務(wù)、講清楚優(yōu)化的價(jià)值。在這一階段優(yōu)化之后，我們核心業(yè)務(wù)的帶寬突發(fā)場(chǎng)景得到收口，整體帶寬利用率明顯得到提升。
2.1.2 全局優(yōu)化
由于局部?jī)?yōu)化是各自業(yè)務(wù)優(yōu)化，在大量突刺問(wèn)題解決之后，各業(yè)務(wù)的帶寬利用率優(yōu)化會(huì)進(jìn)入一個(gè)瓶頸區(qū)。其中，效果比較好的，單業(yè)務(wù)帶寬利用率也很難突破60%，除非是特殊的業(yè)務(wù)形式，帶寬完全受控這種情況。此時(shí)，我們業(yè)務(wù)把部分帶寬抽離出來(lái)，用以調(diào)控公司整體帶寬，進(jìn)一步提升公司整體帶寬利用率，我們把他定義為全局優(yōu)化階段。
基于這樣一個(gè)全局優(yōu)化的思路，各個(gè)業(yè)務(wù)只要沒(méi)有太大的突刺，總體帶寬利用率就會(huì)得到一個(gè)較大幅度的提升。首先，我們把帶寬進(jìn)行劃分，抽取部分可以受服務(wù)器控制的帶寬拆分為可控帶寬，主要是工信部許可的wlan下載部分帶寬；然后，我們觀測(cè)帶寬走勢(shì)，根據(jù)帶寬歷史走勢(shì)，分離出各個(gè)時(shí)段的帶寬數(shù)據(jù)，針對(duì)不同時(shí)段控制不同的帶寬量級(jí)放量，最終達(dá)到一個(gè)“削峰填谷”的目的。此策略是通過(guò)閾值控制放量速度的，每小時(shí)設(shè)置一個(gè)閾值，以每小時(shí)閾值生成每秒的令牌數(shù)，進(jìn)行令牌桶控量。
2.1.3 自動(dòng)化控制
全局優(yōu)化之后，作為技術(shù)開發(fā)人員，更進(jìn)一步的方法就是利用程序取代人工，往更精細(xì)化控制方向控量。
基于這樣一個(gè)思路，筆者開始探索機(jī)器學(xué)習(xí)方面的預(yù)測(cè)技術(shù)，想象著有規(guī)律、有特征，就有一定的預(yù)測(cè)的可能性。跟股票不同，雖然CDN帶寬的影響因素也有很多，但是影響最大的幾個(gè)因素卻是顯而易見(jiàn)的。所以我們分析這些因素，先歸因，后提取特征和特征分解，預(yù)測(cè)閾值，預(yù)測(cè)各點(diǎn)的帶寬值。最終攻克了這一預(yù)測(cè)難題，實(shí)現(xiàn)了通過(guò)預(yù)測(cè)技術(shù)來(lái)調(diào)節(jié)CDN帶寬峰谷問(wèn)題。
2.3 降本思路的由來(lái)
說(shuō)到降本增效，作為技術(shù)開發(fā)，首先想到的就是利用技術(shù)取代人工，利用程序提升大家的工作效率。比如：自動(dòng)化測(cè)試、自動(dòng)化點(diǎn)檢、自動(dòng)化監(jiān)測(cè)歸類告警等等，不管哪個(gè)團(tuán)隊(duì)都不少見(jiàn)。甚至自動(dòng)化代碼生成器，提升大家的編碼效率，都已經(jīng)孵化了大量平臺(tái)。
下面，分析一下我們降本增效的主要思路。
筆者主要負(fù)責(zé)的技術(shù)模塊偏應(yīng)用分發(fā)，涉及的成本方向有：CDN帶寬成本、存儲(chǔ)成本、主機(jī)成本。相對(duì)于CDN的巨大成本，存儲(chǔ)成本和主機(jī)成本部分，少量業(yè)務(wù)的體量微不足道。至此，我們最合適的方向是往CDN成本方向突破。
CDN成本方向有兩個(gè)細(xì)分方向：降低帶寬體量、提升帶寬利用率。
小結(jié)：
降低帶寬體量復(fù)雜度高，基于當(dāng)前情況，如果能夠自動(dòng)預(yù)測(cè)帶寬，并且做到自動(dòng)化控制，可以大幅度提升帶寬利用率，達(dá)成顯而易見(jiàn)的降本效果。并且企業(yè)CDN費(fèi)用越高，降本收益顯著。
三、“踏踏實(shí)實(shí)”搞預(yù)測(cè)
確定目標(biāo)之后，該專題最初是放在“個(gè)人OKR目標(biāo)里”里緩慢推進(jìn)的。本章，筆者跟大家聊聊我們最主要“預(yù)測(cè)方向”的探索思路。
3.1 帶寬預(yù)測(cè)探索
我們的探索期主要分兩個(gè)階段。前期主要是圍繞：觀察→ 分析 → 建模 開展，類似于特征分析階段；后期主要是進(jìn)行算法模擬→算法驗(yàn)證，選擇效果相對(duì)滿意的算法，繼續(xù)深入分析探索，深挖價(jià)值，研究算法最終突破可用的可能性。
3.1.1 觀察規(guī)律
如圖是我司三大項(xiàng)目今年7月1日~7月31日 的帶寬走勢(shì)圖（數(shù)據(jù)已脫敏）：
可以觀察出一些比較明顯的規(guī)律性：
3.1.2 成因分析
我們的帶寬會(huì)走出如此趨勢(shì)，跟它的影響因素有關(guān)，下面列出了“顯而易見(jiàn)的”一些影響因素。
3.1.3 模型拆分
了解帶寬成因之后，我們主要的研究方向?yàn)椋簷C(jī)器學(xué)習(xí)、殘差分析、時(shí)間序列擬合等方向。然而，最終契合我們的預(yù)測(cè)模式是：閾值時(shí)間序列預(yù)測(cè)、帶寬實(shí)時(shí)預(yù)測(cè)模型。從最初探索到最終成型，我們的模型探索也是多次轉(zhuǎn)變方向，逐漸變得成熟。
3.2 算法關(guān)鍵
【最近數(shù)據(jù)】雖然CDN廠商沒(méi)法提供實(shí)時(shí)帶寬數(shù)據(jù)，但是卻可以提供一段時(shí)間之前的數(shù)據(jù)，比如15分鐘之前的帶寬數(shù)據(jù)，我們簡(jiǎn)稱之為最近數(shù)據(jù)。
基于最近的帶寬數(shù)據(jù)，我們嘗試結(jié)合延期數(shù)據(jù)和歷史數(shù)據(jù)之間的關(guān)系，納入模型，研究出一種自研的算法（主要周期單位為周），進(jìn)行實(shí)時(shí)預(yù)測(cè)。
下圖（數(shù)據(jù)已脫敏）是納入最近數(shù)據(jù)之后的一周預(yù)測(cè)擬合效果。并且，區(qū)別于殘差學(xué)習(xí)對(duì)突變點(diǎn)的敏感，我們的模型預(yù)測(cè)主要問(wèn)題出在帶寬轉(zhuǎn)折點(diǎn)，只要處理好轉(zhuǎn)折點(diǎn)的帶寬模型即可讓算法效果得到保障。
我們自研算法的核心思路：
算法的注意事項(xiàng)：
四、“兢兢業(yè)業(yè)”做愚公
假設(shè)你已經(jīng)能夠較為精準(zhǔn)的預(yù)測(cè)帶寬（標(biāo)準(zhǔn)是：特殊突變點(diǎn)之外，方差5%以內(nèi)），那么真正要投產(chǎn)其實(shí)還有很多細(xì)節(jié)要做，你可能會(huì)一些面臨模型優(yōu)化的些許問(wèn)題 或者 技術(shù)處理的問(wèn)題。
下面，我們主要講講我們《愚公平臺(tái)》處理從預(yù)測(cè)到控量的一系列方案，并針對(duì)落地實(shí)踐問(wèn)題，我們做了些說(shuō)明，讓大家少走彎路。
4.1 我們的落地方案
總體上，我們方案的最終目標(biāo)還是降本，降本思路是基于計(jì)費(fèi)模式。我用一句話概括了我們的方案，如下圖，預(yù)測(cè)藍(lán)色線、控制陰影區(qū)，最終壓低藍(lán)色線，也就是我們的計(jì)費(fèi)帶寬，從而達(dá)到如圖的降本效果。
4.2 愚公平臺(tái)的實(shí)踐思路
如下圖，愚公平臺(tái)的核心思路可以概括為：
- 通過(guò)離線模型預(yù)測(cè)明日的閾值
- 使用自研模型，實(shí)時(shí)預(yù)測(cè)未來(lái)一段時(shí)間的帶寬值
- 結(jié)合閾值與預(yù)測(cè)值，算出一個(gè)控量值
- 控量值寫入令牌桶，每秒生成令牌給端側(cè)消費(fèi)
4.2.1 使用Prophet預(yù)測(cè)閾值
首先是閾值預(yù)測(cè)，基于之前做帶寬預(yù)測(cè)的時(shí)候也研究過(guò)prophet預(yù)測(cè)，所以最終選擇其作為閾值預(yù)測(cè)的核心算法。其時(shí)間序列特性配合突變點(diǎn)的識(shí)別非常契合我們的場(chǎng)景，最終的效果也是非常優(yōu)秀的。
如下圖（數(shù)據(jù)已脫敏），除少量特別突發(fā)點(diǎn)以外，大部分閾值點(diǎn)基本上落在預(yù)測(cè)范圍內(nèi)。
最后，閾值預(yù)測(cè)本身是一種時(shí)間序列預(yù)測(cè)模型，網(wǎng)上也有較多的類似的選型方案，我們使用prophet預(yù)測(cè)閾值，并且我們也設(shè)計(jì)了閾值自適應(yīng)模型，自動(dòng)擴(kuò)充帶寬閾值，可以一定程度降低閾值偏離風(fēng)險(xiǎn)。所以，我們使用的閾值一般是體量閾值，結(jié)合其自適應(yīng)特性，加上一些干預(yù)手段，可以極大的保障我們的調(diào)控效果。
4.2.2 使用自研算法預(yù)測(cè)帶寬
這部分內(nèi)容在預(yù)測(cè)部分已經(jīng)有較為詳細(xì)的介紹，這里就不再贅述。總體上，還是用最近的帶寬，結(jié)合歷史走勢(shì)，擬合出未來(lái)一段時(shí)間的帶寬走勢(shì)，從而預(yù)測(cè)未來(lái)短暫的帶寬走勢(shì)。
4.2.3 子模型解決調(diào)控問(wèn)題
這里主要是針對(duì)預(yù)測(cè)之后的數(shù)據(jù)，到控制數(shù)據(jù)之間的轉(zhuǎn)換，做一些細(xì)化處理。對(duì)突發(fā)、邊界、折算、干預(yù)等問(wèn)題給予關(guān)注，需要根據(jù)業(yè)務(wù)實(shí)際情況做分析和應(yīng)對(duì)。
4.2.4 流控SDK問(wèn)題
研究發(fā)現(xiàn)，許多業(yè)務(wù)可能都存在可控制的帶寬，基于此，我們統(tǒng)一做了一個(gè)流控SDK。把更多帶寬納入管控，控制的帶寬體量越大，帶來(lái)的效果相對(duì)會(huì)更好。這里的SDK本質(zhì)還是一種令牌桶技術(shù)，通過(guò)此SDK完成所有帶寬的統(tǒng)一控制，可以大幅度減少各個(gè)業(yè)務(wù)處理帶寬問(wèn)題的煩惱。
4.3 精細(xì)化控制能力
閾值預(yù)測(cè)之后，到最后控量，期間存在較大的轉(zhuǎn)換關(guān)系，可能還需要進(jìn)一步思考和優(yōu)化才能讓帶寬利用率得到較大的提升。本節(jié)例舉了我們遇到的挑戰(zhàn)，針對(duì)我們流控問(wèn)題，做了些例舉，并做了些分解說(shuō)明。
4.3.1 多CDN數(shù)據(jù)源問(wèn)題
一般公司會(huì)對(duì)接多家CDN，各家CDN分配一定的量級(jí)，部分CDN不提供最近數(shù)據(jù)的拉取能力，或者對(duì)頻率限制太嚴(yán)重，導(dǎo)致數(shù)據(jù)拉取困難。我們的解決思路：找一家比例相對(duì)尚可 且 數(shù)據(jù)拉取相對(duì)配合 的廠商， 用他們的數(shù)據(jù)和比例反推公司總帶寬，減少對(duì)其它CDN廠商的依賴。
注意：因?yàn)楣緲I(yè)務(wù)多，小業(yè)務(wù)不支持多CDN比例調(diào)控能力，會(huì)導(dǎo)致這個(gè)比例存在波動(dòng)，波動(dòng)太大的情況下會(huì)導(dǎo)致調(diào)控失真，會(huì)導(dǎo)致你的利用率受損。
4.3.2 大小文件引起帶寬控制不準(zhǔn)
限流時(shí)，一般只能控制開始下載，但是一旦開始下載，不知道什么時(shí)候才會(huì)下載完成。小文件，下載耗時(shí)較短，控制精準(zhǔn)度較高。（常見(jiàn)的小文件、小資源下發(fā)等。）大文件，如系統(tǒng)升級(jí)包，3G的包，下載可能要一小時(shí)以上，控制下載開始是會(huì)出問(wèn)題的。下載時(shí)長(zhǎng)引起的長(zhǎng)尾會(huì)讓你絕望。
我們的解決思路：
- 思路一：對(duì)于這種特別大的文件 但是 流量及時(shí)性要求不高的，拆分到粗控模型中（可以理解成全局控制那一套思路）。用小文件做精控。精控使用預(yù)測(cè)模型，對(duì)整體帶寬做進(jìn)一步補(bǔ)充。
- 思路二：對(duì)大文件的下載進(jìn)行拆分，假設(shè)拆成100M， 每下載100M都請(qǐng)求一下流控服務(wù)器。 這里復(fù)雜度較高，依賴于客戶端改造，作為一種思路考慮。
4.3.3 流量折算問(wèn)題
其實(shí)也是流量長(zhǎng)尾引起的，你控制每秒可以下載100個(gè)文件，每個(gè)文件100MB， 那么就是10000MB/s的帶寬，實(shí)際上由于下載是連續(xù)的，這一秒并不會(huì)完成下載，實(shí)際跑出來(lái)的流量沒(méi)這么多。
我們的解決思路：存在流量折算系數(shù)，就是你控制3Gbps，實(shí)際上打滿之后只有2Gbps，這里需要手動(dòng)設(shè)置一個(gè)折算系數(shù)，方便進(jìn)行流量更精準(zhǔn)的控制。
注意：這個(gè)折算系數(shù)因?yàn)榘w的大小存在波動(dòng)，會(huì)導(dǎo)致你的利用率受損。
4.3.4 邊界長(zhǎng)尾問(wèn)題
一般情況下，邊界在凌晨， 就是每天一計(jì)費(fèi)。而昨天23:59，往往是大家的帶寬低估，你如果控制了非常多的帶寬（假設(shè)因?yàn)樽蛱煊型话l(fā)，導(dǎo)致你控制放量10Tbps），剛好流量又足夠，這個(gè)流量可能會(huì)因?yàn)殚L(zhǎng)尾問(wèn)題，到今天00:01才放完。因?yàn)榱髁刻^(guò)龐大，導(dǎo)致今天的計(jì)費(fèi)帶寬在凌晨形成巨峰。
我們的解決思路： 對(duì)邊界點(diǎn)之前的一些點(diǎn)進(jìn)行特殊控制。比如：23:50~ 23:59， 使用明天的峰值進(jìn)行控量。
4.3.5 突發(fā)應(yīng)對(duì)問(wèn)題
這里主要是指模型識(shí)別的突發(fā)，比如數(shù)據(jù)顯示20分鐘之前帶寬驟增，那么根據(jù)模型你其實(shí)已經(jīng)可以根據(jù)這個(gè)突發(fā)識(shí)別到當(dāng)前的帶寬是在高位行走，且因?yàn)橼厔?shì)的問(wèn)題，帶寬預(yù)測(cè)出一個(gè)較高的值。我們的解決思路： 根據(jù)總的增長(zhǎng)值(或者增長(zhǎng)值占比)， 或者增長(zhǎng)速度（或者增長(zhǎng)速度占比）， 或者增長(zhǎng)最大步長(zhǎng)（每分鐘增長(zhǎng)最大的數(shù)據(jù)） 考慮作為判斷突發(fā)的方式，采取突發(fā)應(yīng)對(duì)方案。
有人也發(fā)現(xiàn)了，上文講過(guò)的，部分突發(fā)是預(yù)測(cè)不了的，我們是怎么應(yīng)對(duì)來(lái)減少損失呢？
① 小突發(fā)預(yù)留閾值空間
比如預(yù)測(cè)目標(biāo)閾值是2T，可能會(huì)放1.8T作為閾值，這樣就算有短暫的突發(fā)，帶寬突到2T，也在我們的目標(biāo)范圍內(nèi)。預(yù)留的0.2T就是我們給自己留下的退路，我們的目標(biāo)也從來(lái)不是100%的帶寬利用率，這部分預(yù)留就是我們要犧牲掉的帶寬利用率。并且，當(dāng)帶寬突到更高峰值之后，這部分預(yù)留值要合理配置。
②大突發(fā)收集統(tǒng)一接入
怎么定義大突發(fā)？有些業(yè)務(wù)，比如游戲發(fā)版、微信發(fā)版，涉及包體很大、涉及用戶很廣。只要發(fā)版，必定引起大突發(fā)，這種只有大業(yè)務(wù)才能引起的較大帶寬突變，這就是大突發(fā)。如果這個(gè)突發(fā)走勢(shì)非快，可以嘗試控制速度，壓一壓這個(gè)走勢(shì)（在我們第一階段的帶寬利用率優(yōu)化其實(shí)已經(jīng)做的不錯(cuò)了）。如果壓成了緩慢突發(fā)，我們模式是可以識(shí)別到趨勢(shì)，做好應(yīng)對(duì)，至此，大突發(fā)就不是問(wèn)題。反之，壓不了的大突發(fā)，一下突增300G以上，迅雷不及掩耳之勢(shì)突上去的，模型來(lái)不及調(diào)整，我們建議直接讓類似的行為接入控制系統(tǒng)，讓控制系統(tǒng)提前挖坑應(yīng)對(duì)。
③容易突發(fā)的區(qū)段，帶寬放量少放一些，犧牲一些量，來(lái)做防御
有些時(shí)段，比如晚高峰，就是容易突發(fā)，不是這事就是那事，總會(huì)出現(xiàn)意想不到的突發(fā)，建議直接壓低閾值，本來(lái)閾值2T，直接控制一個(gè)時(shí)段壓到1.5T。這0.5T就是對(duì)系統(tǒng)的保護(hù)，畢竟只挖一個(gè)時(shí)段，在其它時(shí)段把堵住的流量放出去就好，整體影響還好。
4.3.6 驟降不降問(wèn)題
根據(jù)模型預(yù)測(cè)驟降（歷史規(guī)律導(dǎo)致的），你知道這個(gè)點(diǎn)的帶寬趨勢(shì)是降低，并且有一些常規(guī)降低的降低數(shù)據(jù)。然而，實(shí)際可能沒(méi)有降低那么多，最終因?yàn)檎{(diào)控問(wèn)題可能會(huì)引起新峰值。
基于這個(gè)問(wèn)題，我們的解決思路：定義驟降場(chǎng)景和驟降識(shí)別規(guī)律，對(duì)驟降點(diǎn)做特殊標(biāo)記，處理好驟降帶寬的放量策略，避免引入新峰值。
4.3.7 手動(dòng)干預(yù)處理
部分特殊場(chǎng)景，比如，大型軟件，可以預(yù)料到量級(jí)非常大，或者大型游戲預(yù)約（如：王者榮耀）更新。這部分可以提前知道突發(fā)。
我們的解決思路： 提供突發(fā)SDK接入能力和后臺(tái)錄入能力，對(duì)部分容易突發(fā)的業(yè)務(wù)，提供突發(fā)上報(bào)SDK，提前上報(bào)數(shù)據(jù)，方便模型做出突發(fā)應(yīng)對(duì)。
比如：根據(jù)帶寬體量，歷史突發(fā)場(chǎng)景規(guī)律，建模擬合出突發(fā)峰值，在突發(fā)期間，降低閾值；在突發(fā)前，提升閾值。
4.3.8 特殊模式：周末&節(jié)假日模式
節(jié)假日不同于平時(shí)的帶寬走勢(shì)，會(huì)存在幾個(gè)明顯的規(guī)律：
- 大家不上班，可控帶寬明顯偏少
- 突發(fā)點(diǎn)往早高峰偏移
我們的解決思路：針對(duì)節(jié)假日單獨(dú)建模，分析節(jié)假日的帶寬走勢(shì)。
4.3.9 閾值自適應(yīng)調(diào)整問(wèn)題
如果按閾值一成不變，那么突發(fā)之后，用之前的閾值會(huì)造成大量的帶寬浪費(fèi)。
我們的解決思路：設(shè)計(jì)閾值增長(zhǎng)模型， 如果池外帶寬峰值突破閾值，或者總帶寬超過(guò)閾值一定比例，則考慮放大閾值。
4.3.10 帶寬權(quán)重問(wèn)題
在CDN競(jìng)爭(zhēng)激烈的時(shí)代，由于用戶習(xí)慣，導(dǎo)致白天帶寬使用較多，而夜間帶寬使用較少。所以部分CDN廠商支持了分段計(jì)費(fèi)方案，這就意味著我們?cè)谟行r(shí)間段可以多用一些帶寬，有些時(shí)間段需要少用一些帶寬。
我們的解決思路： 此方案是基于分段計(jì)費(fèi)， 所以需要設(shè)置不同時(shí)段的帶寬權(quán)重，即可保障帶寬模型平滑運(yùn)行。當(dāng)然，分段之后，會(huì)出現(xiàn)新的邊界問(wèn)題，邊界問(wèn)題需要重新應(yīng)對(duì)解決。
4.4 技術(shù)問(wèn)題
本節(jié)基于我們使用的技術(shù)，對(duì)大家最可能遇到的技術(shù)問(wèn)題做些說(shuō)明。
4.4.1 熱點(diǎn)key問(wèn)題
由于接入業(yè)務(wù)方多，且下載限流經(jīng)過(guò)的流量巨大，可能是每秒百萬(wàn)級(jí)的，這里必然存在一個(gè)問(wèn)題就是熱點(diǎn)key問(wèn)題。我們通過(guò)槽與節(jié)點(diǎn)的分布關(guān)系（可以找DBA獲取），確定key前綴，每次請(qǐng)求隨機(jī)到某個(gè)key前綴，從而隨機(jī)到某個(gè)節(jié)點(diǎn)上。從而把流量均攤到各個(gè)redis節(jié)點(diǎn)，減少各個(gè)節(jié)點(diǎn)的壓力。
下面是我們的流控SDK，LUA 腳本參考：
4.4.2 本地緩存
雖然解決了熱點(diǎn)key的問(wèn)題，但是真正流控控到0的時(shí)候（比如連續(xù)1小時(shí)控到0），還是會(huì)存在大量請(qǐng)求過(guò)來(lái)，特別是客戶端重試機(jī)制導(dǎo)致請(qǐng)求更頻繁的時(shí)候，這些請(qǐng)求全部都過(guò)一遍L(zhǎng)UA有點(diǎn)得不償失。
所以需要設(shè)計(jì)一套緩存，告訴你當(dāng)前這一秒 流控平臺(tái)沒(méi)有流量了，減少并發(fā)。
我們的解決辦法： 使用內(nèi)存緩存。當(dāng)所有節(jié)點(diǎn)都沒(méi)有流量的時(shí)候，對(duì)指定秒的時(shí)間，設(shè)置一個(gè)本地緩存key，經(jīng)過(guò)本地緩存key的過(guò)濾，可以大幅減少redis訪問(wèn)量級(jí)。
當(dāng)然，除此之外，還有流量均衡問(wèn)題，客戶端的流量在1分鐘內(nèi)表現(xiàn)為：前面10s流量很多，導(dǎo)致觸發(fā)限流，后面50s沒(méi)什么流量。
這種問(wèn)題我們服務(wù)端暫時(shí)還沒(méi)有很好的解決辦法?？赡苄枰藗?cè)去想辦法，但是端側(cè)又較多，推起來(lái)不容易。
4.5 最終效果
如圖是除權(quán)之后的帶寬走勢(shì)。從圖中可以看出，使用《愚公平臺(tái)》調(diào)控帶寬，CDN帶寬利用率顯著提升。
五、寫在最后
本文主要講述了《愚公平臺(tái)》從研究到落地實(shí)踐的歷程：
- 結(jié)合業(yè)務(wù)，選擇了CDN降本方向作為技術(shù)研究方向。
- 觀察規(guī)律，選擇了Prophet作為離線閾值預(yù)測(cè)算法。
- 算法突破，自研出擬合算法作為實(shí)時(shí)預(yù)測(cè)算法。
- 持續(xù)思考，思考應(yīng)對(duì)模型中的問(wèn)題及持續(xù)優(yōu)化方案。
- 最終，從技術(shù)的角度，為公司創(chuàng)造巨大的降本收益。
