vivo 互联网渠道产品研发团队 – Peng Zhong
跟着分发规划地逐步增加，各企业对CDN带宽的运用越来越多。而且，各类事务运用CDN的场景各式各样，导致带宽会不断地呈现骤增骤降等问题。依据本钱考虑，国内CDN厂商的计费形式首要用峰值点的带宽来计费，就算不用峰值点的带宽，也会因为峰值问题所产生的本钱而举高带宽单价。依据此，操控CDN带宽的峰谷具有重要意义，下降峰值就意味着本钱节约。
一、布景
伴跟着互联网地鼓起，许多企业都阅历过互联网粗野成长的一段年月。可是，在互联网市场逐步老练稳定之后，各大企业在事务上的增加速度逐步放缓，也纷繁开端“对内发掘本钱方面”的产出，对本钱做愈加精细化的管控，提高企业的竞争力。
特别是跟着“互联网寒冬”的降临，“凉气”传导到各行各业，“降本增效”的概念也纷繁被从头提起。有拉闸限电的，扣本钱扣细节；也有大规划裁人一刀切的，淘汰部分事务，紧缩人力；还有些团队直接组成横向团队，通过顶层思想，在不影响团队运作的状况下，专攻中心本钱技能难题，保证降本作用。
本文，依据作者在CDN带宽运用率优化方面的实践，跟咱们共享一下咱们的降本思路和实操方法。“降本增效”作为继续的立异方向，并不局限于某个部分，企业价值链的任何一个环节都或许会成为打破点。作为技能开发人员，咱们则更多的需求“从各自担任的事务方向出发”，对公司本钱有触点的事务进行剖析和发掘，针对性的从技能的视点出发，技能攻关，深化探究，降本增效，为公司带来实在价值。
通过本文，你能够：
1）打开思路，为**“降本增效”供给或许的考虑方向**，助力咱们发掘轻量化可是价值大的方针。
2）一览无遗，了解咱们CDN带宽运用率优化的中心方法。
名词解说：
【CDN】内容分发网络。
本文的CDN专指静态CDN，动态CDN首要是对路由节点的加快，带宽本钱规划相对小的多。浅显的解说：CDN厂商在各地部署了许多节点，缓存你的资源，当用户下载时，CDN网络帮用户找到最近的一个节点，通过这个节点用户下载速度大大提高。
【CDN带宽运用率】
带宽运用率=实在带宽/计费带宽，能够理解为投入产出比相同性质的东西。为何要提高运用率？打个比方：你不会愿意花一亿够买价值一千万的东西，假如你的运用率只需10%的话，你其实就做了这样一件不合逻辑的事。
- 【愚公渠道】通过带宽猜测和削峰填谷，大幅度提高企业总的CDN带宽运用率的渠道。
二、“寻寻觅觅”找降本
作为CDN的运用大户，在CDN带宽本钱指数级增加的状况下，笔者有幸见证并参加了我司CDN降本的每一个环节，从开端依据各自事务CDN带宽运用率的优化到后来依据可控带宽调控的思路。本章，咱们来聊聊咱们CDN降本的几个重要阶段，并跟咱们共享一下，为什么我会挑选CDN带宽运用率这一个方向去研讨？
2.1 CDN带宽计费形式
首要，不得不讲下咱们的计费形式，峰值平均值计费：每天取最高值，每月取每日最高值的平均值作为计费带宽。
月度计费=Avg(每日峰值)
该计费形式意味着：每日峰值越低，本钱越低。带宽的运用率决议了本钱。由此，咱们从未抛弃过对带宽运用率的追求，下面看看咱们都有哪些优化带宽运用率的阅历吧。
2.2 CDN降本三部曲
咱们CDN降本优化首要分为三个阶段。三阶段各有妙用，在其时的环境下，都有相当不错的战果。而且均是依据其时的状况，探究出来的相对合理的优化方向。
2.1.1 局部优化
局部优化是依据我司的首要CDN运用状况而产生的一种思路。作为手机出产制造厂商，咱们的静态CDN运用场景的中心事务是运用分发类，如：运用商铺app分发，游戏中心app分发，版别自升级分发。归纳一下，中心六大事务占有了我司带宽的90%以上，只需把这六大事务的带宽运用率提高上去，咱们的带宽运用率就能够得到显着的提高。
依据这样一个状况，CDN运维工经常找到中心事务，给一个带宽运用率的指标，让各事务把带宽运用率提高上去。归纳一下，**中心思路便是：找到中心CDN运用事务方、分别给他们定好各自的运用率指标、提需求任务、讲清楚优化的价值。**在这一阶段优化之后，咱们中心事务的带宽突发场景得到收口，全体带宽运用率显着得到提高。
2.1.2 大局优化
因为局部优化是各自事务优化，在许多突刺问题处理之后，各事务的带宽运用率优化会进入一个瓶颈区。其中，作用比较好的，单事务带宽运用率也很难打破60%，除非是特别的事务形式，带宽完全受控这种状况。此时，咱们事务把部分带宽抽离出来，用以调控公司全体带宽，进一步提高公司全体带宽运用率，咱们把他界说为大局优化阶段。
依据这样一个大局优化的思路，各个事务只需没有太大的突刺，总体带宽运用率就会得到一个较大幅度的提高。首要，咱们把带宽进行划分，抽取部分能够受服务器操控的带宽拆分为可控带宽，首要是工信部许可的wlan下载部分带宽；然后，咱们观测带宽走势，依据带宽前史走势，分离出各个时段的带宽数据，针对不同时段操控不同的带宽量级放量，终究达到一个“削峰填谷”的意图。此战略是通过阈值操控放量速度的，每小时设置一个阈值，以每小时阈值生成每秒的令牌数，进行令牌桶控量。
2.1.3 主动化操控
大局优化之后，作为技能开发人员，更进一步的方法便是运用程序替代人工，往更精细化操控方向控量。
依据这样一个思路，笔者开端探究机器学习方面的猜测技能，幻想着有规则、有特征，就有必定的猜测的或许性。跟股票不同，尽管CDN带宽的影响要素也有许多，可是影响最大的几个要素却是清楚明了的。所以咱们剖析这些要素，先归因，后提取特征和特征分解，猜测阈值，猜测各点的带宽值。终究霸占了这一猜测难题，完成了通过猜测技能来调节CDN带宽峰谷问题。
2.3 降本思路的由来
说到降本增效，作为技能开发，首要想到的便是运用技能替代人工，运用程序提高咱们的工作功率。比方：主动化测验、主动化点检、主动化监测归类告警等等，不管哪个团队都不少见。乃至主动化代码生成器，提高咱们的编码功率，都现已孵化了许多渠道。
下面，剖析一下咱们降本增效的首要思路。
笔者首要担任的技能模块偏运用分发，触及的本钱方向有：CDN带宽本钱、存储本钱、主机本钱。相对于CDN的巨大本钱，存储本钱和主机本钱部分，少数事务的体量微乎其微。至此，咱们最合适的方向是往CDN本钱方向打破。
CDN本钱方向有两个细分方向：下降带宽体量、提高带宽运用率。
小结：
下降带宽体量复杂度高，依据当时状况，假如能够主动猜测带宽，而且做到主动化操控，能够大幅度提高带宽运用率，达到清楚明了的降本作用。而且企业CDN费用越高，降本收益明显。
三、“踏踏实实”搞猜测
确认方针之后，该专题开端是放在“个人OKR方针里”里缓慢推进的。本章，笔者跟咱们聊聊咱们最首要“猜测方向”的探究思路。
3.1 带宽猜测探究
咱们的探究期首要分两个阶段。前期首要是围绕：调查→ 剖析 → 建模 开展，类似于特征剖析阶段；后期首要是进行算法模仿→算法验证，挑选作用相对满意的算法，继续深化剖析探究，深挖价值，研讨算法终究打破可用的或许性。
3.1.1 调查规则
如图是我司三大项目今年7月1日~7月31日 的带宽走势图（数据已脱敏）：
能够调查出一些比较显着的规则性：
3.1.2 成因剖析
咱们的带宽会走出如此趋势，跟它的影响要素有关，下面列出了“清楚明了的”一些影响要素。
3.1.3 模型拆分
了解带宽成因之后，咱们首要的研讨方向为：机器学习、残差剖析、时刻序列拟合等方向。可是，终究符合咱们的猜测形式是：阈值时刻序列猜测、带宽实时猜测模型。从开端探究到终究成型，咱们的模型探究也是屡次改变方向，逐步变得老练。
3.2 算法关键
【最近数据】尽管CDN厂商无法供给实时带宽数据，可是却能够供给一段时刻之前的数据，比方15分钟之前的带宽数据，咱们简称之为最近数据。
依据最近的带宽数据，咱们测验结合延期数据和前史数据之间的联系，归入模型，研讨出一种自研的算法（首要周期单位为周），进行实时猜测。
下图（数据已脱敏）是归入最近数据之后的一周猜测拟合作用。而且，差异于残差学习对骤变点的灵敏，咱们的模型猜测首要问题出在带宽转折点，只需处理好转折点的带宽模型即可让算法作用得到保证。
咱们自研算法的中心思路：
算法的留意事项：
四、“兢兢业业”做愚公
假定你现已能够较为精准的猜测带宽（标准是：特别骤变点之外，方差5%以内），那么真正要投产其实还有许多细节要做，你或许会一些面临模型优化的些许问题 或许 技能处理的问题。
下面，咱们首要讲讲咱们《愚公渠道》处理从猜测到控量的一系列计划，并针对落地实践问题，咱们做了些阐明，让咱们少走弯路。
4.1 咱们的落地计划
总体上，咱们计划的终究方针仍是降本，降本思路是依据计费形式。我用一句话归纳了咱们的计划，如下图，猜测蓝色线、操控阴影区，终究压低蓝色线，也便是咱们的计费带宽，然后达到如图的降本作用。
4.2 愚公渠道的实践思路
如下图，愚公渠道的中心思路能够归纳为：
-
通过离线模型猜测明日的阈值
-
运用自研模型，实时猜测未来一段时刻的带宽值
-
结合阈值与猜测值，算出一个控量值
-
控量值写入令牌桶，每秒生成令牌给端侧消费
4.2.1 运用Prophet猜测阈值
首要是阈值猜测，依据之前做带宽猜测的时候也研讨过prophet猜测，所以终究挑选其作为阈值猜测的中心算法。其时刻序列特性配合骤变点的辨认十分符合咱们的场景，终究的作用也是十分优异的。
如下图（数据已脱敏），除少数特别突发点以外，大部分阈值点基本上落在猜测范围内。
最后，阈值猜测自身是一种时刻序列猜测模型，网上也有较多的类似的选型计划，咱们运用prophet猜测阈值，而且咱们也规划了阈值自适应模型，主动扩大带宽阈值，能够必定程度下降阈值偏离风险。所以，咱们运用的阈值一般是体量阈值，结合其自适应特性，加上一些干涉手段，能够极大的保证咱们的调控作用。
4.2.2 运用自研算法猜测带宽
这部分内容在猜测部分现已有较为详细的介绍，这儿就不再赘述。总体上，仍是用最近的带宽，结合前史走势，拟合出未来一段时刻的带宽走势，然后猜测未来时间短的带宽走势。
4.2.3 子模型处理调控问题
这儿首要是针对猜测之后的数据，到操控数据之间的转换，做一些细化处理。对突发、鸿沟、折算、干涉等问题给予重视，需求依据事务实践状况做剖析和应对。
4.2.4 流控SDK问题
研讨发现，许多事务或许都存在可操控的带宽，依据此，咱们一致做了一个流控SDK。**把更多带宽归入管控，操控的带宽体量越大，带来的作用相对会更好。**这儿的SDK实质仍是一种令牌桶技能，通过此SDK完成一切带宽的一致操控，能够大幅度削减各个事务处理带宽问题的烦恼。
4.3 精细化操控才干
阈值猜测之后，到最后控量，期间存在较大的转换联系，或许还需求进一步考虑和优化才干让带宽运用率得到较大的提高。本节例举了咱们遇到的挑战，针对咱们流控问题，做了些例举，并做了些分解阐明。
4.3.1 多CDN数据源问题
一般公司会对接多家CDN，各家CDN分配必定的量级，部分CDN不供给最近数据的拉取才干，或许对频率约束太严重，导致数据拉取困难。咱们的处理思路：找一家份额相对尚可 且 数据拉取相对配合 的厂商， 用他们的数据和份额反推公司总带宽，削减对其它CDN厂商的依赖。
**留意：**因为公司事务多，小事务不支持多CDN份额调控才干，会导致这个份额存在波动，波动太大的状况下会导致调控失真，会导致你的运用率受损。
4.3.2 巨细文件引起带宽操控不准
限流时，一般只能操控开端下载，可是一旦开端下载，不知道什么时候才会下载完成。小文件，下载耗时较短，操控精准度较高。（常见的小文件、小资源下发等。）大文件，如体系升级包，3G的包，下载或许要一小时以上，操控下载开端是会出问题的。下载时长引起的长尾会让你失望。
咱们的处理思路：
-
思路一：对于这种特别大的文件 可是 流量及时性要求不高的，拆分到粗控模型中（能够理解成大局操控那一套思路）。用小文件做精控。精控运用猜测模型，对全体带宽做进一步补充。
-
**思路二：**对大文件的下载进行拆分，假定拆成100M， 每下载100M都恳求一下贱控服务器。 这儿复杂度较高，依赖于客户端改造，作为一种思路考虑。
4.3.3 流量折算问题
其实也是流量长尾引起的，你操控每秒能够下载100个文件，每个文件100MB， 那么便是10000MB/s的带宽，实践上因为下载是接连的，这一秒并不会完成下载，实践跑出来的流量没这么多。
咱们的处理思路：存在流量折算系数，便是你操控3Gbps，实践上打满之后只需2Gbps，这儿需求手动设置一个折算系数，便利进行流量更精准的操控。
**留意：**这个折算系数因为包体的巨细存在波动，会导致你的运用率受损。
4.3.4 鸿沟长尾问题
一般状况下，鸿沟在清晨， 便是每天一计费。而昨日23:59，往往是咱们的带宽轻视，你假如操控了十分多的带宽（假定因为昨日有突发，导致你操控放量10Tbps），刚好流量又足够，这个流量或许会因为长尾问题，到今日00:01才放完。因为流量过分庞大，导致今日的计费带宽在清晨形成巨峰。
咱们的处理思路： 对鸿沟点之前的一些点进行特别操控。比方：23:50~ 23:59， 运用明日的峰值进行控量。
4.3.5 突发应对问题
这儿首要是指模型辨认的突发，比方数据显现20分钟之前带宽骤增，那么依据模型你其实现已能够依据这个突发辨认到当时的带宽是在高位行走，且因为趋势的问题，带宽猜测出一个较高的值。咱们的处理思路： 依据总的增加值(或许增加值占比)， 或许增加速度（或许增加速度占比）， 或许增加最大步长（每分钟增加最大的数据） 考虑作为判别突发的方法，采取突发应对计划。
有人也发现了，上文讲过的，部分突发是猜测不了的，咱们是怎么应对来削减丢失呢？
① 小突发预留阈值空间
比方猜测方针阈值是2T，或许会放1.8T作为阈值，这样就算有时间短的突发，带宽突到2T，也在咱们的方针范围内。预留的0.2T便是咱们给自己留下的退路，咱们的方针也从来不是100%的带宽运用率，这部分预留便是咱们要献身掉的带宽运用率。而且，当带宽突到更顶峰值之后，这部分预留值要合理装备。
②大突发收集一致接入
怎么界说大突发？有些事务，比方游戏发版、微信发版，触及包体很大、触及用户很广。只需发版，必定引起大突发，这种只需大事务才干引起的较大带宽骤变，这便是大突发。假如这个突发走势非快，能够测验操控速度，压一压这个走势（在咱们第一阶段的带宽运用率优化其实现已做的不错了）。假如压成了缓慢突发，咱们形式是能够辨认到趋势，做好应对，至此，大突发就不是问题。反之，压不了的大突发，一下突增300G以上，迅雷不及掩耳之势突上去的，模型来不及调整，咱们主张直接让类似的行为接入操控体系，让操控体系提早挖坑应对。
③简单突发的区段，带宽放量少放一些，献身一些量，来做防御
有些时段，比方晚顶峰，便是简单突发，不是这事便是那事，总会呈现意想不到的突发，主张直接压低阈值，原本阈值2T，直接操控一个时段压到1.5T。这0.5T便是对体系的保护，究竟只挖一个时段，在其它时段把堵住的流量放出去就好，全体影响还好。
4.3.6 骤降不降问题
依据模型猜测骤降（前史规则导致的），你知道这个点的带宽趋势是下降，而且有一些常规下降的下降数据。可是，实践或许没有下降那么多，终究因为调控问题或许会引起新峰值。
依据这个问题，咱们的处理思路：界说骤降场景和骤降辨认规则，对骤降点做特别符号，处理好骤降带宽的放量战略，避免引进新峰值。
4.3.7 手动干涉处理
部分特别场景，比方，大型软件，能够预料到量级十分大，或许大型游戏预约（如：王者荣耀）更新。这部分能够提早知道突发。
咱们的处理思路： 供给突发SDK接入才干和后台录入才干，对部分简单突发的事务，供给突发上报SDK，提早上报数据，便利模型做出突发应对。
比方：依据带宽体量，前史突发场景规则，建模仿合出突发峰值，在突发期间，下降阈值；在突发前，提高阈值。
4.3.8 特别形式：周末&节假日形式
节假日不同于平时的带宽走势，会存在几个显着的规则：
-
咱们不上班，可控带宽显着偏少
-
突发点往早顶峰偏移
咱们的处理思路：针对节假日单独建模，剖析节假日的带宽走势。
4.3.9 阈值自适应调整问题
假如按阈值一成不变，那么突发之后，用之前的阈值会形成许多的带宽糟蹋。
咱们的处理思路：规划阈值增加模型， 假如池外带宽峰值打破阈值，或许总带宽超越阈值必定份额，则考虑放大阈值。
4.3.10 带宽权重问题
在CDN竞争剧烈的时代，因为用户习惯，导致白天带宽运用较多，而夜间带宽运用较少。所以部分CDN厂商支持了分段计费计划，这就意味着咱们在有些时刻段能够多用一些带宽，有些时刻段需求少用一些带宽。
咱们的**处理思路： 此计划是依据分段计费， 所以需求设置不同时段的带宽权重，即可保证带宽模型滑润运转。**当然，分段之后，会呈现新的鸿沟问题，鸿沟问题需求从头应对处理。
4.4 技能问题
本节依据咱们运用的技能，对咱们最或许遇到的技能问题做些阐明。
4.4.1 热点key问题
因为接入事务方多，且下载限流通过的流量巨大，或许是每秒百万级的，这儿必定存在一个问题便是热点key问题。咱们通过**槽与节点的分布联系（能够找DBA获取），确认key前缀，每次恳求随机到某个key前缀，然后随机到某个节点上。**然后把流量均摊到各个redis节点，削减各个节点的压力。
下面是咱们的流控SDK，LUA 脚本参阅：
//初始化和扣减CDN流量的LUA脚本
// KEY1 扣减key
// KEY2 流控渠道核算值key
// ARGV1 节点个数 30 整形
// ARGV2 流控兜底值MB/len 提早除好(防止渠道核算呈现推迟或许反常，设一个兜底值)，整形
// ARGV3 本次申请的流量（一致好单位MB，而不是Mb） 整形
// ARGV4 有效期 整形
public static final String InitAndDecrCdnFlowLUA =
"local flow = redis.call('get', KEYS[1]) " +
//优先从操控值里取，没有则用兜底值
"if not flow then " +
" local ctrl = redis.call('get', KEYS[2]) " +
" if not ctrl then " +
//兜底
" flow = ARGV[2] " +
" else " +
" local ctrlInt = tonumber(ctrl)*1024 " +
//节点个数
" local nodes = tonumber(ARGV[1]) " +
" flow = tostring(math.floor(ctrlInt/nodes)) " +
" end " +
"end " +
//池子里的值
"local current = tonumber(flow) " +
//扣减值
"local decr = tonumber(ARGV[3]) " +
//池子里没流量，返回扣减失败
"if current <= 0 then " +
" return '-1' " +
"end " +
//核算剩余
"local remaining = 0 " +
"if current > decr then " +
" remaining = current - decr " +
"end " +
//执行更新
"redis.call('setex', KEYS[1], ARGV[4], remaining) " +
"return flow";
4.4.2 本地缓存
尽管处理了热点key的问题，可是真正流控控到0的时候（比方接连1小时控到0），仍是会存在许多恳求过来，特别是客户端重试机制导致恳求更频频的时候，这些恳求全部都过一遍LUA有点因小失大。
所以需求规划一套缓存，告知你当时这一秒 流控渠道没有流量了，削减并发。
咱们的处理方法： 运用内存缓存。当一切节点都没有流量的时候，对指定秒的时刻，设置一个本地缓存key，通过本地缓存key的过滤，能够大幅削减redis访问量级。
当然，除此之外，还有流量均衡问题，客户端的流量在1分钟内表现为：前面10s流量许多，导致触发限流，后边50s没什么流量。
这种问题咱们服务端暂时还没有很好的处理方法。或许需求端侧去想方法，可是端侧又较多，推起来不简单。
4.5 终究作用
如图是除权之后的带宽走势。从图中能够看出，运用《愚公渠道》调控带宽，CDN带宽运用率明显提高。
五、写在最后
本文首要讲述了《愚公渠道》从研讨到落地实践的进程：
-
结合事务，挑选了CDN降本方向作为技能研讨方向。
-
调查规则，挑选了Prophet作为离线阈值猜测算法。
-
算法打破，自研出拟合算法作为实时猜测算法。
-
继续考虑，考虑应对模型中的问题及继续优化计划。
-
终究，从技能的视点，为公司发明巨大的降本收益。
《渠道产品》系列文章：
-
vivo渠道化实践探究之旅-渠道产品系列01
-
vivo霍金试验渠道规划与实践-渠道产品系列02
