腾讯云海外直播系统架构是怎么设计的？

| 导语近期，在音视频及融合通信技术技术沙龙上，特邀请腾讯云技术专家胡仁成老师关于海外视频云直播系统架构中的实践案例的分享。

说到建设海外系统，我们要了解海外直播包含哪些，主要有三部分，第一，包括了公有云和网络基础设施的建设；第二，在此基础设施上我们架设软件系统，实现直播流媒体的分发；第三，我们在已完成的系统上更深入化的做好更多网络细节上的处理，包括跨区域的拉流等方面的优化，比如说精细化的调度，精细化到运营商实现调度。因此，海外直播系统在应用软件层面跟国内没有太大的区别，更多在弱网优化、调度优化等方面做一些精细化的工作。以下是具体的内容。

海外网络与机房建设

首先了解一下全球的网络态势，从这张图可以看出来我们在全球的网络布局从地域分为三大区，北美、亚太（中国香港、新加坡）、欧洲（德国）。其实海外运营商比国内多很多，国内说三大巨头电信、联通、移动再加小运营商。在海外大概接近2千家运营商。

那么我们如何去完成这2千家运营商的互联呢？不可能每家都拉一个专线到交换节点。我们肯定要去一个二八原则，比如说我们如何完成快速的80%的接入。

首先在全球的核心骨干网的BGP房，目前在美国铺两个点，一个是硅谷，一个是阿什本，在新加坡、法兰克福、荷兰、中国香港、印度、泰国、韩国、包括Q2在中国台湾会建设成功，Q4在阿联酋也会建设。

按运营商的级别可以划分为三类Tier1、Tier2、Tier3。Tier1是跨大区跨州互联的，Tier2是区域互联的，Tier3是国家内部覆盖，一般是面向终端用户提供网络服务的运营商，比如说中国澳门CTM。

骨干网核心节点主流的Tier1运营商进行大量采购，我们先买解决60%-70%的问题。Tier2也是花大量的钱买成本比较高，比如说腾讯会考虑对内容获取的接入质量，那这时候就会免费、降价。我们先买再谈再降价再免费。Tier3一般是主动找我们的，他是为了获取内容上的优质体验，会主动找到内容提供商进行免费的peer对接。

目前在全球我们跟很多的运营商合作，比如说Tier1比较著名的是Level（3）、西班牙电信，Tier2有中国电信这些，Tier3有印尼的indosat等这些都有合作。

海外目前加速点布局。我们服务更多地还是出海的用户，包括虎牙的NIMO TV，这些出海的用户的特点集中在东南亚或者是人口比较有优势的、人口红利的南美。腾讯布局在亚太比较密集。在欧洲和北美也部署了不少的点，在中东和非洲也做了一定的布局，但是我们预期在下半年在中东会有投入。

海外直播系统软件层面怎么设计

首先，根据直播的特点，直播是需要获取一个低延时、秒开、低卡顿，根据这个原则所有的流系统不能设置在一个地方，我们采取了一个去中心化的方案。在已有的DC的机房都会部署一个源站系统。

每一个源站会包含流媒体接入的能力，比如说RTMP接流。在这个上面部署转码能力，部署录制、截图、存储和CDN分发的源站的能力。

去中心化的设计方案好处肯定很多，第一个是直播，直播的特点是95%的人观看本地主播，不可能说中国人喜欢看英语，这是很少的，或者说你在南美用葡萄牙语言比较多，不可能中国人看葡萄牙语言。基于这种目的我们采用去中心化，主播的流推到最近的源站。

那么我们的状态如何实现同步？比如说巴西的主播推了流上来，中国的观众看的时候怎么样找到巴西主播的流在哪？怎么样设计这一套系统？挑战最大的就是同步的问题。

我们对状态系统设计要求第一个是双活；第二通过间隔心跳去保持数据同步的最终一致性，它有一个容忍的尺度和阈值，我们设置的是11秒，在11秒容忍它的待修正。当主播下播了发了一个RTMP delete过来，这个在传输链路上丢掉了如何处理？那么我们自研了一套状态组件。

除了这些工作以外，我们在状态同步的思想上根据95%的原则，我们在9个大的源站的状态并不是互相同步，其实意义不大。比如说美国的源站同步到中国真的有那么多人看美国的源吗？其实没有。我们挑选了集中点，把海外其他七个源站同步到中国香港，然后再从中国香港东部到中国大陆，那些小的源站如何去查？他们查一下中国香港就可以，这样减少了设计开发的复杂度。

这里还有一个小问题，状态同步的时候第一次推流可能推到A上面秒推秒下然后又秒推了，下一次落点不一定在同一台机器上，怎么修正状态就是ABA的问题。

去中心化设计又引入了另外一个问题就是如何实现跨区拉流，我真的是5%的人要看美国的流怎么办？这时候我们要保证这一整条链路的服务质量，状态一定要准；状态同步过去之后还要保证回源链路的问题性，在核心链路上去铺设回源专线，现在跨区回源都走腾讯云的内网专线。虽然成本高一点，我们要保证回源的稳定性。

这是一个标准化的一体化方案，这种方案的特点是双端用户自己控制，只要推RTMP流过来由腾讯自己分发，支持RTMP、DASH、HLS通过不同的码进行分发。

我们还支持用户自己的，比如说直播厂商有自己的能力建设自己的源站，自己转码，自己录制不需要腾讯，我们也提供了回源分发的能力，这个很快上到控制台上面给用户提供服务。也可以提工单进行线下对接。

