360 移动直播云端架构演进

摘要:视频直播是现在互联网领域的一大热点,腾讯、百度、阿里等国内的几家互联网领军公司都在该领域投入了大量的人力、物力和财力,而移动视频直播相对于互联网直播而言难度更大,了解大公司在这上面所选择的技术路线,填坑的方案对于志在直播领域有所作为的公司而言是非常重要的。本文根据 360 高级技术经理殷宇辉在见沙龙上的演讲整理而成。

大家好,我是来自 360的 殷宇辉,我讲的内容大概包括以下几部分:

1.     移动直播的背景现状

2.     移动直播的基础架构

  3.    360直播云发展历程

2016年是直播发展元年,最早的时候Meerkat和Periscope这两款应用引爆了市场。目前国内直播市场几乎是一片红海,大概有两百多个直播APP,在这里面我大概会把它分成四个象限。

360 移动直播云端架构演进

直播需求分类

360 移动直播云端架构演进

1. 资讯类 。资讯类主要是像传统的演唱会或者体育赛事直播,它的特点是所有的信号都需要经过审核,所以它是一个先审后发、技术上主动加延迟的方式,就是你看到的画面可能是加了大概30秒,或者40秒的延迟。

2. 游戏直播 。大家知道特别火的斗鱼、熊猫等平台,它们的特点第一是信号来源相对单一,主要是OBS录屏。第二是帧率都比较高,大概在30帧以上,对于游戏直播,如果帧率较低会导致画面迟滞。

3. IoT领域 。IoT领域主要以监控为主,大家比较熟悉的有360小水滴、小蚁、萤石,这块它主要的要求是加密传输和低延迟,基本不会走RTMP协议

4. 泛娱乐 。这是目前兵家的必争之地,已经有大量的APP杀进来了,领头的是映客、YY和花椒这几个,这块机型比较复杂,也强调实时互动性。

基本直播流程

360 移动直播云端架构演进

这是一个最简单的直播流程,首先它会通过采集端的采集处理,经过编码封包,编码封包主要使用H264/AAC格式,H265现在还没到大规模商用阶段,编码封包之后就是推流,这块大家可能比较熟悉,如使用开源libRtmp,然后会推到CDN,CDN里面可能会做一些流分发和流处理,流处理主要是回放和截图的处理以及一些状态回调,在看播端主要是从CDN上拉流,然后进行解码播放。

移动直播基础组件

360 移动直播云端架构演进

刚才有同学提到了,如果我们做个创业APP,那应该怎么做合适呢?就目前来说,找一个成熟的云平台就够了。我们专心做业务就好,也就是上图中业务层的事情。  其余的服务组件和直播流的部分都可以包给第三方服务商。

360直播历程

360 移动直播云端架构演进

下面是360直播的历程,大家可以从图上看到,我们做直播是比较早的,我们最早进入该领域是在智能硬件特别火的时候,我们做了水滴直播,然后从2015年3月开始决定做花椒直播,做花椒直播到现在,业务方和平台方差不多已经处于相对稳定的状态,所以我们逐渐开始在内部成立一个私有云平台,以支持所有的音视频业务。

目前的现状是,像水滴的并发峰值大概有四万路,属于直播行业相对较高的一个量级。对我们而言,也是一个巨大挑战。当业务量没上去的时候可能没什么问题,但是业务量上去以后一切都是问题。比如存储,我们每天大概有近百T的存储,我们怎么处理这些海量的数据,以及高并发的直播流呢?

水滴直播-业务场景

360 移动直播云端架构演进

上面这个图是水滴的一个典型使用场景,它主要是用来看家看店的,最近有不少新闻说用户家进贼了,最后是小水滴自动触发报警,把对应的图像等等信息都存下来,最后公安根据这些信息找到了犯罪嫌疑人。它对底层技术要求比较多:

1.低延时

2. 全双工。 全双工的意思是什么呢?就是家里可能进贼了,然后你拿着你的手机,你喊句话摄像头马上就能把你的声音给传出来。就是你在摄像头端,我在APP端,咱俩是可以相互交互的。

3. 数据加密传输。 因为它涉及一些隐私,所以一般不会用RTMP这种协议。

