又拍云羊能卿：直播云系统架构与实施

很高兴今天能够和大家一起分享直播系统的整体架构和实施经验，刚才邓总讲了很多现在直播平台遇到的问题，包括软编码、硬编码，以及一些专业性的内容，比如当你的流最低的时候，怎样实现往前赶帧，而这些也是我们直播 APP 里面需要关注的非常细节的问题。

接下来我主要给大家讲的就是我们怎么去搭建，怎么去实施云直播的整个系统架构，还有我们将会提供哪些功能给到使用我们的云直播的 APP 用户和需要我们这套系统的用户。我们先来看一下直播的整个市场，大家可以看到这张前段时间特别流行的图，各种各样的直播 APP 集成在一起的页面的截图。通过数据统计，可以看出 2016 年是视频直播的元年。而 2015 年年底的数据显示，直播的 APP 已经达到 200 多家，市场规模是在 90 亿左右，同时大平台的在线人数基本上可以达到 4000 个直播间，通过这些数据我们可以看出的网络视频直播已经来到了群雄逐鹿的时代。

一、直播类型

我们接下来看一看直播都有哪些类型？它们分别在什么场景下运行？

直播主要有五类，第一是我们的传统直播，第二是最近比较火的游戏直播，第三是电商，第四是移动轻秀场，第五是我们说的直播 + 的概念。

1、传统直播

传统直播基本都是单向传输，很少有做交互。有点像广电演唱会的直播，现在如果做交互的话都是放在秀场里面去做。他只是简单的对外传输他的直播流，并且流数比较少，延迟容忍度高，基本都超过 10 秒，包括电视转流、演唱会直播等。

2、游戏直播

我们来看一下游戏直播，比如说战旗就是热门直播的竞技类直播的秀场。游戏直播也是单向传输，他通过直播文字进行交互，利用弹幕或者讨论组进行沟通。他有一个特点是流数比较多。他们有一个万人主播的培养计划，如果同时在线能达到一万个主播数。游戏直播自身的业务对延迟要求不高，但他现在做秀场直播，都做到 2 秒，这是因为竞争激烈拉高了要求。大家想想主播在打游戏的过程中，不管他是在直播他自己玩的游戏内容还是介绍一些玩游戏的心得，延迟对他来说并不是特别重要，因为更多的时候，在直播的过程当中，弹幕和讨论组跟我们的直播流是分开的。你看到哪一段就沟通哪一段，更何况刚才邓总也说了平台只是让用户看到他想看到的东西。

3、电商直播

电商直播的特点是单向、文字交互，流数少，基本就是介绍自己的商品，延迟容忍度高于 5 秒。有跨国性的特殊需求，像海外淘，国外买手在直播自己的内容，这时候需要专业的厂商提供一些海外的内容。之后我们会讲这一类的客户如何为他提供服务。

4、移动轻秀场

移动轻秀场有两种方式，一种是单向，一种是双向。他们通过文字交互或者直接通过流进行聊天。打比方说我们现在在同一个屏幕上看到话多话，他其实是 A 主播和 B 主播两个人同时进行实时交流。而观众看到的是他们之间进行沟通的一个屏幕的直播流转推出来的内容。这部分的用户他们体现的跟前面一样，流数比较多。延迟容忍度比较低， 2 到 5 秒已经是非常大的要求。基本很多都是 1 到 2 秒之间，他要求两个主播必须互动起来。

5、直播 + 的概念

直播 + 使直播进入一个更多垂直的细分领域，包括 O2O，以及其他内容，比如说我们做新闻发布会，做培训宣讲希望别人看到我们的内容。这是直播架构带给更多的用户趋向性的东西，你可以通过直播的方式介绍你的产品，你的员工，你的工程师可能一对一，或者是你自己宣传自己的产品，有更多丰富的承载方式。

讲完了我们现在说的直播的五个应用场景，我们再来看一下今年最火的 VR，要说 VR 火不火，其实可以看去年股票市场里面的暴风妖股。当时说的很多 VR 场景，在现在来说做的还不是特别成熟。不管是设备推广，还是受限于他现在马力比较大，终端用户访问，家庭带宽不够高等理念的需求。现在已经有巨头在做这个事情，比如淘宝推出的一个 “Buy+” 计划，你要去买一件衣服，你站在那里通过败家的 VR 平台，就可以展示出你现在要穿的衣服以后是什么模样。还有你装家具，走进一个空间，可以通过数据扫描把整体的家具装璜按照你的思路进行描绘。这也是 VR 在以后的应用过程当中，能够带给我们的增强现实的体验。讲完直播行业的状态，接下来我们进入主题，来讲讲直播的服务架构。

