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

摘要：为了处理解决这个问题，需要提高海外直播的接流覆盖率，并针对链路进行优化，从而有效降低整体从推流到拉流的卡顿率。

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

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

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

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

原因分析

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

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

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

解决思路

针对于这个问题，网易云通过自建 CDN 源站节点来处理这种场景，因为用户上行节点推流一般网络状况都不一样，有WiFi、4G，我们需要通过自建 CDN 先把主播的流接过来，然后再通过自建的 CDN 和回国链路之间进行中间一公里的一些优化，来彻底解决这个问题。但是部署节点也有一个比较麻烦的问题，就是成本和性能，如果选择了一个源站覆盖密度非常高，这个时候用户体验肯定会好很多，但是你的成本也就特别高，而且你的主播也并不是一定会用到所有的节点，容易造成资源的浪费；相反，源站覆盖密度比较粗，那主播的问题就很有可能并没有得到解决，成本还是浪费了。

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

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

1、源站部署

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

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

2、智能调度

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

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

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

3、高可用覆盖

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

后续优化

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

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

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