4. 实时云存。 家里 如果发生什么事件,这些事件是能及时在云端存下来的。

5. 能分享。 像一些房地产商,他用水滴实时拍摄样板间的室内全景,然后可以通过H5分享给目标客户,这块我们会进行私有流到公有流的转化。

下面这个图是水滴服务大概的调度流程,大家可以简单看一下,之后我会分模块拆解。

服务流程

360 移动直播云端架构演进

首先水滴和花椒这种直播形式不太一样,其他的直播属于主播已经开流了,我只要调度观众端,而水滴的模式是APP端想去看某个摄像头的时候才去调动这个摄像头往上推流,它有一个实时调度这个摄像头去推流的过程。

大家可以看到,当我在APP端请求观看的时候,业务服务器会通过调度中心拿到两个地址,一个是摄像头的推流地址,一个是APP端的看流地址,摄像头会把私有流分发到我们的一个私有网络,APP端拿到这个私有流就可以开播、看播。最下面画的主要是实现H5分享的功能,我们会把私有流在需要的时候经过流转换器,转换成RTMP流之后推到直播源站,让第三方CDN进来回源,这样PC、H5端都可以去看。

后面是我们的云存服务,就是我们有直播,也要有录像,这个录像对手机来说也不能24小时全录,因为成本太高了,它会在流里面去找一些标识,然后把对应的内容存下来,需要观看的时候,如果访问量大的话走CDN,量不大的时候直接走我们的源站。

底层部署

360 移动直播云端架构演进

在整体架构底层部署方面,我们是有光纤的,我们在国内重点地区以及海外都有光纤或者专线的互联节点,核心的互联光纤节点主要是负责一些大区域及运营商,南北联通电信这些比较大的区,主要是做一些流转发以及数据处理之类的工作,每个节点之间,都是双向光纤互联。

第二块是二级的区域中心节点,主要负责一些地方大区,像北京联通或北京电信,它会有三通落地,也就是出口可能有电信、联通以及移动,它和我们内部的一级节点是光纤打通的,然后下面和我们边缘的二级节点之间可以走对应的ISP网络,避免跨运营商。

传输协议

360 移动直播云端架构演进

大家知道TCP有一些问题,比如拥塞控制等;然后TCP如果加上TLS之后,流程更多,带来的延迟也更大。因为手机直播对延迟要求比较高,传统UDP不可靠,如果用来传音视频,丢包会产生黑屏、花屏这些现象,所以我们自己封装了一个底层传输框架,它提供像TCP、可靠UDP以及不可靠UDP这些传输协议,使用可靠 UDP的时候,能实时控制滑动窗口、吞吐量等方面。经过我们的线上实测,主播上行的UDP连通率在95%以上。弱网等情况下,可靠UDP的表现也远超TCP。

调度系统

我们调度是HTTP服务,它会响应开流、看流的这些请求,返回对应的节点列表,这里我们也是返回多个IP,让客户端去测试,选择最优节点。

360 移动直播云端架构演进

大家可以看到,我们的私有网络跟传统CDN不太一样。

1. 它会把自己的一些管理信息,以及节点的负载等信息同步调度给服务器。

2. 我们的运维系统,比如说今天华北或者广州某个节点有网络割接,要把这个节点下掉,那么通过我们的应用系统实时就能下掉,这些信息都会同步给调度服务器,调度服务器本身是无状态的,它挂了之后,重启就可以,它没有持久化的工作。

除了这两块,我们后续还会有些信息返回到调度服务器,比如说根据区域算的实时卡顿率等,具体怎么算待会会讲。这是调度系统的一个基本情况。

分发系统

360 移动直播云端架构演进

我们的分发网络,主要是为了水滴的实时流服务,它跟传统的CDN有本质的区别。传统CDN是层次状,金字塔形的,所有的流推上来必须要到最高的顶点再往下分发。就是说:

1. 它的传输链条比较长;

2. 它是一个完全单向的连接,如果要在这个网络上实现我刚才提到的“从APP端说句话,摄像端实时播出来”是不可能的。

基于CDN去改造也是比较困难的事情,所以我们自己在下面做了一个私有的分发网络,它的特点是:

1. 我们所有的连接都是双向的,就是保证能下去,也能反向回来;

