【网易云信】海外推流部署实践

今天主要分享咱们海外直播链路优化的问题和解决问题的一个思路，介绍的主要流程，大概就是抛出一个问题，简单介绍咱们解决的思路，在这个过程当中碰到的一些问题和咱们具体进行的一些思考，以及后续能够再进行一些额外优化的处理。

指标定义

在介绍总体内容以前，首先定义一下咱们的性能指标，因为咱们暂时不考虑实时性，因此主要考虑的是卡顿率。卡顿指的就是观众在播放一个视频的时候，因为网络缘由，播放器缓冲区中没有接收到新的数据数据了，这个时候画面就一直转圈，而后一直等待新数据的到来，这时候就没法播放。

网易云对卡顿有两种衡量指标，一种是实时卡顿率，以秒级为单位，若是播放器缓冲区空了，这一秒就记为卡顿，总卡顿率的计算方法就是直播卡顿的秒数除以总直播秒数；可是一般咱们还会用另外一种卡顿率的指标，也是以秒级为单位，可是观察的不是单纯一秒以内的卡顿，咱们考虑的是连续两秒卡顿，这个时候用户会很是明显的感受到播放异常，此外，卡顿的出现通常也不会是跳跃式的卡顿，如第一秒卡，第三秒卡，第五秒卡这样，所以两秒内连续卡顿发生，咱们就标记整分钟卡顿，这个的总卡顿率就是一个直播卡顿的总分钟除以总的直播时间。通常来讲选择一分钟卡顿率这种指标会比较严格一点，由于它更能够直观反映出用户体验。

背景介绍

网易云提供了一个平台级融合 CDN 的服务，主要针对企业级用户提供解决方案，其中包括使用咱们的 SDK，或者绕过咱们的 SDK 直接使用推流器进行推流。咱们今天探讨的海外推流的问题，主要场景是咱们当时接入了网易新闻的业务，在联合开发的过程当中，发现当一些主播在国外进行推流，而观众倒是在国内的这种场景下，卡顿率就会很是的高，常常就在转圈，甚至有些就直接拉不到了，用户体验极差。为了处理解决这个问题，须要提升海外直播的接流覆盖率，并针对链路进行优化，从而有效下降总体从推流到拉流的卡顿率。

缘由分析

首先分析一下缘由，当直接使用 CDN 资源时，可是有些 CDN 厂商在国外是没有部署源站的，这个时候主播推流会直接传回国内源站，可是通常来讲主播的网络都不是特别好，国外链路到国内源站这段链路质量通常都是比较差的，此外因为 RTMP 流是基于 TCP 可靠传输的因此在链路不好的时候，TCP 反映会更剧烈，这样在主播到国内源站这一段时间内就已经发生很是大的一个卡顿，无论从国内源站到其的边缘节点延迟有多低，这个时候观众拉到的流必定都是卡的。

还有一种场景是部分 CDN 厂商在国外是有一些源站的，可是他们在源站和本身国内的节点之间没有进行相应的链路优化，这个时候从国外源站一直到下发到边缘节点的这一段过程，网络传输效果较差，至关于只是把主播到国内源站的这一段推流过程放到了网络传输的中间一千米，以上是出现问题的主要两种场景。

对于不一样的 CDN 厂商，有一些是有国外源站覆盖的，可是仍有一些 CDN 厂商跟国外主播是彻底没有办法接流的。对于有国外部署源站的厂商，若是覆盖率不够，不能知足客户分布需求的话，它只能解决一部分场景，好比解决一些比较热门的城市，可是这些热门城市并不必定是主播比较集中的地点，而主播集中的地点它反而可能没有办法彻底的覆盖到，这种场景下依靠 CDN 自身的源站能解决的卡顿问题是比较少的。

解决思路

针对于这个问题，网易云经过自建 CDN 源站节点来处理这种场景，由于用户上行节点推流通常网络情况都不同，有WiFi、4G，咱们须要经过自建 CDN 先把主播的流接过来，而后再经过自建的 CDN 和回国链路之间进行中间一千米的一些优化，来完全解决这个问题。可是部署节点也有一个比较麻烦的问题，就是成本和性能，若是选择了一个源站覆盖密度很是高，这个时候用户体验确定会好不少，可是你的成本也就特别高，并且你的主播也并非必定会用到全部的节点，容易形成资源的浪费；相反，源站覆盖密度比较粗，那主播的问题就颇有可能并无获得解决，成本仍是浪费了。

所以须要在成本和性能之间找到一个比较好的平衡点。咱们首先根据一年多以来的历史数据，进行分析，选择海外主播密度较高的几个主要区域进行必定规模数量的节点部署，完成后咱们须要针对这些节点进行相应的质量评估，评估这些节点是否有能力承载咱们的这些诉求。除此之外，咱们还能够进行一些相应的优化，好比说若是是使用一些第三方云服务云主机，咱们是能够用他们之间的一些专线来进行链路调度上额外的优化；最后一点是分布式系统必需要常常考虑的一个问题，就是节点的高可用。

