作者:胡济麟

1、背景介绍

1.1 直播业务特点

互联网视频直播是一种消息媒介形态,提供时产时消的内容,经过多年,已经发展出秀场、游戏、电商、体育等多种业务形态。主要特点是:内容实时产生实时消费,对时效性要求更高;流媒体内容占用带宽大,对网络质量要求更苛刻;一人生产、多人消费,带宽规模大。直播 CDN 目前是解决这种大规模分发场景最有效的技术途径,主要特点是就近接入以提供良好的接入网环境,多层汇聚以降低中心资源的分发压力,以此达到直播业务规模化和时效性的要求。

1.2 直播 CDN 面临的困难

由于直播业务本身对于质量和时效性的要求,CDN 就需要在短时间内要找到并建立一条完整可靠的传输链路,对于链路稳定性有一定的要求。传统依赖于旁路更新的、基于链路质量的策略,寻路算法简单,不消耗太多时间,时效性有保障。但随着成本压力越来越大和可用性的要求越来越高,基于链路质量的策略的缺点就逐渐体现出来:

一个是这种旁路策略第一策略时效性上存在一定的延迟,延迟大约 2-3 分钟,对于偶发性的质量恶化或资源偏压无法快速做出相应的策略调整;

第二是基于一套统一的链路质量数据,无法兼顾资源能效,对于一些能效低的内容无法基于成本考虑做出相应的寻路策略调整,对浮动成本的控制不够精确。

1.3 解决方案

基于资源信息、链路状态、流媒体信息等多维度数据,精确计算每一路流的分发效能,将计算粒度精确到流一级。通过对能效、质量的综合计算,为每一路流动态计算接入和回源策略是解决困难的关键。

图 1. 干系方

调度系统通过收集、结合资源信息、链路状态、流媒体信息等,对直播接入和寻路进行控制,快速精确的调整策略,提供质量优先、成本优先、质量成本平衡等多种策略,对于在质量指标评价体系下提升分发系统的可用性和能效比提供更加精准和细粒度的控制。

  • 内容平台:内容平台的核心目的就是提高质量,只有提高质量流量才有保障,一套精细化的调度系统,能够做到精确接入,提升网络覆盖的准确度,快速处理短时故障,降低流量流失风险。
  • CDN:CDN 主要目标是提高质量,降低成本。调度系统能够精确控制接入网准确度,提高接入质量,对流量进行精细化调度,提高资源复用率,降低浮动成本,进而执导建设规划,降低固定成本。

2、主要问题及挑战

2.1 时效性的要求

  • 接入调度要求对业务阻塞时长不超过 50ms
  • 寻路调度要求全路径上阻塞时长不超过 50ms
  • 流媒体信息同步延迟不超过 100ms
  • 设备信息、网络质量同步延迟不超过 10s

2.1.1 调度延迟控制

延迟不超过 50ms,考虑到公网的网络本身的传输延迟,基本上不会有多余的时间进行其他系统调用和计算,需要预先准备好响应的策略,并且调度接入位置要尽量靠近调用侧。设计了策略推送、策略缓存、异步更新三种功能。

  • 策略推送功能在资源调度系统生成好调度策略之后,通过推送方式直接推送到接入层,接入层不主动调用其他系统,直接使用推送的调度计划返回给业务方,接入层没有业务处理延迟。
  • 策略缓存功能在接入层收到推送调度计划之后做内存缓存,本地不落磁盘,只有推送或者异步更新触发缓存更新,调度请求直接返回缓存数据。
  • 异步更新是在接口主动定时向资源调度发起请求获取调度数据,防止推送失败。

2.1.2 信息同步延迟控制

由于流媒体信息同步延迟要求 100ms,考虑公网网络传输的延迟,定时采集上报的方式无法满足延迟要求,采用事件触发实时 API 上报的方式同步数据。设备信息、节点信息为接口调用方式取回,对于时效性要求不高,采用任务分派机制,防止数据重复取回。

  • 事件触发在开始、停止等事件边沿上,同步调用 API 上送流媒体信息,保障流媒体信息同步的及时性。
  • API 直连触发后端业务处理,不再经过中间件,节省中间件处理延迟。
  • 任务分派机制将数据查询任务通过 MQ 分派给不同的服务实例,每个实例在认领完任务之后负责将数据取回。

2.2 可用性要求

  • 客户之间互不影响
  • 询源调度和接入调度互不影响
  • 响应异常退化策略保障

2.2.1 接口可用性

隔离

用户隔离

  • 客户一般采用 id 来区别身份,部分大客户可能有独立的接入域名。以 id 和域名为维度,部署独立的计算资源,防止单个客户访问对全体客户造成影响。
  • 考虑到成本和可用性,大客户除了独立部署资源外,还需要在常规集群中也部署相应功能,提供主备资源保障。

业务隔离

  • 回源调度和接入调度的业务方不同,对调度的响应能力和异常处理方式也不相同,调度失效的影响范围和收益也不相同。因此按照业务方进行隔离,内容平台和 CDN 分别在不同的接入实例上,方便对单个业务进行扩展,也可控制业务异常影响范围。