2. 我们有一个节点管理的Manager。管理拓扑层次是分层的,原因是因为有些地方的网络节点之间不互通,这时我们会找就近的,所以管理是分层考虑的,但是实时推拉流不是这样做的 ,因为我们有中心节点,记录了实时流的所有信息,以及拓扑情况,所以在进行推拉流的时候,会去内部查询一下。这样的话,你可以实现完全图状的一个网络,就是几乎你可以找到离你最近的一个节点进行拉流,或者推流。

回放服务

360 移动直播云端架构演进

回放这个事情我们是通过摄像头端做实时触发,当服务端收到这个录制信号之后去决定要不要进行切片存储,当摄像头端的事件结束之后,它告诉我结束录制,我就生成对应的回放地址,并把这个地址回调给业务,这时候业务实时拿来就能看了。这里我们依托了360最大的Cassandra集群去做这个事情,所有的切片都是按照HLS协议去切的,这样做,一是相对简单,二是HLS协议的平台兼容性比较好。

经验总结

360 移动直播云端架构演进

1. 成本。 现在去看下水滴,每个摄像头就一百多元,成本可能占大部分,如果算上返修率、坏件率,几乎不挣钱。但是你还要卖云服务,云服务这块就比较麻烦了,像我们的存储,如果一直录的话,成本是非常高的,用户是接受不了的。我们是用触发的方式,就是刚才提到的,摄像头端把控制信息带在流里面,然后它告诉我这个要存几天,存7天,还是15天,还是半年。每个套餐我们有不同的价格,我们是这样做的,目前的话,像水滴里面用这种付费云存的用户大概占到10%,这也是互联网硬件逐渐走向盈利的一个模式。

2.联通性 。因为硬件和软件不一样,像花椒,你打不开了可以用陌陌,或者用映客,但是摄像头如果打不开的话,用户会选择退货、赔偿。所以我们在前期做了很多工作,第一是调度返回多个IP,然后摄像头和播放端进行测速;第二是传输层同时支持UDP和TCP,当UDP走不通的时候走TCP,好歹能让用户能连通。第三是同网情况优先使用P2P直连,在前面这张PPT里面,我画了一条虚线,P2P直连的方案,它会通过我们的分发系统,拿到对应的信息,相当于做了一个隧道,之后的话,直接走P2P网络。

3. 策略。

(1) 我们如何保持、保证这种比较低延迟的效果,我们要替用户跨省、跨运营商,这也是根据我们公司的一些特点,我北京的一个用户,北京电信的开播,然后我是一个湖北联通的,那可以通过我的光纤去帮他跨一下,两端都找到同运营商去接入,中间一段有我们光纤的穿透,效果会比较好。

(2 )加解密,不用对整个数据段进行加密,只加密帧数据就行,这样的话,再做云存比较方便。我们第一版的时候,没有仔细考虑这一块,后来踩了一些坑,只能在服务端进行加解密,后来压力上来就扛不住了。采用新方案之后当只对帧数据加密的时候,在服务端进行容器格式转化,不需要解密就可以把直播流封装成HLS文件,当业务播放时才去解密。

4. 存储和流分发。 这一块最早的时候我们的量比较小,对我们影响不大,但是后来水滴云存每天大概上百个T,流量实在是太大了,我们就选择把存储服务和流服务部署在相近机房,这样节省了内网的传输带宽,数据写入延迟大幅降低,这是做水滴的一些经验。

花椒直播-新的挑战

360 移动直播云端架构演进

当我们开始做花椒之后,我们早期是把水滴那套方案快速上线,直接先挪过去,最后发现很多问题,大家可以看看我列出来的一些情况。

1. 推流场景复杂。 用水滴的时候,我只有一个摄像头可用,没有其他的东西,它的帧率码率都是硬件厂商那边调优很久之后确定的。但是花椒有安卓、iOS、OBS各种平台,像安卓碎片化,在每个手机上是否支持硬编硬解,支持的好不好等,像我们经常遇到开了硬编的机器它的码率、帧率会跳动。另外是编码格式,做水滴时候我们主要用I帧和P帧,就是BaseLine的Profile,也不会提供High和Main这种profile的支持,因为B帧有可能带来部分解码延迟,但是做花椒的时候,各种格式都要支持。

