海量用户实时互动直播架构探索 | WebRTC编风网
1

海量用户实时互动直播架构探索

已有 397 人阅读此文 - - 见云(微信ID:cloudmeetday) - 李伟(声网Agora.io 1号架构师)

现在比较流行的直播,经常会出现这样的情况: 用户打了一个弹幕上去,主播念出来的时候,弹幕已经飞出去了。二者时间是不匹配的。

这是我们的一个客户,两个主播连线互动,实时交互。试想,如果直播时延时高达几秒,像这样的双主播组合是没有办法进行交谈的。A说完之后,对方要等几秒才能听到,又过了几秒,A才能听到对方的回答。

1

这两个例子其实要说明实时互动直播和普通直播相比有本质的区别:延时。实时互动直播延时必须低达几百毫秒。

为什么是几百毫秒?为什么不是几秒也不是几毫秒?这是由人们日常交流习惯决定的。人的说话声音通过声波传播,如果两人相隔34米,那么延时就是100毫秒。基于这个范围,略长的延时,观众还能。基于互联网的音视频通信,音频通话延时标准在400毫秒以内,视频通话延时在800毫秒以内,这可以让通话双方无延时感知的。延时如果达到秒的数量级,那么通话双方就会有明显的等待。

互联网是基于电磁波或者通过光纤传播的。光绕地球一圈,耗时300毫秒,这是无法逾越的物理定律延时。有人号称可以做到0延时,他们估计用上了量子通信。在实际互联网应用中,网络条件并不理想,互联网信号绕地球一圈的延时必然大于300秒。这就给实时互动直播,带来了巨大的挑战。

实时互动直播的挑战

第一,互联网的骨干网上路由器的部署,不是直线点到点,而是中间要经过很多路由器的跳数,实际上是在走“弯路”。所以,互联网传输没有办法绕地球一圈正好300毫秒,最好的情况也需要要近400毫秒。

第二,公共互联网上,路由器其实经常出现故障。比如,在晚高峰的时候,网络会比较慢。这是因为部分路由器可能过窄。因为路由器有最大的处理能力上限,一旦超过上限,就不能处理,会造成丢包、拥塞。

第三,无线网络相对有线网络,可靠性较低。无线网络普及度越来越高,,越来越多的手机、笔记本连接无线网。但是无线网络相对有线网络没有那么可靠,同时也会引入信号污染。信号覆盖不到的地方,效果较差。

第四,高并发挑战。首先需要普及一个概念:并发和在线是有区别的。当今的移动互联网,大家都在讲千万级。当我们谈及海量用户架构这个话题时,似乎如果不说到上亿这个量级,是落后了。但是实际上,前面这些说法都混淆概念了,它们都在说“在线”,而不是“并发”。以下图为例:

2

左边是QQ在线好友列表,图中可以看到很多好友展现,其实没有交互,使用者不会有压力。右边是一个框同时和很多人聊天,使用者会感受到巨大压力。同样的,对于直播服务而已,如果用户只是在线,很少会跟服务器有交流,最多偶尔发一个新跳高。

用户在线时,如果参与了“看”“说”,这就是并发。直播的并发峰值具有突发性,往往跟主播的活动密切相关。比如,主播会跟粉丝约定直播时间,到了约好的时间,粉丝就会在短时间大量涌入一个直播频道。观众慢慢进入频道,服务器没有压力,但如果瞬间涌入,后台的压力非常大。

本文,将重点介绍互动直播的可用性问题。电信业务的可用性标准是四个九,我们期望做到五个九。双十一时,支付宝的处理能力非常强,百度百科上提供的数据显示,支付宝当天处理了96%订单。但是,我们对自己的互动直播有更高的要求,期望做到99.999%。

实时互动直播要保证高可用性,有巨大的难度,原因如下:

1、实时很难。互联网基础设施不是为实时通信设计的。

2、覆盖很难。机房找点,互联互通。对通信云来说,覆盖不好会影响到可用性。

