2016 年 10 月 29 日，又拍云主办的 Open Talk No.26 在“魔都”上海 3W 空间成功举办，此次活动邀请了直播领域开发一线的技术大神们，聊一聊直播平台的架构与优化，如何化解项目选型、开发上线、迭代过程、性能优化中遇到的挑战与经验。又拍云高级产品经理孙曦凭借在直播行业多年的研究、实践，对 CDN、云存储、互动直播等领域的技术、需求、用户有较深的理解和丰富的实践经验，在活动中围绕“又拍直播云系统探索”的主题进行了详细的分享。

以下就是孙曦的分享全文啦~

大家下午好！我是又拍云产品经理孙曦，主要负责又拍直播云系统的产品规划及设计，今天就主要跟大家谈谈与直播业务相关的一些功能。

直播的挑战：画面和设备

首先我们来看下这张图

上面的图从2015年开始流行起来，在朋友圈中也是频繁转载，当时短短一年的时间内市面上就出现了如此多的直播App；到现在，直播App数量已经达到了数千个，市场规模达到百亿级别。大家身为IT行业的业内人士，紧跟新兴热流，对这应该也是了解的。

不过现在的直播跟前几年火热的直播还是不一样的。早期的映客、花椒是社交直播，但是社交直播只是直播一个很小的分类。现在的直播已经涉及到我们生活的方方面面，比如有的主播做旅游，有的主播做户外探险；前一段时间的巴西奥运会，有的主播做了体育直播，除了这些，还有发布会、美食、教育、影视、新闻等直播。

说到直播，我们来回顾一下直播的发展历史及当时的特点。

传统直播

在2000年左右的时候，传统直播已经非常成熟了，它的直播内容是以电视信号传输。电视信号传输，跟现在的直播相比，控制得严格一点，那时你看到的内容可能有三到五分钟的延迟。它的信号不是通过互联网而是通过模拟信号传输，传输非常稳定，同时传统直播是单向、无交互的。

直播1.0时代

当时主要是以六间房等为主的媒体秀场直播。这个时候画面的清晰度跟现在相比有较大的差距，受限于当时一兆、两兆的家庭带宽，它的直播画面比较模糊，特点是单向、数据量小，延迟容忍度高，延迟大于5秒，主播地域分散。

直播2.0时代

前几年，随着斗鱼、虎旗等游戏直播的发展，直播的画面有了巨大的提升，而且我们能够在电脑上观看游戏直播，这样就好像自己真的在打游戏一样。那这时的特点是：单向，文字交互，流数多，延迟容忍度高，延迟大于5秒，虽然自身业务对延迟要求不高，但是由于竞争较大提高了要求。

直播3.0时代

随着互联网时代的发展，直播行业有了较大的改善，此时主播可以在生活的每个方面进行随时随地的直播、随时随地的分享。直播3.0的特点是：单向或双向，比如主播连麦交互，文字交互，流数多，延迟容忍度低，延迟控制在2-5秒。

直播4.0时代

到了直播4.0时代，也就是现在所说的VR直播，它的数据量比以前更大，交互性更强，会让人有身临其境的感觉。VR直播对于设备的要求非常非常高。暴风在2015年上市的时候，创造了一个股市的奇迹，当时市价从7元升到250多。它生产的眼镜，让人如同身临其境，虽然硬件给观看直播带来了一些新鲜的感觉，但是也带来了一些不必要的麻烦，比如观看的时候，用户对设备的依赖感特别强，而且受地域的影响，如果没有外联设备，体验就大打折扣。 直播4.0时代的特点是多维互动，数据量大，延迟容忍度2-5s，虽然目前技术条件不够成熟，体验还不完美，但是是大势所趋。

了解了直播的发展过程，总结一下直播行业遇到的挑战：

• 首先就是我们刚刚一直提到的画面的高清晰，以及观看的高流量。
• 其次，我们观看直播的设备越来越丰富，不光是在电脑上、电视上，同时在手机上也可以进行观看，这就会带来一些潜在的问题。直播非常烧钱，需要大量的服务器资源、带宽资源，平时服务带宽一两个G，突然有一天来了上百万的直播流请求，会让服务器崩溃。

这是直播行业遇到的一些挑战，也是亟待解决的一些问题。

又拍直播云服务架构