2. 需求爆炸。 端上面的功能越来越多,像美颜、face++、礼物特效,以及像我们也推出过VR直播还有多路连麦的功能。这里面有几个问题,一是CPU会争抢,二是底层各种SDK可能冲突,比如像连麦的SDK;播放器的SDK可能会有冲突,以及对音视频设备抢占的处理问题。

3. 运营事件复杂。 像刚才也提到过,现场网络不可控,我怎么去拨测,流量也不能预估,有时候可能哪个明星突然某天心情好了,他偷偷上来,这种我们最害怕。再就是主播的网络,他开车,就是边移动边播放,然后动不动开WiFi切4G,像这种也是比较麻烦的。

4.海外用户增多。 有些主播他在法国或者北欧,还每天播,我们有个法国某小镇的小伙子,每天直播打太极,逛街,像这种情况的推流质量难以保障。

解决方案

360 移动直播云端架构演进

我们遇到这些问题之后,逐渐采取了一些解决方法,因为我们开始得比较早,还没有人能提供全平台的运营商,但我们的思路比较好,第一把业务底下的流都拆开,端上面统一SDK,然后云端统一流分发以及处理服务;业务的话,只专注自己的APP以及服务端,这里面有两个关键的技术。

1. 多家CDN融合。 我们会让其他每家CDN去做一个汇聚转推,就是他在自己的节点内进行汇聚,汇聚完之后转推到我的直播源站,相当于到直播源站之后,后面的存储以及截图等事情还是由我统一来提供,用户观看回放的时候也会走多家CDN,这时他统一都要来我这边回源。我们不希望跟CDN绑太紧,目前有些直播会把录像这件事情交给某家CDN,回头你想迁数据,或者说你想把这家CDN迁走的时候,你的数据是比较难迁移的,在这里面,我们用多家CDN会有几个策略:

(1) 在正常情况下,我们倾向于自洽,就是开流开到那家,那我观看就会调到哪家,这个第一是为了对比多家CDN的质量,第二个是为了避免复杂性。

(2) 溢出机制,比如说像张继科、范冰冰,他们一开播,那流量一下就跑上去了,可能像我们用的网宿一家抗不住,那我们就会把它下行,放到其他家的CDN,这样其他CDN就过来进行回源。

2. 客户端实时反馈 ,在客户端会有实时的统计,这里面大概有些维度,我大概给大家介绍一下。

(1) 推流,帧率,码率,宽高,丢帧率。这一块我们做得策略比较多,比方说像动态支持率码率和分辨率,这些都是可调的。

(2) 播放。我们主要关心的是在线,卡顿,首屏,延迟。

3. 业务层面。 比如说用户的直播ID,一个ID可以贯穿全流程,可以通过这一个ID去追溯;还有会话ID,我在一次直播里只有一个会话ID,通过这个Session可以贯穿从业务端到底下云端,以及数据分析的全流程。

4. 传输。 我们传输第一是用了多协议,第二个是用了多CDN,这些标志我们都要标注出来。第三是用了测速,最后客户端实际连了哪个IP,以及它的一些连接状态,有没有中途切换网络等。

5. 物理信息, 像设备类型,网络类型,以及iOS,安卓的一些系统版本,以及CPU、GPU占用,有些礼物特效对CPU、GPU的耗用特别大,有时候如果到90%的CPU,那观众端看流都会卡。

6. 流程。 无论在调度阶段,还是在数据获取阶段,还是在业务交互阶段,失败,那这个失败率,我们也都会通过这个实时反馈。

评判体系

360 移动直播云端架构演进

我们大概关心三块,稳定性、成本和效果。稳定性、成本这块就不多讲了,这里主要讲下效果。我们会有一些指标,比如像首屏时延、平均时延、推流看流卡率以及请求失败率。

那么怎么不在实验室环境计算这个延迟,很多CDN厂商号称自己是秒级延迟,一到三秒,其实他是只测传输网络,不会测端对端,如果端对端的话,加上端的buffer,加上GoP的cache的buffer会很大。我们是通过在推流端加了一个时间戳,在看流端解除这个时间戳去做对比,当然了,每个主播端的时间戳都不一样,我们通过一个标准服务器去做了校正,校正完之后,只选可信的,不可信的扔掉,这是我们实际得到的一个图。

