找回密码
 立即注册
LiveVideoStack 首页 资讯 查看内容
  • QQ空间
  • 回复
  • 收藏

李浩:无限节点的CDN架构演进(1)

2018-6-22 08:00

本文来自网心科技首席架构师李浩在LiveVideoStackCon 2017大会上的分享,李浩回顾了从迅雷时代到网心科技,P2P CDN的演进,以及挑战和应对方案。


文 / 李浩

整理 / LiveVideoStack


大家好,我是来自网心科技的李浩,今天和大家分享一种新型CDN架构,汇聚家庭用户的闲置网络和计算资源构建的共享式CDN,整个过程会面临很多的技术挑战,下面会做些分析并介绍下解决思路。


我们的理想



我们希望通过共享的方式来降低企业计算成本,节约社会资源。共享经济的模式这几年发展很快,说实话迅雷当年搭建了一套业界最大的利用共享计算资源来做内容分发的网络,网心继承了迅雷的技术优势,想用一个更标准化的方式对外提供一套高性能和低成本的商用服务。


有调查显示现在生产出来的商品能10倍覆盖我们当前的需求量,包括带宽、存储、计算这些数字化产品和服务。Uber、Airbnb这类产品为什么能火起来,就是因为提供了所有权向使用权高效转移的途径,盘活了巨大的存量资源。我们的目标是盘活家庭用户拥有但很难完全使用的计算、存储和网络资源,使服务节点下沉在用户家中,在网络的最边缘提供实时的服务,第一个切入点就是CDN市场。


现实与挑战



从前两位嘉宾的分享可以看到CDN要做得事情很多,远不止缓存分发一件事情,需要提供一整套的多媒体传输、编解码、截图、存储、运营服务。我们要在该功能集上面把共享资源有效的用起来,更会碰到一些额外的挑战。首先,节点之间的连通性,如何在全球Nat设备分布最多的国家达到一个超高连通率。其次,波动场景的应对能力,质量波动相对来说好解决一点,容量波动是难题,IDC带宽容量是有保障的,但在家庭环境下,有很多应用在同时运行,多个家庭共享有限的小区带宽出口,无法保证稳定的资源容量和全局资源视图。同时,不同协议的传输优先级,多个家庭节点之间网络距离的精确测定,用IP判断无法达到小区级的精度,多端数据共享,提高流量放大比等问题都需要有效解决。


直播架构



以典型的直播场景来展开介绍。主播推流和回源拉流构成数据输入,输入数据以后CDN主要做两件事情,一个就是流数据处理,包括协议转换、转码、截图、转点播等;另一个是中转分发,其中最核心的是组网策略,我们通过玩客云节点做了一次末端流量放大,同样的由于链路增加一跳,组网复杂度指数级增加。为了达到更高的放大比,玩客云节点订阅直播流的一部分信息,SDK需要并行从多个玩客云节点获取编码的切片数据然后还原,封装为标准的http-flv、hls数据流给到客户端。最理想的情况下,对于1Mbps的热流,一个10Mbps上行能力的末端节点,由于数据编码和分片策略的存在,可以达到1000倍以上的放大比,带宽压力完全下移,远优于传统p2p方案。


架构实例



从数据流层面看,数据进入系统后,在IDC节点内部上行转发时会做多份拷贝,避免单链路的问题,因为这里是整条链路最脆弱的一环。下行主要是按需回源,但对热流和冷流做一些区分处理,冷流对CDN的需求是中转加速的需求,好比北京电信的一个主播在直播,全国就覆盖了十个观众,命中率和流量放大等指标基本没有意义,系统核算内部链路成本后不会使用到共享计算节点,最核心的诉求就是缩短中转加速路径。热流需要在内部分发路径上做冗余保障,数据分片配合编码纠错是一个不错的方式,同时尽可能使用共享节点来提高放大比,跳数带来的内部带宽完全可以消化。


内部组网架构



上面列出了我们内部组网的几次演进,最开始是固定的树状结构,根据运营商的拓扑结构,选定两到三个多线路BGP节点做为源,同时根据运营商拓扑结构选出区域中心点,例如华北、华东这些地域,组成一个比较清晰的三层架构。因为结构层级很清晰,路由都是按照预定好的规则去设置,便于研发和运营,一开始起步选这种结构,我觉得是合理的,但是到后面呢,就会发现,它很便于运营,但是它特别依赖于运营,需要运营人员对整体的网络拓扑结构非常了解。举个例子,假设核心源点一个选择了河南,一个选择了广州,那么你可能会出现问题,2015年底的时候,电信的京汉广骨干经常瘫痪,一瘫痪两个点全都不能用,我们需要知道中国的骨干链路是怎么建的,需要能支持这种骨干之间的容灾,是一个依靠人的强运营网络。


第二种方案是很自然演变过来的,把规划好的区域和源节点抽象成节点池,比第一种方案多一套路由系统。不再依赖之前设定的静态路由规则,假设之前设置的华东节点只能走华东和华北区域中心,现在可以通过一些探测算法来动态选择,我们有一些专利算法,例如eqv算法会通过丢包、重传、延时数据来和关键业务指标拟合,通过训练好的拟合参数来为每一条有基础网络数据的链路评分。其次影响路由的还有成本权重,本来回源北京节点是最快的,质量可能是98分,但是从山东走质量是95分,但是山东能直接命中,北京需要回源多一跳成本,那对于能接受95分质量的业务应该优先走山东。有了动态路由系统后,运营工作量大为减少,主要处理一些资源的缩扩、预知的网络割接等事项就行。