3、高并发很难。不能看着看着就不动了,没声了。

4、突发性很难。系统容量要高,还要防止雪崩。

这些挑战我们在做整个服务的时候,都需要全面考虑。

直播架构的演进

1、CDN直播架构

这是当前流行的直播架构,左下角是一个主播,主播通过手机或电脑等设备,把自己的视频流上传到服务器,接入目前流行的CDN服务,通过CDN服务进行网络分发,分发到各地的用户。所有用户都可以看到主播的表演。

3

2、单服务器实时互动直播架构

实时互动直播,不能使用CDN方案,因为CDN方案性质决定了延时达不到实时的要求。下图是我们认为可以实现实时互动的架构。主播把自己的视频流上传到服务器,通过这台服务器分发给其他用户,再采用合适的传输协议,延时可以做到很小。从主播到服务器再到观众的延时,加上编解码和抖动的延时,可以做控制在几百毫秒以内。

4

这个架构很简单,但有一个缺点,没有考虑覆盖不同地用户的问题。并且一台服务器支撑不了大规模用户。这台服务器如果宕机,或者服务器机房出故障,整个传输都会受到影响。这必然达不到高可用架构的标准。

3、分布式实时互动直播架构

主播的视频流上传到一个接入服务器,这个服务器会把这个视频流分发到我们部署在世界各地的服务器。然后这些服务器接入本地的用户,把视频传下去。

5

在这个架构里面,首先可以解决的是覆盖问题,部署在世界各地的服务器,可以让用户可以快速就近接入。整个视频流通过我们在互联网上做的分布式传输算法,把它实时的传输到世界各地的机房。其次,可以避免机房甚至骨干网故障,对传输造成的影响。

如何实现高可用性

可用性可以分为两个部分:接入可用性和使用可用性。你在使用服务的时候,能够接得进去,能够听得到,这是接入可用性。举个例子,打电话的时候,有时会出现你所呼叫的用户无法接通,因为用户的手机没有接入电信服务,这就是接入可用性问题。在通话的时候,听不到对方说话了,使用中掉线了,这就是使用可用性。

为了实时监测可用性,我们做了两方面的监测:

1、主动监测

服务可用性不能依靠用户数据反馈或者用户主动上报,这样你永远是最后一个知道的。况且初期用户量小怎么办?因此,我们需要自己给出我们的服务有多可靠。为此,我们研发主动监测系统来监测整个服务。端到端监测,接入有没有问题,在使用的过程中会不会出问题。

2、被动监测

用户在使用我们的服务的时候,我们会收集用户接入服务的整个过程,多长时间可以接入,接入时经过了几次请求,使用中有没有掉线,中间有没有声音终端或卡顿。我们会收集这些数据,据此了解服务的可用性。

有了监测数据,那么就可以据此来不断改进我们的服务,解决前面所说的挑战。

1、覆盖问题

在中国做互联网的人应该都有一个感受,联通跨电信,用户之间是难以交互的。早期的QQ传文件没有做中转,如果联通和电信的用户要互相传文件,速度非常慢,甚至会中断。玩网游的用户,也会遇到有电信专区、网通专区。下图是一个简单的测试,当跨运营商的时候,发一个包,可以看到里面有很多丢包。这个数字是RTT,这个测试结果可以看出,最小是62毫秒,最大是840毫秒。

6

不但中国有网络互通的问题,国外也有。很多人以为发达国家,比如美国、日本,互联网的基础设施较好,所以不会有互联互通的问题。但是,在我们做实际测试时,美国的互联网也存在互联互通的问题,只是状况比中国好一些。

7

上图,展示了一个一个阿尔及利亚用户的网络状况。他接入的是国家电信的服务商,从骨干网接入阿尔及利亚电信有很多线路,最下面的线路意大利电信是最直接的。如果不走意大利电信,那么中间就必须经过很多运营商跳转。在这种情况下,要保证用户有做最快的传输,就要保证传输走意大利电信。这必须依靠覆盖来解决。

