随着网络技术的迅猛发展，网络直播已不再遥不可及。各行各业以直播为基础的应用场景更是如雨后春笋，遍地开花，相关数据也显示，无论是国内还是国外，市场需求层出不穷，不仅包含视频门户、视频社交、在线教育、娱乐直播，企业视频协作、新闻媒体、金融、监控以及医疗等各行业均存在巨大的视频需求。

由此，很多有主播资源的公司都需要开发自己的直播app，但是缺乏相关技术开发团队。寻求直播app软件外包将是最好选择。

中科研拓基于十多年的软件研发经验，开发研发了多款直播app，可按用户需求定制各类直播app应用。

首选，分析下直播功能有哪些应用场景？

如图所示，直播功能的场景非常多样化，小编总结了一下，直播场景细分为以下几个方面：

1、在线教育行业：网校、慕课、K12、在线家教等

2、在线娱乐行业：美女秀场、游戏直播、演唱会直播KTV直播、婚礼直播、活动直播、体育赛事直播、装修直播、吃饭直播等

3、社交：明星社交、视频社交等

4、视频门户：视频直播等

5、企业协作：企业例会直播、产品发布会直播等

6、在线金融：视频理财咨询、在线签约过程录制、股评直播、大宗交易平台直播等

7、安防监控：家庭监控、幼儿园监控、早教中心监控、旅游景区监控等

8、远程医疗：视频问诊、专家会诊等

9、新闻媒体：现场手机直播、短新闻、庭审直播等

总结下来，基本分类主要有媒体&活动直播、游戏直播、秀场直播和社交直播。

媒体&活动直播

特点：单向，无交互，流数少，延迟容忍度高 >10s；包含电视转流、演唱会直播等。

这类目前对于直播的技术要求较低，低上行，高下行。

游戏直播

特点：单向，无交互，流数多，延迟容忍度高 >5s；目前国内CDN产商抢得最激烈的一块。

本身的业务场景其实并不需要那么低的延迟。延迟是2秒、5秒还是10秒其实对体验的影响不是十分大。不过由于竞争激烈，拉高了延迟门槛。

秀场直播

特点：单向，文字交互，流数量多，延迟容忍度低 2~5s；这个是目前大家都能看得到盈利模式的一种。除了主播在播外，观众可以点赞，文字，送礼物，有一定的交互性。所以对直播的延迟要求苛刻，越低越好。推流主要是专业主播PC端，流数量多。

此类直播也称为美女秀场，市场上存在大大小小公司，基本带宽在1~5G。 秀场平台非常多。

社交直播

特点：单向，文字交互，流数量非常多，延迟容忍度低 2~5s；社交直播和秀场直播，在交互上类似，区别比较大有两点：1. 秀场一般都是有限的主播把内容运营起来，推流的数量较少，一般是<100路；2. 社交直播是路人即可产生内容，所以直播的流数会上升到1000，甚至10000。

目前最火的一块，有映客，在直播，花椒等。整体直播云的设计是以满足技术及并发要求最高的社交直播需求为主要目标。

直播服务架构分析

要完成这类直播产品，需要有哪些模块支撑？通常包括直播内容采集、直播后台系统和直播内容播放三个模块。

1. 内容采集：采集的方式有很多，从一般几十块PC摄像头到几十万的专业录制编码设备，还有移动端的手机前后置摄像头；分布式推流：这里是比较成熟的架构，用户在推流之前会通过名字服务，一般是DNS智能解析或是自有按IP调度系统获取最靠谱的推流节点，然后把流上传到服务器。

2. 直播后台系统：在分布式推流节点“接入”了用户流之后，后续一系列的分发、转码、截图、录制、存储等构成了直播后台系统；这里根据不同的业务需求，需要有不同的后台服务来支撑。

3. 直播内容播放：这个就比较好理解了，一般输出是PC屏幕、手机、现在还有VR头盔。

直播云的云化，主要是解决了视频流 上传、处理和分发 的一系列问题。用户只需要实现采集和播放即可。

直播云架构

直播云最核心、难度最大的部分是直播的流分发网络的架构和分发算法设计，直接决定了整套服务可支撑的并发数和质量以及服务成本。

以下重点分析UCloud核心分发网络这块的设计和演进。直播云架构主要有核心的流分发网络、运营子系统和业务逻辑子系统三大部分构成。

运营子系统包括了调度系统、监控系统和故障处理系统。

1. 调度系统：实现直播索引及调度的能力，主要解决三个问题：用户去哪个IP推流？流如何分发？用户去哪个IP观看？

2. 监控系统：实时监控整套分发体系的上行压力、下行压力、中间网络质量及服务状态等。

3. 故障处理系统：负责IP、机房、片区网络不可用时的处理。

业务子系统包含了非常多的系统，这里列举几个常见的。

1. 实时转码：是一个集群，作用是在用户推流码率较高（比如720P）、但是会有移动端观看的用户时，需要实时转成360P低清晰度的流；这个子系统实际服务能力非常有限，一台8核设备只能实时转10 路流，如果来1000路，就需要100台。这里给一个重要经验：如果做不到按流的按需实时转码，建议不要搭建实时转码集群。因为成本极高！

2. 实时截图：架构和实时转码类似，一般单机可处理100 流。

3. 实时录制：即将直播内容实时保存下来存储成点播文件。

直播app开发主要挑战：

• 高并发，高上行，高在线。

  5亿中国人已经离不开在线娱乐，2006年-2015年，月度覆盖人数增长5倍 ，每人每天花近一个小时用于在线娱乐，2007年到2014年，有效使用时长更是增长15倍 ；不同于传统的CDN分发模型，直播是流式的数据，主播产生内容、云服务进行实时的处理和分发，对上行的带宽和质量要求也非常高。以最近融资的映客为例，同时在线主播10000 ，观众50000 。

  对比于传统的CDN，这里有个重要的架构考虑是需要支撑高上行的带宽。

• 热点时间集中直播流的分发网络。

  透过我们对大量直播客户的带宽观察发现，直播的高峰期集中在晚上22点~0点，产品以“你丑你先睡，我美我直播”为宣言，在此期间的带宽是平时的5~10倍。

• 带宽成本高。

  上行带宽，下行带宽，中间转发的带宽，总体带宽成本非常高。

• 分发质量要求高。

  传统的视频点播，有一个源站，一份文件可以在发布的前一天把文件分发到离观众最近的节点，上行哪怕再慢些也无所谓，在直播的场景，越来越多的交互形式，需要实时把直播内容尽可能快且稳定的传输到观众端。