大家看这个卡顿率,是相对偏高的,像电商类、或者游戏类的直播,它的卡顿率一般会在3%到5%之间,原因是他们OBS推的比较稳 定。第二,他们的延迟比较高,他们不在乎延迟,他们延迟可能比移动互动直播更高一些,像我们展示这些图,会有不同的维度,比如时间、业务、CDN厂商、版本、运营商、地域等,这些维度,也会有实时、离线两个大的维度。

360 移动直播云端架构演进

这一章是刚才说的几个指标里面, CDN的一个对比,大家可以看一下。延迟计算方式是我们最近才摸索出来的,这也是最近才上线的一个功能,所以数据不是特别稳。大家可以看到,移动直播推流端的卡顿率非常重要,几乎有时候能到10%左右。观看端的话,大家也能看到大概的一个情况。首屏时间,看这张图有很大差异,蓝色这 条线呢,是我们私有的传输,可以大致看到相比RTMP协议,还是有优势的。

经验总结

花椒这一块经验的话,大概有这么几类,大家可以看一下。

1.体验类。 滑屏卡顿一方面通过调度预加载、本地结果缓存来减少流程,另一方面还有一些SDK冲突的,因为现在在端上有很多SDK,美颜滤镜的、多路连麦的,以及自己的播放SDK,这些SDK之间相处并不太平。录制卡顿这块,我们目前大概会在上行端去做自适应码率,就是通过主播端的网络去自适应,主动地降码率,帧率,也可以通过服务端发指令,把码率降下去。覆盖的话,我们会根据优势区域去分配CDN,比如说海外可能网宿覆盖比较好,我们优先把海外的主播调到网宿。

2.效果类方面 ,大家比较关心的像首屏秒开目前几乎是没什么秘密,首先是服务端的一个GoP cache设置,再就是推流端的GoP间隔。比方说你是15,你每个GoP大概是几秒,目前我们大概是两秒一个GoP。还有客户端的Buffer策略,等到第一个关键帧,还是把Buffer堆满再播放。

保障效果的第二块是延迟,目前看,对移动直播会比较重要一些,它会涉及到流的特效展示,比如说我有一个大土豪可能给某个主播送了一个效果特别赞的礼物,但是隔了一分钟还没看到,这就不行了,所以这里面有追帧的逻辑,我们可能会根据流里面的时间戳,发现差异过大,就把前面的快进,两倍速度、三倍速度播放掉。

3.监控类。 监控类我们目前会有一个实时流反馈,主要采集的维度刚才也讲过了。我们会做一些底层的自动化应用。

(1)后 台监控 ,在后台有一个图片墙,图片墙上会展示每个流的状态、当前的帧率、码率,以及主播是否切后台等信息。

(2)热榜切换 ,比方说主播已经切后台了,那我立马就把你从热榜上切下去,不要让你继续占着热榜,因为所有人点进来之后都是黑的。

(3)多CDN监控 ,我们会进行链条式的监控,在主播的推流段,在上行的第一个推流点,再转推点,我们都要求CDN做了实时监控,这样能实时具体定位到哪一段出了问题。

360 移动直播云端架构演进

做完前面两个产品之后,我们也在同步做一些事情,因为我们发现我们提供的越来越底层,所以我们希望把一些基础的技术汇集起来,在这里,我们主要是依托360的一些基础技术,因为360有一个比较成熟的基础网络架构,像刚才说的多点多层互联,再就是它有比较好的运维体系,目前的话,我们申请机器、申请服务、Redis、MySQL这些全都是线上自动完成。

然后融合的话:

(1)我们对CDN开放,我们选择多家CDN接入;

(2) 连麦技术也在做融合,因为让每个APP厂商去接入难度还是相当大的。

(3) 大数据的一些分析处理能力,比如像截图鉴黄,以及其他的分析,外面有些厂商做的比较好,我们也会积极地把它拉进来。

(4) 人工智能处理,这块比较典型的一个应用场景是,你家里如果装了小水滴,它可能过一段时间就会认识你,你回家,它大概就知道你回来了,如果是陌生人它就会报警,这是有人工智能学习在里面的。