如何解决覆盖问题?

首先,部署大量边缘服务器。边缘服务器的地理位置越接近用户越好,二者的线路越接近约好,同一个SP最好。比如中国国内,我们会有大量电信、联通、移动服务器。当我们发现一个接入的用户是电信时,我们会找电信线路,如果是联通的会找联通线路。再看回上一个图,如果遇到阿尔及利亚的用户要怎么办?在现在的服务里面我们就要找一个意大利电信接入,而不是随便找欧洲的机房。必须部署很多边缘服务器才能做到这一点。

其次,要有分配服务。有边缘服务器之后,用户还是无法接入边缘服务器,因为他不知道接哪个。因此,必须有配套算法,根据用户的SP,找到和他最匹配的边缘服务器,来进行接入分配。

2、跨地域问题

我们在全中国有好几十个机房,其中有很多电信的机房,不同的电信用户来使用我们的服务,应该给他哪个电信机房呢?如果把北京电信用户接到广州的电信机房,虽然大多数情况下丢包不会很高,但延时会比较大。为此,我们设计了就近接入算法,使用我们服务的每个用户,都会接入到最靠近他,且线路最匹配的服务器。

8

当我们就近按SP接入时,遇到了一个新问题:假如一个香港用户,接入的是香港机房,想看北京联通用户的表演,那么这个香港用户怎么看到北京用户的表演呢?我们就需要有一个分布式传输的架构和算法,来把北京的流量传到香港。

3、DNS解析问题   

今天无线互联网非常普及,使用无线网时,有一个问题比有线网更严重:DNS解析。用户接入时,第一步是通过域名解析,解析到最近的服务器。但是,做DNS解析时,无线网络的信号会存在污染,导致DNS解析失败。为此,我们优先使用解析,解析不到再用静态IP配置。

4、骨干网故障问题

我们发现在骨干网上,很多默认的骨干网路由经常出问题,同时有一些骨干网部分是不会拥堵的。基于这样的发现,我们做了自己的路由网络。

9

在默认路由之外,我们会额外部署路由机房。比如,从上海到洛杉矶,假设默认线路到晚上高峰期会比较拥堵,同时我们发现从上海经过广州再经过香港再到洛杉矶,这条线路不会拥堵。那么,我们就会部署这样一条路由线路,然后做自动的适配。

如果骨干网上出故障了,我们通过路由的方式构建Overlay应对。首先,我们的应用会先连接到分配服务,分配服务会给出一批可接入的机房,当接入的机房坏了,就立即切换到下一个可用机房,如果发现还是坏了,则再次接入到分配服务,继续寻找当前可用服务器。

5、蜂拥

蜂拥是实时互动直播里面特别突出的现象,短时间内大量用户进入频道或者使用服务。蜂拥对整个后台的冲击力非常强。大多数的互联网的后台服务器每秒接入大概千的量级,但是对于蜂拥而来的用户,处理量远远不够。这时候就会遇到一个问题,后台处理响应速度越来越慢,很多用户的请求会超时。超时之后就会进入更多的请求,请求就会像滚雪球一样越来越大,导致整个后台系统不能响应,整个系统就会产生雪崩,这叫雪崩效应。

如何防止雪崩效应

10

1)要把性能上限提高。通常来说我们的性能上限会达到峰值处理能力10倍以上。性能上限提高要做分配服务性能扩展,我们的做法一般是水平扩展,因为垂直扩展比较困难。

2)应用里面做自动的重复请求,它会不断累计请求量,我们要做退避的策略。

3)保证整个接入服务本身的可用性问题,处理方法很简单,多点备份,然后做并发的请求。我们有很多分配的服务器,们的应用接入的时候会同时从几个点请求分配,分配到一批边缘服务器之后,会同时连接几个边缘服务器,哪个先响应就处理哪个。

 

3
相关文章!
  1. 匿名 - 2016.12.15

    汗 这通篇说的不就是CDN思想