跨国应用场景下网络的复杂性、不稳定和高丢包率对网络的实时性和流畅性提出了更高的挑战。本文是即构科技技术副总裁冼牛在LiveVideoStackCon 2018大会上的分享，深入探讨了实时网络调度系统的部署、架构设计、挑战和应对策略。由LiveVdeoStack整理而成。
文 / 冼牛
整理 / LiveVideoStack
大家好，我是冼牛，目前在即构科技主要负责实时音视频引擎的研发，专注于视频直播、视频社交和在线教育等领域。本次主要分享即构科技在出海构建全球网络的过程中遇到的问题和解决问题的方法和思路。
分享内容覆盖四个领域，分别是实时音视频和跨国应用场景，跨国实时网络的部署，跨国调度系统的架构设计，以及跨国调度系统的挑战和应对的方法。
1. 实时音视频和跨国应用场景
图中所列的几点摘自《36k研究报告》。互联网出海大多是因为趋势，图中列出了相关的一些背景和理由。人口红利的消退，技术的溢出，更关键的是国内的激烈竞争。而国外部分国家的互联网技术相对落后四到五年。
视频直播/视频社交-互联网出海应用场景
图中展示的是视频直播的其中一个应用场景，出海应用场景包括两类：一类是视频直播一类是视频社交。视频直播分两种，基础的是单向直播，没有互动，用户一般从CDN拉流，主播推流到比较好的资源里去做加速。第二种是连麦直播，连麦直播对技术的要求比较高，上面两张图截取自“花椒直播APP”。
实时音视频系统架构图
关于实时音视频系统架构图有两点需要说明。第一点是对于实时传输网络，我们要考虑其实时性和成本。综合考量后，对于实时的低延迟波动，我们会选择通过比较好的资源来支持实时的互动，使用UDP的私有协议，或者RTMP协议来支持，利用CDN网络进行大规模的分发也是其中比较经济的。另外一点就是需要支持目前所有主流的终端，但是每个终端的协议，音频编码的格式，视频编码的格式都不一样，如果不同的终端要通信，就要考虑是否需要互相转码，如果需要转码，就要考虑增加的成本，以及是否会带来延迟。
跨国在线教育微场景
跨国在线教育中最主要的场景有两种：一种是1对1的英语学习；另外一种是跨国小班互动教学。由于跨国的教育资源不平衡，在美国、英国有大量英语非常优秀的老师，但缺少教育的市场。而在中国则是有大量的孩子想要学英语，却没有足够优秀的英语老师，将他们连接起来，就需要跨国的实时传输网络。
跨国实时传输网络的挑战
想要实现跨国实时网络，我们就需要解决其中所遇到的一系列问题，包括RTP较大，网络不稳定，易掉线，丢包率高等等。此外，小班课存在的问题是：小班课的终端需要供多个学生同时上课。因为人数较多，如果这种互动课我们采取拉多流的方式，网络挑战非常大。除了前面提到的跨国，跨区域不稳定之外还存在的技术挑战就是，“就近接入”。就近接入采取的是查IP库的方式，但IP库往往是不准确的，特别是在国外。此外，网络故障的情况在中国经常出现，海外发生的频率更高。然后是容量控制，它指的是每个节点的容量（带宽资源，计算能力），需要对这些容量进行管理，避免某个节点容量过载。多协议互通，用户从多个终端连接到云端，每个终端有着不同的协议，多个协议之前需要互通（需要转码），这也意味着会产生大量成本。
跨国实时传输网络的策略
同一地区，我们会通过区域化部署的方式解决本地的一些通信问题。第一公里和最后一公里，我们采用就近接入，负载均衡的传输方式。中间的六个部分采取动态路由、动态回源的传输方式。我们比较有优势的传输方案是基于UDP的传输方案。在理想的网络状态下（不存在丢包，不存在抖动，带宽充足），RTMP与UDP的私有协议理论上差别不大；但在弱网情况下，UDP协议会具有更好的抗性。
2. 跨国实时网络的部署
图中展示的是即构在全球的服务器节点、CDN节点部署的情况，重点部署地点包括日本、韩国、东南亚、中东、东欧、西欧、美东和美西等，，节点资源相对密集的地方用户和需求也就相对较多。
跨国网络节点的部署流程
上图展示的是我们在海外新的区域部署节点时的流程，以及列举的市场上部分资源供应商。部署新节点的流程是：首先与当地或者国际的云商沟通，询问是否有当前节点的资源，如果有就选购这个资源，如果没有，就选择通过国际运营商购买资源，在选购资源时我们有一套方法对节点资源进行测试。当选购到比较好的节点资源后，部署时我们的软件系统是不用改动的，主要是对采购的硬件资源进行优化，然后部署。一般在节点资源到位的情况下，两天时间就可以完成。部署完成后，会对节点进行长期的优选，好的节点保留，不好的淘汰。经过长期的运营，积累下来的都是比较优质的节点，同时也积累了大量的运营数据，这些运营数据可以支撑我们在选路，动态回源时进行更好的决策。
3．调度系统的架构设计
跨国实时网络的拓扑图
上图是跨国实时网络的拓扑图，其中基本包括了四类实体，一类是用户终端；第二类是普通的媒体节点；第三类是调度中心；第四类是服务节点。在整体设计逻辑中，我们要遵守的第一个原则是尽量保证每个节点设计简单，这就可以使得调度策略也相对简单。遵循简单的原则，我们把调度中心独立出来，转码服务的节点也独立出来，每个蓝色媒体节点的功能基本上就相当于一个SFU，进行传求证的功能，不进行复杂的处理。
服务器节点和调度中心的工作机制
图中展示的是蓝色的服务器节点和调度中心之间的服务机制。流媒体的服务节点会定期的以秒/毫秒的级别向调度中心上报负载的情况。负载的情况包括负载中进出流的输入带宽，以及CPU的负载情况，容量和注册流的信息。每个节点将信息上报给调度中心，调度中心就可以根据这些信息进行决策，调度。那么调度中心能够给流媒体服务器提供什么样的帮助呢？流媒体服务器可以向它查询对应回源的策略，另外调度中心还可以帮流媒体节点调整指令，如某个节点过载，或者光纤刮断了，路线需要重新调整，这个调整路径的策略决定是由调度中心决定的，它通过调整指令告诉这个节点该如何进行处理。
单点调度模式（成本优先）
这里简单介绍一下我们的调度模式，它分为两种，一种是单点调度模式；一种是多点调度模式。单点，简单来说就是推流到某个节点，拉流也从那个节点进行。这种模式有两个好处，第一节省成本；第二传输的节点越少，延迟就越少。所以从延时的角度来考虑，一般来说，同一个城市我们会采取单点调度的模式。当然单点调度模式也有其弊病，如中国和美国的用户通话，如果采取单点调度的模式，而节点设置在中国，让美国的用户从中国拉流基本是行不通的。对于这种情况我们有一些后备方案，如果单点拉流体验不好，达不到要求怎么办？如果是因为容量不足，负载能力不够，我们会在同一个机房利用其它的节点来进行负载。同机房内的节点间，互相拉流是免费，没有成本的，而且同一个机房的计算资源可以支撑这个负载；如果是因为不同的ISP，网络之间通讯有问题导致体验不好，可以通过BGP节点作为中转。BGP结点在不同的运营商网络里有不同的IP地址，这样就可以解决跨网通信的问题。如果还是没有办法解决，我们还会有全局网络节点来保障其可用性。
多点调度模式
多点调度模式其实是为了解决单点调度模式中存在的问题。多点调度模式遵循的哲学是体验优先，成本其次。上面所展示的针对国内的不需要中转的场景，简单来说，比如北京的用户流推到A节点，会到调度中心注册说明推流到了A结点，调度中心了解掉A节点流的存在。当深圳节点的用户需要拉流观看，会就近接入节点C询问调度中心如何拉取终端1的流，调度中心会指示从节点A拉流，这样整个调度过程就完成了。这是动态回源的方式。
但是对于两个节点分别在国内外的情况，由于存在的通信问题，需要在中间增加一个中转节点。通过中转节点往往会使延迟降低，流畅性提高。
第一公里&最后一公里
第一公里和最后一公里，从调度的角度来说，它们是一样的。简单的逻辑就是，当你向调度中心询问应该从哪推流或者拉流，调度中心就会告诉你答案。在这里我们遵循两个原则，第一是就近，另外是要考虑负载均衡。当用户在推流的时候，会询问调度中心应该向哪一个节点推流，调度中心会给出多个选择。这一系列的选择存在优先级，首先会考虑到成本，人为的偏好等多种因素。这些选择主要是通过查IP库，根据用户所在地域，运营商进行分配的，可能会存在一些问题，用户也会通过测速来选择最优的节点接入。对于负载均衡，我们采取两个策略，一个是预售票的策略，举个例子，假设一个节点，如果告诉所有的调度中心这个节点有三百路下行的推流能力，每个调度中心都会将这三百路用完，也就会因为重叠而导致节点挤爆。我们的做法是将三百路分成三份，每个调度中心的手里只有一百个名额，这样每个调度中心都不会用超。万一发生资源分配用超的情况，则会在事后进行重定向，也就是对应的第二种策略。
节点之间传输
对于节点之间的传输，前面有提到区域性的部署，也就是分布式部署。包括了调度中心要在各个区域有所部署；服务节点负担转码的工作，它也需要在各个区域有所部署。调度中心要做动态的回源和全局的调度，必须要监控整个网络链路的健康性，每个节点的容量。并且必须要遵循最短的原则，原因是其成本最低且对应路距短，延迟也会最低。之后还要考虑质量的评估，也就是指事后评估。在运营一段时间以后，积累了一定量的数据，我们会根据这些数据分析某个时间段推流时节点效果。在动态回源的过程中也会主动的做一些实时的测速，根据测速的结果综合考虑动态回源的决策。
4. 调度系统的挑战和应对
就近接入-IP库问题
关于调度系统挑战的应对，首先看第一个问题，即IP库的问题。第一公里或者最后一公里在就近接入的时候，我们采取传统的方法是查IP库。但是查IP库的方式存在一些问题，因为通过查IP库得到的信息不是实时的，是查询时的最终结果，可能已经发生改变。这种情况在国内约有10%概率会发生，而在国外的几率会更高。那么解决这个问题的方法是，调度中心通过查IP库得到结果后，同时返回若干个选择给客户端。客户端获得选择后会主动测速来验证调度中心所给的结果。
负载均衡-容量控制的问题
第二个问题是容量控制的问题，前面有提到过一些方法，一个是通过预售票的方式，另外则是重定向的方式。接下来将介绍这两个方法是如何解决问题的。我们通过多个参数、多个维度来衡量每个节点的容量，测量流的数目就可以反映CPU的运算能力，码率用来考量网卡的吞吐能力，还有CPU的占有的百分比，另外一个就是纯音频的场景和语音视频要分成不同的网络来处理，因为音频和视频的码率不是一个量级的。
智能选路-网络故障的问题
在网络故障的情况发生时，我们会进行路线重新调度，如果要能够实时的重新调度另外一个路线，就必须存在多个备用方案。在接入回源时，为了能够准备多个接入的选择，调度系统需要对整个网络有全局的监控才能够动态的调整路由。
智能选路-跨区域不稳定的问题
关于跨区域不稳定的问题，跨区域指的是不同的区域，不同的国家之间是靠进出口光纤通讯的。进出口光纤资源是稀缺的，共享的，并且存在很多不稳定的情况。为了解决这个问题，我们的出海领域的客户里大部分还是区域化的业务场景，所以我们在每个区域部署当地的调度中心，转码服务器，多条路线的热备。
智能选路-跨区域调度
跨区域调度还存在另外一个问题，用上图的场景来解释，当深圳的用户与纽约的用户之间通话的时候，这里是采用了多节点调度的方式。从流程上来说，在纽约的用户推流出去之前会询问美东的调度中心应该推流至哪个节点？美东的调度中心会回复它推流到节点A。当节点A存在流之后，如果有需求，节点A 就可以将流贡献出去。深圳的用户要跟纽约的用户进行通话，在拉流之前会询问华南的调度中心要从哪个节点进行。由于是区域化部署，所以就存在美东调度中心，华南调度中心，当华南调度中心不知道纽约用户的流在哪时，它有两种方法。一种是广播询问纽约用户的流在哪，每个调度中心都会收到这个询问，当美东调度中心知道后会回复它用户流在节点A，这样深圳的用户回源到节点A拉流。另外一个方式是纽约的用户通过房间里面的信令告诉深圳用户这个流在节点A，华南的调度中心可以告诉他从美东调度中心查询，那么最终深圳的用户可以通过节点D回源到节点A拉流。
多协议互通-转码的问题
这是最后要讨论的一个问题，在最开始展示的实时架构图里显示了支撑不同的接入的终端，比如微信小程序、WebRTC浏览器，安卓、iOS，甚至有非WebRTC H5页面的。不同的终端是使用不同的协议进行通讯的，流媒体的封装格式也不一样。那么不同终端之间的通信就需要转码。但是转码，包括解码、重新编码会增加延迟，消耗资源，增加复杂度。于是我们采取三种应对的方式，第一种是被动转码的方式。举个场景来说，如果有安卓和iOS两个用户间通话，两种终端所用的协议，编解码格式都是一样的，那就不需要转码。如果这时有第三个人再进这个房间跟这两个用户聊天，并且是用网页版加入进来的。网页版是通过WebRTC的浏览器来支持通话的，网页版的WebRTC的通信是RTP和RTCP，音视频格式为H.264/OPUS，2、微信小程序上支持RTMP标准协议，音视频格式为H.264/AAC，这里就需要进行转码，只有在有用户要进来，必要的时候再进行转码，这就方式叫做被动转码。
转码的服务之间要独立，比如WebRTC的服务器当作一个子集群，RTMP的协议包括小程序等都要独立一个集群来运营。我们的私有网络也有另外一个大的集群。我们有两张大的私有网络，一张是支持RTMP协议的网络，另外一个是基于UDP协议的网络。具有这三张不同的独立的小集群就可以提高效率，降低成本。最后展示的是不同终端之间的转码关系。