限流

当系统负载过高时,保护系统服务,提升系统恢复速度,降低系统负载,需要对系统业务流量进行限制。

熔断

并发熔断

  • 系统中存在很多接口调用的场景,比如统一接入调用资源调度接口获取调度计划,资源调度调用信息采集获取基础数据等。为保障后端业务服务稳定性,防止后端业务被突发增量打死,需要对后端业务并发数进行熔断,超过额定并发之后,不再允许调用后端接口,监控系统抛出异常,前端业务依据故障处理机制容忍一定的故障请求,超过容忍额度则退化到兜底策略。

失败率熔断

  • 后端业务可能短时处于不可用状态,降低后端业务在短时不可用时的请求量,能够加速后端业务恢复。当调用后端接口失败率高于阀值后,一段时间内不再调用后端接口,超过额定时间则继续探测后端业务可用性,直到业务恢复。

2.2.2 退化策略

无法在进行接入和询源调度服务时,需要退化为默认兜底策略,接入退化为 DNS 解析方式,询源退化为 CDN 固定询源策略,不再依赖调度系统做策略选择。

3、调度系统架构

3.1 业务架构

图 2. 业务架构

调度系统分为统一接入、运管平台、资源调度、信息采集、日志系统五个部分。

  • 统一接入:为内容平台提供中心化标准接入能力。考虑性能及延迟消耗,为 CDN 的边缘实例、二级源实例提供下沉 agent 接入能力。
  • 运管平台:运管平台作为人工界面,主要提供配置能力和数据大屏。
  • 资源调度:资源调度作为调度系统的核心单元,依据多种输入条件,针对接入和询源两种业务模式,输出不同的调度计划。
  • 信息采集:信息采集作为数据底座,为资源调度提供必要的质量、能力、位置等输入信息。
  • 日志系统:日志系统提供时序化的记录方式用于记录调度信息,主要用于复盘和评价调度策略。

3.2 信息采集系统

图 3. 信息采集系统业务架构

信息采集系统作为调度系统的数据底座,主要功能是从运维系统收集设备资源情况、从业务系统收集流媒体信息,经过数据整合之后提供给资源调度使用。

信息采集系统通过主动定时调用运维系统接口采集设备运行数据,包括 CPU 使用率、内存使用率、磁盘 IO、网络 IO 等信息,用于评价设备的服务能力。采集节点带宽用量等信息,用于评价节点承载能力。

通过主动定时调用监控系统接口采集链路质量数据,包括 RTT,丢包率等信息,用于评价网络质量。

通过被动等待 CDN 业务实例上报流媒体资源位置、下行并发、卡顿率等信息,用于评价服务质量和服务收益。

这些信息被收集上来之后通过分类整合,按照节点、地区、运营商、业务形式等不同维度,形成服务能力、服务质量、服务收益的聚合数据。

聚合数据最终会通过查询接口提供给资源调度系统。

3.3 资源调度系统

图 4. 资源调度系统业务架构

资源调度作为调度系统核心业务模块,主要从信息采集收取必要调度依据,通过一套调度策略,输出调度计划提供给接入和询源业务。

资源调度系统主要通过运管平台将个性化调度配置信息落到资源调度系统。通过查询信息采集接口,查询所需要的服务能力、服务质量、服务收益等信息。通过匹配不同的调度策略,生成静态调度计划。

通过查询信息采集接口,查询流媒体资源位置及描述信息。通过匹配调度策略,生成动态调度计划。

最终调度计划会以接口方式提供给业务方使用。

3.4 技术架构

图 5. 技术架构

3.5 部署方案

图 6. 部署方案

