6 月 29 日,音视频及融合通信技术技术沙龙圆满落幕。本期沙龙特邀请腾讯云技术专家分享关于最新的低延迟技术、全新的商业直播方案等话题,针对腾讯云音视频及融合通信产品的技术全面剖析,为大家带来纯干货的技术分享。本文是胡仁成老师关于海外视频云直播系统架构中的实践案例的分享。
说到建设海外系统,我们要了解海外直播包含哪些,主要有三部分,第一,包括了公有云和网络基础设施的建设;第二,在此基础设施上我们架设软件系统,实现直播流媒体的分发;第三,我们在已完成的系统上更深入化的做好更多网络细节上的处理,包括跨区域的拉流等方面的优化,比如说精细化的调度,精细化到运营商实现调度。因此,海外直播系统在应用软件层面跟国内没有太大的区别,更多在弱网优化、调度优化等方面做一些精细化的工作。以下是具体的内容。
海外网络与机房建设
首先了解一下全球的网络态势,从这张图可以看出来我们在全球的网络布局从地域分为三大区,北美、亚太(香港、新加坡)、欧洲(德国)。其实海外运营商比国内多很多,国内说三大巨头电信、联通、移动再加小运营商。在海外大概接近 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,在最后一公里去解决了弱网传输的问题。
其实做这么多工作,海外跟国内最大的区别是如何在综合成本的控制下取得一个边际收益的最大值,这是我们目前做海外直播的设计思路也是我们的考虑点。
Q:您好,如果要是优质的话一定是在物理层,物理层看不到监控,你怎么解决流量控制?
A:我们采购的运营商他们自建的跨大区的物理链路提供给我们的服务,是一种 MPLS-VPN 技术,并且打了金牌标签的优质链路。在腾讯内部的网络体系里面我们认为它就叫专线。
Q:精细地探测是怎么做的?
A:如果是腾讯云的 CVM 的话,CVM 的建设都是 Tier1、Tier2 带宽,会跟印度前五家 TOP 直接采购,运营商会保证质量的。你说检测其他小的运营商,首先你得知道印度有几家运营商你分析,分析完之后要拿到 ASID 号以及对应的网段,然后你去探测、监控对应的网络质量指标,比如延时或丢包率等。
作者介绍:
胡仁成,腾讯云高级工程师,腾讯云海外直播技术负责人,专注于海外直播系统的建设与优化,包括海外云直播机房与网络的建设与优化、流媒体处理系统的建设与优化等。
本文转载自公众号云加社区(ID:QcloudCommunity)。
原文链接:
https://mp.weixin.qq.com/s/uFs0fjJ1y0P1ElODAGwuOg
评论