大规模实时流媒体服务网络架构演进.docx
- 文档编号:28173477
- 上传时间:2023-07-09
- 格式:DOCX
- 页数:11
- 大小:98.46KB
大规模实时流媒体服务网络架构演进.docx
《大规模实时流媒体服务网络架构演进.docx》由会员分享,可在线阅读,更多相关《大规模实时流媒体服务网络架构演进.docx(11页珍藏版)》请在冰豆网上搜索。
大规模实时流媒体服务网络架构演进
大规模实时流媒体服务网络架构演进
2016-08-02卜赫InfoQInfoQ
InfoQ
微信号infoqchina
功能介绍有内容的技术社区媒体
“本文根据七牛资深布道师卜赫在KVM社群里针对「大规模实时流媒体服务网络架构演进」做的分享内容整理而成。
从CDN到LiveNet
随着基础设施的升级,我们从文字时代演进到读图时代,又从读图时代演进到微视频时代。
人们对媒体载体的实时性,交互性的要求越来越高。
今年是Live时代的元年,直播App如雨后春笋,像极了几年前的千团大战、O2O大战、P2P金融大战,成为互联网的又一场战役。
∙什么是内容分发网络
∙内容分发网络的链路路由
∙内容分发网络的扩容
∙内容分发网络的安全
∙回归本质:
LiveNet
∙LiveNetVSP2P网络
为什么要有内容分发网络,其由来是?
互联网起源于美国军方的一个内部网络,TimBerners-Lee是互联网发明者之一,他很早就预见到在不久的将来网络拥塞将成为互联网发展的最大障碍,于是他提出了一个学术难题,要发明一种全新的、从根本上解决问题的方法来实现互联网内容的无拥塞分发,这项学术难题最终催生出一种革新性的互联网服务--CDN。
当时Berners-Lee博士隔壁是TomLeighton教授的办公室,一位麻省理工学院应用数学教授,他被Berners-Lee的挑战激起了兴趣。
Letghton最终解决了这个难题并开始自己的商业计划,成立了Akamai公司,成为世界上第一家CDN公司。
内容分发网络的架构
上图是一个典型的CDN系统的三级部署示意图,节点是CDN系统中的最基本部署单元,分为三级部署,中心节点、区域节点和边缘节点,最上面一级是中心节点,中间一级是区域节点,边缘节点地理位置分散,为用户提供就近的内容访问服务。
下面介绍一下CDN节点的分类,主要分成两大类,骨干节点和POP节点,骨干节点又分为中心节点和区域节点:
∙骨干节点
▪中心节点
▪区域节点
∙POP节点
▪边缘节点
逻辑上来讲,骨干节点主要负责内容分发和边缘节点未命中时进行回源,POP节点主要负责提供给用户就近的内容访问服务。
但如果CDN网络规模较大,边缘节点直接向中心节点回源会给中间层的核心设备造成的压力过大,在物理上引入区域节点,负责一个地理区域的管理,保存部分热点数据。
内容分发网络的种类
∙网页加速
∙视频加速
∙文件传输加速
∙应用协议加速
∙直播加速
内容分发网络主要分为以上几种,我们简单介绍一下:
网页加速
网页是比较早出现的互联网信息载体,也是CDN支持的最早的一种加速服务,开始主要是对静态网页、图片等等进行加速,发展到现在也可以对动态内容进行加速。
视频点播加速
随着基础网络的提升,单纯的图片和文字已经没办法满足大家的物流需求,于是涌现了大量的视频网站,CDN应对这种需求开发了针对流媒体视频的加速网络,做出的技术改变,主要是改变原有PULL模型为PUSH模型,缩短了用户访问时间,避免视频流媒体的冷启动,也降低了对树形网络拓扑结构中的根节点的压力(骨干节点)。
文件传输加速
主要支持了很多常见的文件下载协议,如FTP、HTTP、P2P等,同时像七牛这种云存储厂商会支持层次更高的对象存储服务,CDN也内建在其中,对用户无感知加速。
应用协议加速
推出了HTTPS加速,HTTP网页压缩加速等,进一步缩短了用户访问时间,降低了源站的资源使用压力。
直播加速
随着Live时代的到来,直播成为当前CDN厂商的又一个主要的战场,那么Live时代CDN需要支持什么样的服务呢?
∙流媒体协议的支持,包括RTMP,HLS,HTTP-FLV等;
∙首屏秒开,从用户点击到播放控制在秒级以内;
∙1~3延迟控制,从推流端到播放端,延迟控制在1~3秒之间;
∙全球全网智能路由,可以利用整个CDN网络内的所有节点为某一单一用户服务,不受地域限制。
随着全球一体化进程不断推进,跨区域、跨国家、跨洲的直播正变为常态,很可能主播在欧美,而用户在亚洲;
∙天级别的节点按需增加,中国公司出海已成大势,CDN需要更多的海外节点,如今比拼的更多的是海外节点可以快速部署,从提出节点增加需求到节点入网提供服务,需要达到一天之内,对CDN运维和规划提出非常高的要求。
原有的月级别规划和入网满足不了先进的要求。
内容分发网络的链路路由
CDN基于树状网络拓扑结构,每一层都有GSLB(GlobalServerLoadBalancing)用于同一层内的多个CDN节点负载均衡,这样有什么好处呢?
前面提到的众多CDN的应用场景中,网页加速、视频加速、文件传输加速,都是同时依赖GSLB和Cache系统的,Cache系统是整个CDN系统中的成本所在,设计树形结构可以最大化的节省Cache系统的资本投入。
因为只有中心节点需要保持机会所有的Cache副本,先下逐级的减少,到了边缘节点只需要少量的热点Cache就可以命中大部分CDN访问请求,这样极大的降低了CDN网络的成本,也符合当是CDN用户的需求,可谓双赢。
但是到了Live时代,直播业务是流式业务,很少涉及到Cache系统,基本都是播完就可以释放掉存储资源,即使因为政策原因有存储的需求也都是冷存储,对于存储的投入相对非常低廉,而且不要求存储在所有节点中,只要保证数据可回溯,可用即可。
我们看看树状网络拓扑,用户的链路选择数量是有限的,如下图,用户在某一个区域内可选择的链路数是:
2*6=12
用户在某一区域内,则GSLB(通常在边缘节点这一层是SmartDNS)会把用户路由到该区域内的某个边缘节点,上一层又会路由到某个区域节点(这里的GSLB通常是内部的负载均衡器),最后又回溯到中心节点,中心节点会链接源站。
这里的假设是:
∙用户能访问的最快节点一定是该区域内的边缘节点,如果该区域没有边缘节点则最快的一定是逻辑相邻的区域内的边缘节点。
∙边缘节点能访问的最快节点一定是该区域内的区域节点,一定不会是其他区域的节点。
∙区域节点到中心节点一定是最快的,这个链路的速度和带宽都是最优的。
但实际真的如此么?
引入了如此多的假设真的正确么?
实际上就算理论上我们可以证明以上假设有效,但是节点规划和区域配置大都依赖于人的设计和规划,我们知道人多是不靠谱的,而且就算当时区域规划正确,谁能保证这些静态的网络规划不会因为铺设了一条光纤或者因为某些IDC压力过大而发生了改变呢?
所以我们可以跳出树状网络拓扑结构的桎梏,探索新的适合直播加速的网络拓扑结构。
为了摆脱有限的链路路由线路限制,激活整理网络的能力,我们可以把上述的节点变成网状网络拓扑结构:
我们看到一旦我们把网络结构改成了网状结构,则用户的可选择链路变为:
无向图的指定两点间的所有路径,学过图论的同学都知道,数量惊人。
系统可以通过智能路由选择任何一个最快的链路而不用依赖于系统部署时过时的人工规划,无论是某些链路间增加了光纤或者某个IDC压力过大都可以实时的反映到整理网络中,帮助用户实时推倒出最优链路。
这时我们可以去掉前面的一些假设,通过机器而不是人类来时实时规划网络的链路路由,这种实时大规模的计算任务天生就不是人类的强项,我们应该交给更适合的物种。
内容分发网络的扩容
前面提到中国公司的出海已成大势,CDN海外节点的需求越来越大,遇到这种情况需要CDN厂商在新的区域部署新的骨干网和边缘节点,需要做详细的网络规划。
时代发生变化,原来CDN用户都是企业级用户,本身业务线的迭代周期较长,有较长时间的规划,留给CDN厂商的时间也比较多。
而互联网公司讲究的是速度,双周迭代已成常态,这里面涉及到成本和响应速度的矛盾,如果提前部署节点可以更好的为这些互联网公司服务,但是有较高的成本压力,反之则无法响应这些快速发展的互联网公司。
理想情况是,用户提出需求,CDN厂商内部评估,当天给出反馈,当天部署,客户当天就可以测试新区域的新节点。
怎么解决?
答案是基于网状拓扑结构的对等网络,在网状拓扑结构中每个节点都是Peer,逻辑上每个节点提供的服务对等,不需要按区域设计复杂的网络拓扑结构,节点上线后不需要复杂的开局过程,直接上线注册节点信息,就可以对用户提供服务了,结合虚拟化技术前后时间理论上可以控制在一天之内。
回归本质:
LiveNet
我们知道最早的互联网就是网状拓扑结构,后来才慢慢加入了骨干网来解决各种各样的问题,我们是时候该回归本质,拥抱下一代Live分发网络:
LiveNet。
总结前面的讨论,我们发现Live时代我们需要的内容分发网络是:
∙对Cache的要求没有以前那么高
∙对实时性的要求非常高
∙对节点运维的要求高,要更智能,尽量减少人工干预
∙对扩容这种运维事件响应度要求非常高
要做到如上几点,我们需要:
∙去中心化,网状拓扑
∙全球全网调度
∙节点无状态,节点对等
∙智能运维
以上这些就是LiveNet设计时候的斟酌,让运维更自动化,系统运行高度自治,依赖机器计算而不是人工判断,下面分别介绍一下。
去中心,网状拓扑
网状拓扑结构是设计的根本和基础,只有看清了我们对Cache需求的降低,网状拓扑结构才更有优势。
全球全网调度
基于全球一张网,不在受限于区域网络调度,将调度的范围从区域网络扩展到全球,全网内的节点都可以响应用户的请求,参与链路路由,不再先由人工假设选定一部分节点进行路由,去掉人工干预,让整个系统更智能。
节点无状态,节点对等
LiveNet节点无状态和节点对等都方便了运维,去掉了区域概念后的全球一张网让整个拓扑结构变的异常复杂,如果各个节点间有先后依赖关系,势必让运维成为噩梦,需要专有的服务编排系统,同时也给扩容带来困难,需要运维人员设计复杂的扩容方案,需要预演多次才敢在复杂的网络拓扑中扩容。
当时如果节点本身对等且无状态,则运维和扩容都变的容易很多。
但整个系统在运行过程中还是会一些状态和数据需要保持,比如某些Live内容需要落地回放的需求,这些通过久经考验的七牛云存储来存储。
智能运维
智能运维建立在以上的「网状拓扑结构的对等网络」的基础上会变的容易的多。
可以方便的下线有问题的节点而不影响整个LiveNet网络,可以方便快速的上线新节点,提升系统容量。
通过节点的数据分析可以更好的了解整个网络的整体状态。
下面列举部分LiveNet采用的智能运维方案,让内容分发网络再次升级,以符合Live时代的要求。
∙监控节点健康状况,实时下线有问题的节点
∙Failover机制,保证服务一直可用
∙快速扩容
LiveNetVSP2P
最后我们和P2P网络做一个对比:
LiveNet
P2P
CDN
网状结构
网状结构
树状结构
对等网络
对等网络
异构网络
自有节点
混合节点,部分自有
自有节点
链路多,稳定
链路特别多,不稳定
链路少,稳定
扩容周期短
扩容周期短
扩容周期长
节点可管理性强
节点可管理性弱
节点可管理性强
节点质量好
节点质量参差不齐
节点质量好
我们发现P2P方案,节点的可控性和链路的稳定性上还有很大提升空间,比较适合在实时性要求不高的场景使用、适合长尾需求,在Live的场景下面多是对实时性要求比较高的重度用户,无法忍受频繁的FailOver和节点质量参差不齐带来的网络抖动,但是如果是文件分发就比较适合用这种混合方案,可以有效降低CDN厂商成本,利用共享经济提高资源利用率。
Q&A
Q:
计算最优路径是每个节点单独计算,还是由一个调度中心计算,然后将计算结果分发给所有节点?
当节点过多时,会不会占用太多的资源来计算最优路径?
A:
1)计算最优路径是调度中心计算的,我们做过测试和监控,计算最优路径不会占用太多资源,在可以接受范围内;
2)LiveNet专为Live时代而生,说的实在点就是为了直播场景做了定制的数据,而直播场景的数据都是即用即丢的。
Q:
CDN采用什么协议通信?
A:
主要是一些应用层的协议,在不同场景会使用不同的协议,比如直播就是RTMP和HLS等。
Q:
哪些公司应用了CDN?
A:
上规模的公司都会使用CDN。
目前使用LiveNet的公司也有很多,比如熊猫TV、咸蛋家等。
Q:
我想了解一下,这个各节点的数据同步如何保证实时,及如果一个节点故障,用户域名访问如何快速下线,是自己做的一套内部DNS吗?
A:
1)节点是无状态节点,不存在数据同步问题;
2)基于HttpDNS,如果HttpDNS不可用,降级为SmartDNS(SmartDNS就是根据用户的来路,自动智能化判断来路IP返回给用户,而不需要用户进行选择,比方一个企业的站点三个运营商的带宽都有:
电信、网通、移动,同样有三个来自不同运营商网络的访问用户,那电信访问企业网址的时候,智能DNS会自动根据IP判断,再从电信返回给电信用户;其他的也同理)
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 大规模 实时 流媒体 服务 网络 架构 演进