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