云直播系统架构与实施

文章来源：http://geek.csdn.net/news/detail/89010

据数据统计，可以看出 2015 年是视频直播的元年。于2015 年年底的数据显示，直播的 APP 已经达到 200 多家，市场规模是在 90 亿左右，同时大平台的在线人数基本上可以达到 4000 个直播间，通过这些数据我们可以看出的网络视频直播已经来到了群雄逐鹿的时代。

直播类型

传统直播

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

游戏直播

游戏直播也是单向传输，通过直播文字进行交互，利用弹幕或者讨论组进行沟通。最大的特点是流数比较多。游戏直播自身的业务对延迟要求不高，但因为竞争激烈提升要求，目前做秀场直播，要做到2秒。大家想想主播在打游戏的过程中，不管是在直播自己玩的游戏内容还是介绍玩游戏的心得，延迟并不是特别重要，因为更多的时候，在直播的过程当中，弹幕和讨论组跟直播流是分开的。

电商直播

电商直播的特点是单向、文字交互，流数少，基本是介绍自己的商品，延迟容忍度高于 5 秒。有跨国性的特殊需求，像海外淘，国外买手在直播自己的内容，这时候需要专业的厂商提供一些海外的内容。

移动轻秀场

移动轻秀场有两种方式：单向和双向。通过文字交互或者直接通过流进行聊天，流数比较多。延迟容忍度比较低，2到5秒已是非常大的要求。基本很多都是1到2秒之间。

直播+的概念

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

直播服务架构

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

业务架构

常见业务架构

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

视频云业务架构

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

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

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

传统直播服务与直播云的对比

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

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

传统的直播架构由于只有一个视频源站，无二层缓存。而直播云中的产品采用全国分布式集群架构，除视频源站里还会有一层二级缓存，在源站与源站间合并回源，从而提升加速的效果，降低用户流量成本。

云直播的整体框架

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

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

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

核心系统介绍

核心系统中有几项较为重要的内容，第一是智能调动中心。它负责整个云CDN系统的调度，根据网络质量、节点健康状况进行诊断。我们内部ES把所有的日志信息进行搜集到后台，可以通过图像化的样式直接展示出来。每个边缘节点访问的状态码是多少，占比有多少，它的访问数是不是突然有增高的情况，我们可以通过在线筛选的实施，每五分钟日志访问来源的情况。另外是边缘节点集群，目前我们除了比较健硕的六个核心数据中心以外，还有 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

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

防盗链

防盗链，是很多用户比较头疼的地方，当APP应用做的比较好、有知名主播上线的时候直播、或者有提供的版权内容服务时，会有很多盗链服务的风险。又拍可以提供合理的防盗链解决方案，可以在又拍后台进行自主配置。常用的像UA的黑白名单、动态的Taken防盗链、回源鉴权等。其他配置功能可以在后台进行自主操作。

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秒，这在业内来说是比较好的数据。