直播CDN调度技术关键挑战与架构设计的更多相关文章

  1. 阿里云李刚:下一代低延时的直播CDN

    在上周落幕帷幕的多媒体领域技术盛会——LiveVideoStackCon音视频技术大会上,阿里云的高级技术专家李刚进行了<下一代低延时的直播CDN>技术分享.主讲人李刚,多年关注在CDN这 ...

  2. 5G 融合计费系统架构设计与实现(一)

    5G 融合计费系统架构设计与实现(一) 随着5G商用临近,5G的各个子系统也在加紧研发调试,本人有兴全程参与5G中的融合计费系统(CCS)的设计.开发.联调工作.接下来将用几篇文章介绍我们在CCS实现 ...

  3. 一面数据: Hadoop 迁移云上架构设计与实践

    背景 一面数据创立于 2014 年,是一家领先的数据智能解决方案提供商,通过解读来自电商平台和社交媒体渠道的海量数据,提供实时.全面的数据洞察.长期服务全球快消巨头(宝洁.联合利华.玛氏等),获得行业 ...

  4. 直播技术:从性能参数到业务大数据,浅谈直播CDN服务监控

    线上服务的有效监控和数据收集,一直是后端服务离不开的话题.直播作为一种经典的分布式系统,监控以及数据收集更是必不可少的工作.如何对海量的服务集群有效的监控和保活,又如何抓取集群中的碎片数据中来优化服务 ...

  5. CDN服务技术架构图

    前言 在博文中 解读大型网站的演变过程  浅谈 举家搬迁静态文件到CDN 博文中都有涉及CDN,这次我们来详细讲解下CDN的架构 简介 CDN是构建在网络之上的内容分发网络,依靠部署在各地的边缘服务器 ...

  6. fir.im Weekly - 揭秘直播移动 APP 技术实现

    2016年直播似乎无处不在,作为一个开发者也许需要补充下关于直播技术点.本期 fir.im Weekly 整理了一些开发者对于直播实践项目中的技术经验与直播技术架构分析等内容,还有一些关于 iOS . ...

  7. CynosDB技术详解——架构设计

    本文由腾讯云数据库发表 前言 CynosDB是新一代分布式数据库,100%兼容MySQL和PostgreSQL,支持存储弹性扩展,一主多从共享数据,性能更是超越社区原生MySQL和PostgreSQL ...

  8. 资源管理与调度系统-YARN的基本架构与原理

    资源管理与调度系统-YARN的基本架构与原理 作者:尹正杰 版权声明:原创作品,谢绝转载!否则将追究法律责任. 为了能够对集群中的资源进行统一管理和调度,Hadoop2.0引入了数据操作系统YARN. ...

  9. 架构设计:远程调用服务架构设计及zookeeper技术详解(下篇)

    一.下篇开头的废话 终于开写下篇了,这也是我写远程调用框架的第三篇文章,前两篇都被博客园作为[编辑推荐]的文章,很兴奋哦,嘿嘿~~~~,本人是个很臭美的人,一定得要截图为证: 今天是2014年的第一天 ...

  10. CTO、技术总监、首席架构师的区别

    2016年11月30日13:22:26[转] CTO.技术总监.首席架构师的区别 提升自已的能力,比如专业技术,行业发展趋势,技术发展趋势,协调能力,组织能力,管理能力等[技术总监] 需要从技术总监和 ...

随机推荐

  1. python 中matplotlib 绘图

    python 中matplotlib 绘图 数学建模需要,对于绘图进行简单学习 matpoltlib之类的包安装建议之间用anaconda 绘制一条y=x^2的曲线 #比如我们要绘制一条y=x^2的曲 ...

  2. python随机值生成的常用方法

    一.随机整数1.包含上下限:[a, b] import random #1.随机整数:包含上下限:[a, b] for i in range(10): print(random.randint(0,5 ...

  3. linux中awk命令详解(最全面秒懂)

    一:linux中awk命令 1.awk命令简介 AWK 是一种处理文本文件的语言,是一个强大的文本分析工具. 之所以叫 AWK 是因为其取了三位创始人 Alfred Aho,Peter Weinber ...

  4. 如何不编写 YAML 管理 Kubernetes 应用?

    Kubernetes 将自身边界内的事物都抽象为资源.其中的主要部分,是以 Deployment.StatefulSet 为代表的 workload 工作负载控制器,其他各类资源都围绕这些主要的资源工 ...

  5. Node.js躬行记(22)——Node环境升级日志

    公司之前所有的 Node 项目,其环境都是 8.9.4 版本,发布于 2018 年的一个比较古老的版本. 老版本有两个比较明显的问题: Node 高版本的特性和方法都无法使用. 有些第三方新版本的包无 ...

  6. Flink基础概念入门

    Flink 概述 什么是 Flink Apache Apache Flink 是一个开源的流处理框架,应用于分布式.高性能.高可用的数据流应用程序.可以处理有限数据流和无限数据,即能够处理有边界和无边 ...

  7. 第一个Django应用 - 第二部分:Django数据库配置,模型和后台

    汇总操作 注:polls为应用名 1.执行命令:python manage.py migrate,生成默认的数据库表等 2.修改应用的models.py文件,添加数据库表模型等 3.INSTALLED ...

  8. Jetbrains家的软件都可用的激活码-pycharm

    网址:http://vrg123.com/ 步骤: 1,关注下方的公众号 2,点击菜单中的"激活密钥" 3,点击进入,获得网站密钥 4,在网站上输入网站密钥,点击获取,即可获取激活 ...

  9. 生产管理ERP哪一款比较好?

    生产管理用的是MES,企业管理用的才是ERP,这个得弄清楚!如果要谈生产管理,每家工厂的区别.差异性更大,在工厂甲用得很好的管理系统搬到工厂乙,大概率水土不服,不是软件本身的问题,而是生产的产品.部件 ...

  10. 企业信息化建PLM系统、ERP系统、MES系统是单个逐步建设好,还是同时上比较好?

    企业信息化建PLM系统.ERP系统.MES系统肯定是单个逐步建设好啊,不仅仅是各个系统单独建设,系统内各模块的实施也应该先后逐步推进,切不可想着一口吃个大胖子,一股脑的全上,求全求快是很多系统实施失败 ...