上面介绍了直播行业的发展及面临的挑战，接下来我们探讨一下直播的服务架构。

通过下面的图片，大家可以看到，其实直播云架构早期是很简单的，但是直播对直播源站要求是非常高的。

几年前云服务厂商，通常是单点配置，但是单点对容错性支持得不是很好，一旦一个服务节点有故障或者是机房的网络有故障，很难在短期内完成切换所以又拍直播云在构架之初，就提出了一个概念：六个数据中心的视频源站集群。如图所示：

又拍直播云在人口相对密集的浙江、北京、四川、上海、广东、河南六个地方建立了视频源站，彼此之间通过私有光纤打通，真正实现了内网级别的传输效率。

可以观看上面的效果图，河南电信主播推流到推流边缘，四川联通用户请求到拉流边缘，河南视频源和四川视频源间通过光纤传输，那么整体直播传输速率会非常非常快，大概每一层的传输时间20毫秒左右。

还有另外一个好处，如果六个视频源当中，突然某个视频源挂了，又拍云可以通过一个负载均衡和实时调度系统维持源站的可用性，比如在广东源拉取四川源内容的时候，四川源站故障，广东源会切换至河南源进行交互，这样可以保证非常快的切换和传输速度。

刚刚讲的是整个直播网络的架构，其实服务器能够直播是需求，市面上现在有很多流媒体服务器，除了一些商业版本，开源版本也很常见。对于开源软件的支持力度，中国还是比较好的，但是只有开源流媒体服务器是不够的，又拍直播云搭建了一个业务网络，来承载这个高并发的直播系统。

从上图可以看到我们做的一些伴生进程。

• 最左边是负载均衡，它的主要作用是对边缘服务器、源站服务器的健康状况进行探明，进行实时的调度。
  

• 第二个是配置系统。这个是跟又拍直播云业务相关的，使用直播业务的同时，可以通过我们的页面配置系统进行业务的配置，这个平台是开放给所有用户的。配置系统的优势在于高效率：我们可以在页面端创建一个直播空间，关联直播域名，添加转码流和录制流信息，这一系列的操作从配置到生效，只需要5到10分钟左右。
  

• 智能路由。智能路由的作用是实现主播端跟用户端访问直播云系统时如何做到整个链路最优的传输效果。
  

• 日志模块，它分为两块，一块是调试日志，另一块是与业务相关的日志。调试日志跟整体的线上业务息息相关。举个例子，某一个用户观看直播卡了反馈给云服务商，通常是很难定位到问题原因的，又拍云这一套流媒体系统可以通过用户请求流的连接id精确定位到用户的IP，他连了哪一台服务器，这台服务器和哪台服务器进行交互，中间的网速是怎么样的，这些可以在日志中详细地显示出来。其次是一些和业务相关的日志，如果使用直播的客户需要知道今天大概有多少人看这场直播，那我们就可以通过日志的形式导出，可以看出每一个用户的IP情况、他是从哪个网站的来源、他看了多久、使用了多少的流量，这些都可以通过用户日志分析出来。

• 转码系统，现在一个主播将画面推上来了，很多用户的网络状况可能不太能看得到高清的码率，通过转码系统可以将原始码率进行转换。从市面上来了解的话，硬件转码性能会稍微好一点，但是价格昂贵，相对来说软件转码性价比高一些。如果软件方案，用服务器堆转码资源的话，一台服务器最多转八到十路左右的直播流，如果有一百个主播同时在线，对服务器和硬件的消耗非常大，维护成本也很高，平均一到两个月，一台服务器的损耗就很严重，但是通过又拍云的转码系统可以为客户节省很多技术成本和维护成本，减轻开发负担。

• 业务接口，这个直播间的一些在线人数信息以及开播关播时间等信息可以通过业务接口查看我们还可以对之前所说的配置系统的一些操作通过接口实现给到咱们。因为对普通用户来说，页面上配置很简便，但是对程序员来讲，一行代码可以搞定的事情，就不想通过页面操作，简化了流程。
  

• 安全模块。它其实也有两部分，一部分是对直播流的保护，对于直播流的保护，现在市面上有各种各样的方法，比如动态token防盗链，IP黑白名单等。其次还有关于服务器，机房网络的保护。
  

