360 移动直播云端架构演进

本文根据 360 高级技术经理殷宇辉在见云沙龙上的演讲整理而成。

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

1.     移动直播的背景现状

2.     移动直播的基础架构

  3.    360直播云发展历程

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

直播需求分类

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

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

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

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

基本直播流程

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

移动直播基础组件

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

360直播历程

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

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

水滴直播-业务场景

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

1.低延时 。

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

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

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

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

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

服务流程

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

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

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

底层部署

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

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

传输协议

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

调度系统

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

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

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

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

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

分发系统

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

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

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

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

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

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

回放服务

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

经验总结

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

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

3. 策略。

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

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

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

花椒直播-新的挑战

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

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

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

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

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

解决方案

我们遇到这些问题之后，逐渐采取了一些解决方法，因为我们开始得比较早，还没有人能提供全平台的运营商，但我们的思路比较好，第一把业务底下的流都拆开，端上面统一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. 流程。 无论在调度阶段，还是在数据获取阶段，还是在业务交互阶段，失败，那这个失败率，我们也都会通过这个实时反馈。

评判体系

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

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

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

这一章是刚才说的几个指标里面， 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有一个比较成熟的基础网络架构，像刚才说的多点多层互联，再就是它有比较好的运维体系，目前的话，我们申请机器、申请服务、Redis、MySQL这些全都是线上自动完成。

然后融合的话：

（1）我们对CDN开放，我们选择多家CDN接入；

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

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

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

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

（1） 我们提供一个高可用，易接入的SDK；

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

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

发展方向讨论

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

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，负责多个大规模存储、分发类项目。