依托主要是依托360基础服务,融合是融合外部厂家各自擅长的技术。我们自己则主要是专注直播这个领域:

(1) 我们提供一个高可用,易接入的SDK;

(2) 针对低延迟高互动的直播场景,我们不太想做传统的那种演唱会的直播,它的技术含量相对较低。

(3) 提供比较丰富的直播相关的组件服务,像云点播、一站式直播,以及云存储、融合CDN加速等服务。

发展方向讨论

360 移动直播云端架构演进

接下来再跟大家分享一下一些发展方向方面的东西。

1. 一些建议,针对目前有意做直播的创业者、创业团队,要以精细化和垂直化的直播场景为主,因为大家现在建一个直播APP非常快,可能花半天,如果用现成的云服务商SDK,基本推流看流能跑通了,然后再把其他的长连接等等整进来,花一周可能我的Demo就出来了,然后发现业务场景完全起不来,因为现在做直播的太多了,必须得去做垂直化,场景化。

2. 我觉得目前从我们的经验看,常态下是多房间少量观众为主,不排除偶尔有个大主播,比如说像几十万的在线用户。第三块是互动会越来越丰富,因为现在美颜滤镜都属于比较低级的了,大一点的像面部特效,以及像多人连麦互动这种都加了。

云服务提供商方面,你一定要去判断,它具不具备多端统一SDK的能力,是否开放一些数据分析的能力。现在有些云服务商,他实际上是可以把端上面的采点数据都报给你,这样你查问题会更方便一些,就不至于说我接了一个黑盒什么都干不了。再就是他的CDN覆盖网络是否优质,是否能让你自己去选择CDN。在底层技术这块,我觉得未来的话,低延迟互动一定是重要的方向,低延迟五百毫秒都偏高了,正常应该是三百到四百毫秒左右。

Q: 刚才您PPT里面看到了连麦,目前我们也在做连麦,你们用的是服务端的方式,我们目前正在用的客户端的方式,你为什么没有选择客户端的方式?

A: 是这样的,客户端和服务端两种方式各有优劣,应用场景也不太一样,你们是基于WebRTC?还是自研?客户端合成,它对主播端手机有消耗,你如果在做一对一的还比较好做,你如果做多人与你聊天,那全放在客户端是不太合适的,我们目前的方式有两点考虑:

(1)我们私有网络已经搭建好了,可以去做这种基于私有网络的多入流的转发;

(2)我们觉得在客户端合流满足一对一的应用是没问题的,但是我觉得最终的话多人连麦互动可 能是未 来的方向,在服务端会相对轻松一些。

Q: 对音视频怎么同步?

A: 我们主要还是基于流里面的时间戳为准,视频参考音频。

Q: 直播流如何能够快速的实现串网,主动推流到根节点吗?

A: 其实刚才我少讲了一点,就是我们其实不是主动推,我们有多种策略,你比方说像摄像头的策略,它其实是要求中间的环节越少越好,我们大概是三跳。像一个人播,多人看的这种场景,我们会根据这种热门列表有一个互推,预热大区节点。我们会根据不同的业务场景做不同的一些尝试,也有不同策略。

Q: 我刚才看陌陌,还有咱们360都是采用RTMP的方式,其实传统的运营商他们都是采用RTSP的方式,那么你们对于选型是出于什么考虑?

A: 我们最早也看过这些东西,像传统的摄像头主要是采用 RTSP协议。而像花椒里面主要是RTMP,原因是因为,这也要看CDN厂商支持啥,玩法是啥,我们是一个互联网公司,都是偏互联网化的,如果做传统的视频监控的话,倾向于使用RTSP。

讲师介绍

360 移动直播云端架构演进

殷宇辉

360高级技术经理

目前负责360直播云底层服务架构。曾就职于阿里巴巴、盛大、360,负责多个大规模存储、分发类项目。

点击下方“阅读全文”查看PPT

原文 

http://mp.weixin.qq.com/s/hs6UxNoRofyUJ0Ny6Vm3Qw

PS:如果您想和业内技术大牛交流的话,请加qq群(527933790)或者关注微信公众 号(AskHarries),谢谢!

转载请注明原文出处:Harries Blog™ » 360 移动直播云端架构演进

赞 (0)

分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址