二、直播服务架构

关于又拍云的整个直播服务的架构，通过这张图可以看出来，首先我们需要有一个信号语言，不管是电视信号源，摄像机信号源，还是我们桌面捕捉下来的内容，都可以通过推拉流的方式直接上传到一个视频处理的中心，进行编解码或者做一些水印等视频处理。比如说我们会给他们加一些打点的数据，加一些字幕，加一些特殊的说明等，这些都会在我们的视频处理这块生成 H.264 和 AAC 的直播流，然后通过内容分发的网络，直接分发到我们全国的边缘，让用户能够通过各种设备看到我们的直播流。我们处理完视频流之后，还可以进行录制存储，录制完了之后还能够转成点播，满足用户的多样需求。还有虚拟直播的概念，包括现在的直播，在你录下来的时候可以转成 FLV 的流推出来，这是虚拟直播的概念，不是真正的现实流录播。以上就是现在比较常用的直播的服务架构。

三、业务架构

1、常见业务架构

我们再来看一下我们现在常见的业务架构，很多人在设计直播架构的时候，通常他们的传统厂商都会有一个集中的视频源。视频源能够让用户把视频传到单一视频源里面。单一视频源的优势是省事，做分支部署比较简单，但是故障率比较高，发送故障以后解决的时间较长。而直播，特别是互动类直播，大量的主播分布在各个运营商网络里，单一的视频源并不能够满足跨运营商传播的时效问题和网络的优化问题。通过单一视频，搜集到数据之后，再向运营商做一个分发，这是不靠谱的网络结构，那他遇到云直播之后会产生什么样的变化呢？

2、视频云业务架构

如上图所示，在视频云的业务架构中，我们将会加入更多的组建视频源的集群，用于收集视频主播的边缘用户的直播流上传数据。比如说我们的北京电信用户上传上来，如果只有一个单一源比如在上海电信的话，客户会需要跨城市去上传到上海电信区域。但是现在有一个集群式的云，他就可以通过合理调度直接上传到最为适合的上行边缘节点，比如上传到北京电信边缘节点，再通过北京电信上传到我们的核心源，再通过内部进行交互和分发，如果你的播放用户在联通里面，还可以通过几个核心源之间进行数据调度中转，传输到联通边缘，再提供给终端用户进行访问。

我们在河南、浙江、广州、北京、江苏、四川搭建了一个用光纤打通的核心视频源的集群，当做主播推流到我任何一个边缘节点的时候。可以通过智能调度进行跨越传输，通过物理光纤直接进行数据交互，缩短数据传输的时间。合理的将大量用户进行智能调度访问到不同的运营商，不同区域，提供终端用户的访问体验，也就是说我们可以保证一个低延时直播访问。

核心节点集群通过的光纤打通之后有什么好处呢？如果是单一的视频源，像去年有厂商核心数据中心光纤被挖断发生长时间大面积的网络故障，如果使用我司的云直播平台服务，在 6 大核心节点中使用物理光纤打通，当单一核心节点故障时，可以通过智能调度转换访问其他区域，我们又拍云实现自动容灾，发生故障时，节点之间可以进行相互切换，自动选路。就不会出现说我某一个机房断了，我整体的服务就要停止，合理的防止单点故障照成的更大网络故障并提高跨网跨运营商的传输速度和效率。下面我们看一下传统直播服务和我们又拍云的直播云的对比。

3、 传统直播服务于直播云的对比

对直播而言，视频源站的稳定性非常重要，直播不间断、不卡顿，跟源站有直接的关系，对直播效果带来的影响很大。传统直播服务多采用单一源站，而又拍云直播云将整个平台去单点化，通过打造源站集群，形成多个源站的架构。单一源站使整个架构系统非常简单，在单一机房，维护一套系统，很容易实现分布式；延时方面不用担心公网网络抖动导致的系统不稳。既然如此，又拍云为何要耗费精力财力打造源站集群？原因在于单一源站的致命缺点：内容源完全受限于一个源站，当机房带宽拥堵，整个平台所有的直播内容都会卡顿；而一旦公网故障，内容就完全推不出去，意味着直播失败。

