直播CDN调度技术关键挑战与架构设计

作者：胡济麟

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. 部署方案