海外另外一个特点是对版权保护的需求，腾讯云也提供了一个基于IOS和安卓系统级加密的DRM方案，Widevine和Fairplay。

网络细节上的处理

做了这套系统之后其实做并不难，系统做完了可能就完成了80分的工作。那如何做到95分、99分或100分？就在后期如何进行精细化的优化和运营，我们先看有哪些问题。

第一，调度。调度很复杂，你在一个国家跨省调度有的客户还不接受，为什么辽宁推流你调度到山东来了？我们目前基本上都是基于DNS调度，DNS调度里面有很多细节，比如说LDNS、ECS是否都能支持，开发者是否完整的考虑过这里面所带来的问题。

第二、单点故障。海外点很多，我不能每个点都储备2个T的带宽。有些小点我就部署了几台机器，那你过载了怎么办？

第三、海外回源的过程全是外网，我不能全部拉上专线。目前调研过没有哪一家能做到这样，AWS、谷歌他们也做不了，那就存在了外网丢包的问题。

第四、RTT问题。RTT就很大，那怎么办？这个问题我们接下来会有一定的解决方案来去做。

这些问题总体把它归结起来分三类，第一种是腾讯在直播海外系统自动化运维的能力、监控我们是如何做到的；第二我们如何去解决海外调度复杂度的问题，第三怎么解决第一个是回源的外网弱网传输问题，就是IDC之间相对复杂度还没有高，最后一公里边缘到用户侧，像印度、印尼、巴西国家基础设施相对比较差的，跟中国无法比。我们有一个客户就是分发游戏直播的，那我如何去对这种视频流怎么传输和优化，在这种情况下我如何做一些工作去优化。

全方位监控系统

突发我怎么去监控？比如说我能否在一秒以内或者五秒以内我能感知到某个业务流量突发，并且能够在增长的过程中能够自动化的扩展更多的服务节点或服务带宽去给它一个承载业务？我们具备这样的能力。去年有一个海外第二大电商，他们去年在双十一、双十二用直播答题的项目进行引流。在双十一、双十二期间拉流服务超过2千万次，带宽500多G峰值带宽。这也是基于服务和保障能力。

如何发现问题

需要你做更多的监控去发现网络问题、应用程序问题。我们的监控能不能精细到每个国家每个运营商的网断。AS号就是每个运营商有独立的AS号，我们能否能监控到AS号，然后看它的丢包率。我们根据监控找服务应用商，后找我们的团队去优化，这种基础服务能力要保障好。

应用层面的监控

有自动化的监控系统能够实时发现哪些机器上宕掉了，我们能否实时把节点剔除掉，我们具备这样的能力。对于这些监控系统和保障运维系统就体现了我们的服务稳定性。

接下来再讲一下调度的问题。看下面这个案例，这个用户用了我们的服务，他用的这张4G卡有一个特点就是中国电信和中国台湾远传合作的双通4G上网卡。他当时人在中国台湾经常到大陆出差，他拉腾讯的流非常卡，他经常拉到国内的节点，他走的就是默认的DNS调度。我们发现这边是DNS，那边是出口信息，他出口用的很多的是谷歌的Public DNS，客户端应该支持ECS的，用户把IP带过来了，但是中途有一些dns服务器不支持ECS信息，这时候由于运营商DNS服务提供不好，导致了很多国内的LOCAL DNS出口，识别到是国内的，所以识别它就是一个国内的用户，让他中国台湾直连到国内。我标红的就是支持ECS信息，这次调度是准确的能看到流畅的视频。这存在哪几种问题呢？

第一，Public DNS部分SERVER不支持ECS；

第二，Public Dns+多出口问题；

第三，Local DNS异常问题；

做这些工作是让腾讯给他提供最优的服务节点，我们在美国做了一次优化，以前在美国只能按区域，我们在美国有七个机房，东南西北、东北、西南和东南换了一个覆盖圈，这样的覆盖好还是不好？肯定是不好，因为它不是实时探测的结果，你最好是基于运营商的实时探测的结果。就是我哪个州到哪个州我调到哪儿是最优的，我们做了这个工作。从我们的探测结果来看，把美国的网络延时从64毫秒降低到51毫秒，优化的工作肯定是不会停下来的，优化工作还会持续，也有一些新的方向。

海外弱网环境的处理思路

第一，上行优化和下行优化都在IDC之间传输，你可以自己采购，在巴西也有公有云的服务，你去监控发现它每天到美国的链路都或多或少会丢包，有些是持续性的丢包。我们在巴西的机房也是存在这样的问题，它是解决不了的问题，基础设施不够好。每天都会丢包怎么去解决呢？我们去解决TCP由于丢包导致传输速率不稳或者下降的问题，我们采用了Quic方案。

我们接受用户的RTMP流推上来然后转化成QUIC进行传输到美国的源站，然后接到quic之后再把它剥离成RTMP推到美东的源站，这中间用了quic进行了加速，优化了这一短弱网的问题。上行花了2周时间优化完之后，卡顿率从6.5%降到4.8%。

第二、优化了下行回源链路，下行回源也用了Quic而代理做了协议转换，卡顿率从4.8%降到3.6%，这对我们的业务来说，对我们的服务提升都有很大的帮助。

第三，最后一公里边缘协议站的优化。刚才介绍的那些方案都是基于有SDK去配合的，现在用户用的就是IJK Player，那怎么办？因为我要做CDN平台我要做一个普适性的服务，我只能采用单边加速的思路。现在用的比较多的都有提供BBR的服务。腾讯自营了一套类似于BBR也克服了BBR的缺陷叫QTCP，在最后一公里去解决了弱网传输的问题。