为了解决这一问题，如上图所示，又拍云在全国六个比较重要的地区，如北京、浙江、江苏、四川、河南、广东的核心节点部署源站集群。一个源站的集群十几台服务器，六个集群大概六十多台的规模。又拍云通过私有光纤网络将六大数据中心打通，形成类似于内网的状态，实现高可用性。整个光纤链路是个环路，互联互通，即便北京到江苏的光缆出现故障，也可以通过浙江转到北京。因此，使得直播服务的网络质量更有保障，稳定性和安全性也更上一层楼，同时整个平台具备跨地区的自动容灾的能力。举例来说，直播云面向的群体是主播端或者播放端，终端用户群体遍布在全国各地。在云南的主播用户通过 4G 手机推送直播内容到就近的视频源站，如广东，这个内容推送上来后将被同步到全国六个其他的源站。全国所有终端用户播放的时候，就可以到广东源站获取数据。这样不仅可以提高网络传输的效率、保障直播的延时效果，同时当视频源站网络中断时，系统还可以自动的迁移到其他源站，通过 SDK 或者是通过域名解析两种方式均可进行自动化链路选择。又拍云选择 SDK 的方式进行容错设计，可实现秒级容灾，即广东出现问题即时切换到浙江的视频源。而域名解析的延时和生效周期会较长，是分钟级别的，最快也要将近 5 分钟。

传统的直播架构由于只有一个视频源站，无二层缓存。而又拍云直播产品采用全国分布式集群架构，除视频源站里还会有一层二级缓存，在源站与源站间合并回源，从而提升加速的效果，降低用户流量成本。又拍云能够做到 30 毫秒从香港推送到浙江的数据中心，到了浙江进行缓冲加速，进一步推送到全国的 CDN 节点，根据客户的需求定制化配置，最快是 1 秒。也就是说，1.03 秒后观众就可以看到演唱会直播的内容了。

4、 云直播的整体框架

直播云的云化，主要是解决了视频流上传、处理和分发的一系列问题。用户只需要实现采集和播放即可。云直播整体框架包括了运维管理中心、业务管理系统、服务端核心系统和节点集群模块。我们选择几个比较重要的模块进行讲解。

如上图所示，整个运维管理中心对我们的源站进行监控，对流量进行监控，对网络进行监控。包括现在全国的用户到我们的节点之间访问的网络效果是怎样的，我们的核心，节点之间的传输速率是怎样的等等数据，参考这些数据，我们能够进行一个合理的调度。另外就是设备的监控，我们可以做到针对单台设备的单个硬盘现在的网络情况、带宽情况和 CPU 情况，去做一些智能调度。我们的内部监控，主要针对我们服务端的核心系统，包括我们的智能调度，负载均衡，流媒体处理中心，还有我们音视频的处理等。音视频的处理在后期讲到点播或者是做一些处理的时候，我们可以详细介绍我们又拍云的整个音视频处理的过程。还有客户需要的防盗链，我们又拍云可以支持后台自主的进行动态配置防盗链，也可以升级配置健全的防盗链。还有后端可以自助配置。我们一直主打的概念，就是一个帐号，一套 API 可以实现所有的功能，也就是我们一直提倡让创业更简单的概念。

还有一些防攻击的数据，说监控的时候我忘了说一点，我们现在所有的平台给到用户的监控数据，用户都可以在我们的客户端里面看到，移动、联通、电信用户访问延时情况还有带宽速率的情况。当你遇到攻击的时候，我们会详细的帮你统计攻击的类型，这些通过页面后台就可以看到。我们最新一版升级版的数据，可以按照省份和运营商进行统计，根据每个省份运营商的访问量级，我们可以调整他的分布。或者说当你做广告投放的时候，可以定位看看能不能有比较好的效果。或者某个区域的用户，可能故障率比较高，某个城市没有明显的变动，个别的用户终端访问可能存在问题，依靠这些数据可以缩短我们排查故障处理的时间。

四、核心系统介绍

