云直播系统架构与传统直播服务的对比

声明：本文来自「又拍云主办的Open Talk——在线教育：技术让知识触手可及」的演讲内容整理。PPT、速记和现场演讲视频等参见“UPYUN Open Talk”官网。
　　嘉宾：羊能卿，又拍云首席布道师。拥有6年CDN、IDC、OTT技术经验。曾在帝联从事需求答疑、技术支持、技术竞标等工作，精通CDN、CACHE、NDC、DNS，电子商务应用网站等网络运维和工作原理。曾负责边锋战旗、熊猫TV、火猫、视云、触手TV、PPTV等流媒体CDN项目。
　　责编：钱曙光，关注架构和算法领域，寻求报道或者投稿请发邮件qianshg@csdn.net，另有「CSDN 高级架构师群」，内有诸多知名互联网公司的大牛架构师，欢迎架构师加微信qshuguang2008申请入群，备注姓名+公司+职位。
　　据数据统计，可以看出 2015 年是视频直播的元年。于2015 年年底的数据显示，直播的 APP 已经达到 200 多家，市场规模是在 90 亿左右，同时大平台的在线人数基本上可以达到 4000 个直播间，通过这些数据我们可以看出的网络视频直播已经来到了群雄逐鹿的时代。
　　直播类型
　　传统直播
　　传统直播基本都是单向传输，很少有做交互。类似于广电演唱会的直播，做交互都是放在秀场里做。只是简单的对外传输直播流，并且流数比较少，延迟容忍度高，基本都超过 10 秒，包括电视转流、演唱会直播等。
　　游戏直播
　　游戏直播也是单向传输，通过直播文字进行交互，利用弹幕或者讨论组进行沟通。最大的特点是流数比较多。游戏直播自身的业务对延迟要求不高，但因为竞争激烈提升要求，目前做秀场直播，要做到2秒。大家想想主播在打游戏的过程中，不管是在直播自己玩的游戏内容还是介绍玩游戏的心得，延迟并不是特别重要，因为更多的时候，在直播的过程当中，弹幕和讨论组跟直播流是分开的。
　　电商直播
　　电商直播的特点是单向、文字交互，流数少，基本是介绍自己的商品，延迟容忍度高于 5 秒。有跨国性的特殊需求，像海外淘，国外买手在直播自己的内容，这时候需要专业的厂商提供一些海外的内容。
　　移动轻秀场
　　移动轻秀场有两种方式：单向和双向。通过文字交互或者直接通过流进行聊天，流数比较多。延迟容忍度比较低，2到5秒已是非常大的要求。基本很多都是1到2秒之间。
　　直播+的概念
　　直播+使直播进入一个更多垂直的细分领域，包括O2O以及其他内容，比如新闻发布会、做培训宣讲希望别人看到自己的内容。这是直播架构带给更多的用户趋向性的东西，你可以通过直播的方式介绍你的产品、员工。
　　直播服务架构
　　又拍云的整个直播服务的架构，首先需要有一个信号语言，不管是电视信号源、摄像机信号源、还是桌面捕捉下来的内容，都可以通过推拉流的方式直接上传到一个视频处理的中心，进行编解码或者做一些水印等视频处理。比如给它们加一些打点的数据、字幕以及一些特殊说明等，这些都会在视频处理这块生成H.264和AAC的直播流，然后通过内容分发的网络，直接分发到全国的边缘，让用户能够通过各种设备看到我们的直播流。我们处理完视频流之后，还可以进行录制存储，录制完了之后还能够转成点播，满足用户的多样需求。还有虚拟直播的概念，包括现在一直播，在录下来的时可以转成FLV的流推出来，这是虚拟直播的概念，不是真正的现实流录播。
　
　　业务架构
　　常见业务架构
　　很多人在设计直播架构的时，通常传统厂商都会有一个集中的视频源。视频源能够让用户把视频传到单一视频源里面。单一视频源的优势是省事，做分支部署比较简单，但是故障率比较高，发送故障以后解决的时间较长。而直播，特别是互动类直播，大量的主播分布在各个运营商网络里，单一的视频源并不能够满足跨运营商传播的时效问题和网络的优化问题。通过单一视频，搜集到数据之后，再向运营商做一个分发，这是不靠谱的网络结构，那遇到云直播之后会产生什么样的变化呢？