这是咱们整个的流程图，主播要开始推流的时候，会先登陆云管理中心去请求一个推流列表，推流列表通过云调度中心去把这个推流地址转换成一个实际推流的源站 IP，云调度中心主要分红两块，一块是中心调度，是实时的，能实时监控全部的源站；还有一块是基于 DNS，由于网易云业务自己有很多第三方的推流用户，这种场景是不通过中心调度的，所以咱们须要拥有一个 DNS 调度中心，在这两个调度背后还隐藏着一个大数据平台，大数据平台在整个解决问题的过程当中发挥一个比较大的做用：全部的数据，包括推流和拉流，这些数据都会汇总到统计平台上，统计平台最后就会完成链路调度的选优。当主播获取到这个相应的IP之后，会推流到自建的海外 CDN 源站而后走回到国内源站，在国内还能够利用融合 CDN 的优点来经过不一样的 CDN 网络进行分发，便于不一样的观众从质量较好的边缘节点进行拉流观看。

一、源站部署

源站部署是自建 CDN 的第一步，主要是借用第三方云服务厂商的云主机。第一步就是要在成本和性能之间作一个平衡，首先，咱们利用统计平台去分析以前将近一年的全部主播推流的数据，好比 IP 分布和一些推流数据的测量，筛选出主播最经常使用的一些地点，并把源站按照这些地域的热度进行分布，并多选择一些节点做为备选，以便后面能进行一些更好的测评。在完成节点部署之后，就须要对这些节点进行测评，测评主要分为两部分：一部分是上行链路质量的测试，还有一部分是中间一千米传输的测试。在上行链路数据的收集，咱们额外花了三个月的时间专门用来对这些源站进行链路数据收集，首先先过滤掉一部分性能彻底都跟不上的节点，而后会在源站服务器上进行一个比较长时间的模拟推流，并在国内进行拉流，把全部数据汇总到了大数据平台，最后根据大数据平台上反馈的数据结果，结合上行数据，整合出一套调度方案。

这套调度方案不单纯是基于区域，也会额外考虑收集到的这些数据，并赋予必定的权重，好比说有些是属于比较偏远省份的边缘数据，能够对其进行一些额外的细化，根据调度数据选择最合适的调度点，不必定是物理上所属的那种区域概念。

二、智能调度

除了上面说的，咱们还能够依托于云服务厂商的一些专线服务，根据咱们本身部署在上面的一些测试脚本，对这些源站进行分级和分类，相似于 CDN 架构中的父节点和边缘节点，在这些节点之间根据它的分级进行一个级联型的调度，并测试级联传输效率，级联调度并不会形成额外的延迟，可是在合适的链路选择下传输优化效果很是明显，能够很是有效的下降相应的卡顿率。

这是新方案的流程，从主播推流再到中心调度这块跟前面都是同样的，惟一不一样的是在源站接入节点之后，并不会直接推到国内的源站，而会根据配置的调度方案，在图里面实线和虚线至关因而两套调度方案，咱们能够根据这两套调度方案它的性能进行评估，而后进行一个相应的选入过程，在选择一个最优质的链路调度之后，将它推回到国内源站，再经过咱们的融合 CDN 进行分发。

这张图是咱们总体评估出来的一个测试结果，测试结果上面来看：咱们的数据总体来讲已经比原来 CDN 厂商要好不少，大部分都能优化将近一半以上。

三、高可用覆盖

对于高可用来讲， GSLB 是一个实时调度方案，它能实时和全部的源站服务器进行保活，还有它相应的数据收集功能，所以它是能够作到实时高可用的。可是对于一些第三方的推流用户来讲，他们的 DNS 并不属于实时调度的，可能会有一些缓存，所以咱们须要对 DNS 覆盖下的全部服务器进行其余高可用方案，咱们主要采用的是 keepalived 方案，进行一个高可用的保证，keepalived 可使用多机器根据虚IP的漂移实现不一样机制之间的组配切换。

后续优化

固然咱们虽然作了这些，但其实后面还有不少要处理的东西，好比如今针对的产品是国外的推流用户和国内的拉流用户，但实际上还有一批用户，观众并不在国内，这个时候咱们仍是须要对下行链路进行一个相应的处理，使其能够直接从国外绕出去，并不须要从国内再特意走一圈。此外咱们还能够针对这种实时的链路质量进行更高精度的智能调度，咱们如今也有收集实时数据，但调度还不是很是实时的处理，咱们后续还能够根据这些链路数据进行一个比较实时的调度方案的智能选择。

---

随着音频处理和压缩技术的不断发展，效果更好、适用范围更广、性能更高的算法和新的技术必将不断涌现，若是你有好的技术或者分享，欢迎关注网易 MC 官方博客以及微信公众号：

关注更多技术干货内容： 网易云信博客
欢迎关注 网易云信 GitHub
欢迎关注 网易云信官网

官网微信公众号：