核心系统里面有几个重要的东西，第一是智能调动中心。它负责整个云 CDN 系统的调度，根据网络质量、节点健康状况进行诊断。我们内部 ES 把所有的日志信息进行搜集到我们后台，可以通过图像化的样式直接展示出来。每个边缘节点访问的状态码是多少，占比有多少，它的访问数是不是突然有增高的情况，我们可以通过在线筛选的实施，每五分钟日志访问来源的情况。负载均衡和 API 接口集群，后面讲功能的时候会提到。还有边缘节点集群，我们现在除了比较健硕的六个核心数据中心以外，还有 150 多个的边缘节点组成上下行的边缘节点集群。流量调度和流媒体处理中心支持的功能，在功能模块里面会做单独的讲解。

从软件架构上看，大家可以看到通过我们的推流到我们播放器中间，第一个是我们可以提供自己的 SDK 去做一些容错设计。比如说大家如果不用 SDK，通过域名做访问可以做一些容错调度。只不过他的切换的时间比较长，SDK 秒级就可以把我们的数据直接切走。如果是通过域名的话，最快需要 5 分钟，更长需要 48 小时。

我们还会针对 GOP Cache 做一些调整的设计。可以把我们的 GOP 调整成 0.05 秒，根据用户具体的要求达到最好的效果。体现功能即第一延时少，第二秒开。不管是我们的 GOP 的大小，或者播放器的调整，其实都是根据我们的具体业务进行的。因为他其实就是一个取舍，你调整大了或者调整小了，是针对特定的需求的，不是对所有的用户都通用。

最后一个就是我们所有的边缘服务器，有很多用户问我，你们的边缘服务器是不是能够直接支持三协议。比如说 RTMP 和 HLS 都支持，RTMP 和 RTMP 转 HLS 和封装之后，FLV 都可以在我们的任何一台边缘服务器中直接播放。

五、功能

我们做了这么多事情，花这么大价钱搭建我们健硕的核心网，是因为我们希望能够在功能上去为创业者服务，创业者刚开始做的时候可能会遇到很多问题，我们提供场景化的模板，多协议支持，现在支持 HTTP、RTMP，这个月底也将会升对 HTTPS 支持进行升级维护，在我们流媒体里面，也可以通过使用协议在后台进行自动化的配置。又拍云首家发布基于 WEB 的 SSL 自助配置，可以直接提交自有 SSL 信息在我们页面上进行配置后直接使用，不需要做过多的申请和等待等。

还有我们从推流端到播放端都提供了相应的 SDK ，推流端可以提供安卓和 IOS 版本。帮助你快速建立数据流的采集，避免很多用户做推流端的时候有一些不规范的地方，比如编码等。而通过 SDK 我们可以做一些设置，将其标准化，提供美颜、前后摄像头切换、闪光灯开启、码率分辨率调整等。如果说现有的 PC 端用户通过 OBS 推流上传的是非标准的协议的版本或者音视频的版本，我们可以帮你们统一转成 H264、AAC 。比如说火猫为了展示更好的效果给终端用户，让他们的播放器播放出来的画面分辨率统一，编码格式一致，要求厂商提供统一编转码设置服务等。

防盗链，是很多用户比较头疼的地方，当咱们 APP 应用做的比较好，有知名主播上线的时候直播、或者有提供的版权内容服务的时候，就会有很多盗链服务的风险。又拍可以提供合理的防盗链解决方案，可以在我司后台进行自主配置。常用的像 UA 的黑白名单、动态的 Token 防盗链、回源鉴权等。其他配置功能可以在后台进行自主操作。还有对 PULL 模式的支持，如果有一些大型赛事做直播或者做一些比较重点的赛事直播，可以提前通过 PULL 模式把数据推给我们，我们直接推到边缘。等你开始直播的时候，再让用户进行观看，这样可以第一达到秒开，第二可以让保障直播流的流畅稳定。

高效转码，转码在很多用户里面有很大的需求。为什么？第一个你的原始流推上来的时候由于推流端设置的问题源码率是大小不一致的，而你播放终端的网络又比较差，有可能满足 200K 的，有可能 500K 是比较流畅的，这时就需要进行统一转码。但是转码设备如果由用户自己搭建的话，投入的成本比较高。现在基本上除非是硬件转码的设备，业内做用服务器搭建的话，一台普通服务器可以支持同时转码 10 路或 8 路，这是属于比较正常的状态，还需要看你源码率的大小。