• DNS模块。这个主要体现在两个方面，第一个方面是我们的用户如何连接边缘服务器。另一个方面是节点与节点之间的传输，它是通过自有DNS进行内部域名解析。这个跟通常使用的DNS有一些区别，它主要是故障切换的时候，DNS切换特别快。比如某一些地区的流量、带宽突然增大了，通过公网DNS解析可能需要10分钟到1小时不等，通过内部DNS只需要1分钟左右。
  

说完了直播的核心模块，其实它还有一些辅助的模块。

最左边是运维管理中心，运维管理中心的监控有很多层面，从源站、流量、网络、设备到链路监控，如图所示：

其次是业务系统。直播客户来使用又拍直播云，在业务管理系统里可以清楚看到使用情况、用户分布情况、用户的使用时间，还包括质量的监控，比如直播流流畅性的展示、直播流带宽的展示。

另外还有一些集群模块，集群模块是硬件化的东西，我们需要保护这些集群，搜集集群的日志，这些都与整个直播媒体中心是息息相关的。

又拍直播云，同时满足直播业务的架构、功能

说完了直播的架构，最后说一下直播架构产生的功能，这些功能跟想做直播厂商是密不可分的。

• 多协议支持（同时支持http、rtmp、https协议，一个域名三种协议)
  
• 推流SDK，包括Android、iOS
• 防盗链，全民自动token
• 预热模式支持
• 实时转码
• 直播录制
• 异步音视频处理
• 直播流截图
• 直播鉴黄
• 秒开
• 播放器SDK
• P2P支持
• 流状态通知
• 自定义禁播
• 连麦SDK
• 自定义访问限制
• 延时追赶
• 智能调度
• 美颜滤镜
• 流时长统计
• 视频水印

下面的图片显示的是又拍直播云的实施效果，几乎没有延迟：

我们理想状况下实施出来的状态是：

北京的用户观看北京的主播，最快1.1秒延时；

北京在用户观看杭州的主播，最慢1.3秒延时。

直播延迟影响因素非常多，编码器有延迟，服务器传输有延迟，播放器也有延迟，比如你的播放器获取了一秒钟的数据，你不一定能放，因为播放器设置了3秒的缓冲区，一定要等三秒数据加载完毕才能正常观看，此时延迟就增加了3秒。

此外还有硬件上的消耗，比如解码时间、编码时间，延迟的影响是方方面面的，对于每一个想要直播的用户来说，对于延迟的标准是不一样的，有的人觉得要一秒钟之内；有的人是五秒钟之内都没有问题，低延迟和高流畅是不可兼得的，所以需要不断调整各种参数，达到每个人期望的效果。

对于延迟要求比较高的用户，直播的时候可以开启一个低延迟模式，延迟会非常非常短，但是这有个弊端，如果受到网络的影响，画面会有问题。如果延迟把控得不是那么严格的话，那可以推荐一个比较稳定的方法，比如两到三秒的延迟，网络抖动一秒钟的时间，客户端都完全不受影响。

最后说一下我们又拍云。刚刚有介绍到又拍云是完全云化的六大数据中心，那接下来就是具体的介绍：

• 又拍云有150+国内加速节点，这150个节点可以开放给所有的用户使用；
  
• 4000+服务器；
• 1.5TB的带宽；
• 每天500亿次的日均请求；
• 20万的付费用户；
• 首家实现本地运营商覆盖的CDN，拒绝跨网调度，服务更稳定；
• 首家实现客户自主控制的CDN；
• 唯一实现安全透明化监控的CDN；
• 唯一带有计算功能的CDN；
• 业务服务响应速度最快的CDN;
• 可定制的柔性CDN。

又拍云的宗旨是让创业更简单，让想创业想做直播的用户在接入我们之后更高效。如果各位想做直播服务的话，开发成本很大，开发时间也会非常长，那这些可以考虑交给又拍直播云。中国平安、恒大金服、美拍、美团、蘑菇街、乐视、有赞……都是又拍云的客户。

我今天的分享就到这里，谢谢大家!

又拍云 Open Talk 是由又拍云主办的系列主题分享沙龙，秉承了又拍云帮助企业提升发展速度的初衷，用全干货分享的形态，为互联网从业人员呈现先进的IT技术、理念，帮助与会者不断提升自身的专业技能，推动企业更快发展。