对已经在服务的链接根据路由系统指令,要避免乒乓效应带来的额外开销,就是切A切B切A切B这种场景。同时对直播来说很核心一点,要把数据给无缝的拼接起来,因为无法保证两个不同节点拥有同样的时间起点的数据流,在切换过程中如果上一个节点传到某一个编号的P帧,下一个节点就要跟着下一个P帧就往下去传,这里面可以通过特殊标记或者对帧做哈希的方式来拼接,保证路由生效过程中的观看连贯,否则会产生直播重放等问题很影响观看体验。


这个组网方案一开始非常好用,直到UGC直播火起来后逐渐碰到瓶颈。一些客户高峰会有上万路推流并发,在这种情况下,避免不了很多流是长尾流,长尾流在这种固定的网络层级下面确实会有跳数浪费,对只有两个人观看的,或者只有一个人观看的,仍然要走固定跳数。好比主播在山东推流,北京有一个用户观看,源设置在上海,整体路径就是山东到华北区域中心,再到上海,再后到北京,最后到用户,中间浪费的路径比你真正吐出去的这个带宽多好几倍的,而且可能质量还不如北京用户直接访问山东节点。因此这套组网方式在处理冷流上瓶颈是比较大的。


第三种其实是一种网状结构,但是不是无任何规则的网状结构,待会会详细讲一下规则策略,每一个主播都是一个数据源点,这个对冷流多的场景也非常友好,但是要把数据处理系统给独立开来,需要全局可访问的截图、录播、转码系统的支持难度会提升不少。


最后是我们针对热流、重点流的处理思路,内部分发类似SDK的处理方式是一样的,中间会做编码处理,像刚才有个同学去问Akamai是否会做编码处理,Akamai说因为他们的计算开销太大了没有做过多编码处理。看过13年Akamai出的一些论文,传输过程中会做一些简单正交编码配合简单纠错,把一路数据流拆分成三道去往上推。我们也是做编码处理,只不过我们内部编码处理分两种,一种是简单纠错,一种是复杂纠错,以复杂纠错为主。数据推过来以后,重点数据流编码后按照一定冗余度往上去推,一定的程度的丢包是可以克服的,尽量降低双向的数据交互来降低延时。下行通过无率码编码和分发,中间的节点不需要cache所有数据,下行节点通过多个点并行获取一定冗余度的码片并组合。对热流会分发到所有边缘节点的场景,带宽节省也很显著。


对冷流热流的处理



详细说一下冷流处理,我们的处理逻辑就是组建弱网状结构,根据一定的规则和跳数约束来构建的应用级的组播网。核心的路由系统采用etcd存储全量策略,每一个转发节点会有路由代理缓存部分数据并做一些主备线路的质量决策。对冷流逻辑就是降低跳数,减少中间损耗,上行是被动方式,没人观看的情况下数据就不要往上走。下行的主动路由查询,逻辑也是去提高命中率,这个点如果有数据且质量符合的情况下,不应该再去拓展一条新的路径。


根据数据源和观看分布会有几种场景:无人观看、同省同网、同网跨区等,最复杂的是跨网跨区,这种情况也可以在四到五跳到达,和树形结构的一般场景类似,所以真正在线上运营会发现针对UGC的流能节省一半的内部带宽。因为大部分的冷流,尤其是现在的移动直播,App端会用地理位置信息做主播和内容推荐,冷流的主播和观众很大概率在一个区域内。


热流也会依赖路由系统,对热流核心是快速获取到,尽量保证重要节点上已经存在该数据。因此不再做被动上行,会主动分发的,采取一倍以上的链路冗余。会存在冷热转换的过程,因此路由策略要及时刷新,热变冷暂时不考虑。


最后一跳的难点



最后一跳是共享CDN方案的差异化优势点,用SDK的模式把用户资源用起来,做一层毛细节点放大,通过无速率的信道编码来应对波动和实时性要求。传统的P2P方案数据是顺序强相关,主要靠节点间缓存数据的错时实现分享,延时和分享率互相矛盾,同时需要很多的双向交互和补片策略,无法达到很高的放大比。


我们采用运算复杂度较高的喷泉码方案,因为最后一层的共享节点,相对于20Mbps的平均带宽,4核Arm处理器的计算能力是远超的,对比服务器的万兆带宽和32核处理器。因此采用高复杂度前置编码算法非常合理,采用这种方式的数据码片每个都包含原数据的部分特征,像喷泉一样去往外喷,只需要接住一杯原始数据就解出来了。在这种情况下,基本不需要双向交互,采用订阅的模式,告知需要原始数据的比例,上行节点按照比例随机给出码片。


启播过程中通过服务器拿到首帧和音视频描述信息,同时找共享节点订阅,根据fps、cps指标来判断节点吞吐状态,流量逐渐倾斜至共享节点,如果节点资源不足,也可以逐渐倾斜至服务器节点,过程是平滑的没有硬切换。同时每个码片包含原始数据部分特征且不重复,因此从多个节点高并发获取实时数据是可行的,放大比可以很高,对于热流共享节点的1KB码片数据可以分享给上千个客户端。


要达到最高效率,共享节点端要支持全栈协议,同时支持rtmfp、data chanel、自定义,同一份数据可以提供个不同的客户端,C化rtmfp协议难度很高。


内部传输策略与难点解决



来自: LiveVideoStack
文章点评