直播录制，是广电总局最新的要求。所有直播 APP 必须做直播录制流程，便于查看和存档。很多人希望做直播录制，录制完后直接去做点播，不是所有人都把流推到自己服务器然后转到 CDN 厂商去做。因为 CDN 厂商在边缘节点有大量的丰富的上行节点，推上来的效率更高一些。这部分用户他的源是没有直播流的，就需要 CDN 厂商提供直播录制的服务，当然我们也可以转推路给用户由用户进行自主录制。

异步音视频处理，我们录制完文件之后，视频流的编辑、截图或者视频大小的调整等服务需求都可以在音视频处理功能里面实现。

还有一个广电总局的要求，即鉴别非法、暴力的东西。业界都是用直播流截图的办法做，对直播流进行截图，再针对图片进行非法鉴别，当然也有做用户直接做直播流的鉴别，不过这样消耗比较大。还有自定义的延播功能，自定义性能比较高，你可以选择，五分钟之后才播放你现在的流或者秒开地播。我们刚才说了从推流端到分发，播放端需要注意什么？我们现在提供播放器 SDK IOS 和 Android 版我们已经发布到 GitHub 了，大家有兴趣的话可以到我们又拍云文档中心下载，里面有详细的说明。还有一个就是 对 P2P 的支持。

在直播的整个流程里面很重要一点是流状态的通知，它分为好几点。第一点比如说你的流的是否播放了。主播是否推流、断流了，你怎么排查你的主播端的故障，因为有 90% 故障都是来源于上行端，我们希望搜集到我们主播端的帧率，他推上来的码率，他推上来的节点，他现在的速率是多少等。通过测试的方式，直接从我们的流状态里面反映出主播现有的情况。还有针对下行访问数据的收集。一般比较大的厂商会自己去做，可以搜集流的现在卡顿的情况，因为每个人对卡顿的算法不一样。所以说我们在后期也会把流状态通知的接口到 SDK 里面，在第二个版本直接发出来。这是在大数据分析的模块里面，我们希望把这块数据直接通过 API 和 web 展示提供出来。

自定义流禁播，就是当你遇到涉黄的时候，如何快速的把流禁播掉。一般情况下的做法是你请求我们的流禁播接口，然后把这个流的上行推流停掉。我们上线一个自定义的流禁播的功能模块，你可以直接在后台里面进行配置。比如你禁播这个用户多长时间，禁播 IP 或者是禁播流名，可以设置三个频率，第一次禁播五分钟之后自动解禁，第二次禁播三个小时，第三次永远禁播，不让他推流，通过不同维度的流禁播来提供较好的直播服务。

另外就是实时转码样式表的支持。当上行直播流编码比较复杂和多样化的时候，用户可能不再局限于我们只针对某个直播流去做转码支持。这个时候我们可以提供类似样式表的服务，你可以选择建立你的样式模板，选择你所需要的功能项。比如标准转码之后你的分辨率是多少，你要求现在要降的码率是多少，还有其他的格式要求等都可以在转码的样式表里面建立自己的样式表。可以选择你现在推的流里面用哪个样式表去处理。

自定义访问限制，可以针对 IP 和来源用户进行访问设置；延时追赶，可以做到当有延迟累计的时候进行跳帧的延时追赶行为；以及智能调度、直播时移等功能；流时长统计服务，主要是用户需要和主播进行每个月的直播结算场景来源，他这个月直播多长时间，收入有多少，通过流时长统计接口反馈信息能得到一个完整的数据。以及打水印功能，可以在推流端的 SDK 里面进行设置定义好后提交上来。而我们希望建立一个自定义的水印版本，你可以选择 logo，和偏移量，宽度是多少，还可以针对某路流去打水印。因为可能你同一个挂载点下推了不同的流，某个流可能是有版权需求，你卖版权的时候不希望把你自己的 LOGO 打上去或者是对方要求不能把你的 LOGO 打上去。我们通过这种比较方便的方式就可以实现自定义水印的功能。

当然还有很多其他的功能，在这里不做详细介绍了。大家后期可以跟我们进行详细沟通，我们可以提供很多自定义的服务支持。而且很多功能性的介绍大家都可以在我们又拍云的文档里面进行查看。

六、实施效果

我们再来看一下实施效果。这是我们最新实际测试的效果图，北京用户主播推送出来，左边框是用户观看的视频，右边是推流的视频界面。北京用户主播在北京观看，平均下来他的延时是 1.1 秒。这里展示的是 RTMP 流。右边是杭州主播在北京观看，延时是 1.3 秒，这在业内来说是比较好的数据。