中科研拓提供直播app软件开发外包服务，方案成熟可靠，已有多个成功上线案例。
有直播app开发需求，可联系我们：400-0316-532
注：每一种架构在一定程度上都有参考的意义。UCloud 将邀请到了在直播、抱抱直播、Shou.tv和一起玩耍科技的技术专家，分享他们在海量服务架构探索过程中的技术实践。
讲师介绍
曾凯源
UCloud流媒体研发总监
主要负责UCloud视频云和 CDN 产品的研发工作。拥有近十年的互联网研发经验，在云计算领域具有丰富的经验。此前，曾任职于腾讯，分别负责海量云存储系统、海量CDN系统以及微信支付、彩票系统的性能优化等工作。
演讲提纲
本次主要为大家解析UCloud自有直播云平台架构，分析平台架构短板以及在用户规模快速增长下的架构演进过程。
-
直播场景简介
-
直播云架构
-
核心架构演进
-
容灾及故障处理
直播场景&直播服务架构
直播场景
首先，介绍当下很火的直播场景。目前对直播场景的基本分类主要有媒体&活动直播、游戏直播、秀场直播和社交直播。
媒体&活动直播
特点：单向，无交互，流数少，延迟容忍度高 >10s；包含电视转流、演唱会直播等。
这类目前对于直播的技术要求较低，低上行，高下行。
游戏直播
特点：单向，无交互，流数多，延迟容忍度高 >5s；目前国内CDN产商抢得最激烈的一块。
本身的业务场景其实并不需要那么低的延迟。延迟是2秒、5秒还是10秒其实对体验的影响不是十分大。不过由于竞争激烈，拉高了延迟门槛。
秀场直播
特点：单向，文字交互，流数量多，延迟容忍度低 2~5s；这个是目前大家都能看得到盈利模式的一种。除了主播在播外，观众可以点赞，文字，送礼物，有一定的交互性。所以对直播的延迟要求苛刻，越低越好。推流主要是专业主播PC端，流数量多。
此类直播也称为美女秀场，市场上存在大大小小公司，基本带宽在1~5G。 秀场平台非常多。
社交直播
特点：单向，文字交互，流数量非常多，延迟容忍度低 2~5s；社交直播和秀场直播，在交互上类似，区别比较大有两点：1. 秀场一般都是有限的主播把内容运营起来，推流的数量较少，一般是<100路；2. 社交直播是路人即可产生内容，所以直播的流数会上升到1000，甚至10000。
目前最火的一块，有映客，在直播，花椒等。整体直播云的设计是以满足技术及并发要求最高的社交直播需求为主要目标。
直播服务架构解析
要完成这类直播产品，需要有哪些模块支撑？通常包括直播内容采集、直播后台系统和直播内容播放三个模块。
-
内容采集：采集的方式有很多，从一般几十块PC摄像头到几十万的专业录制编码设备，还有移动端的手机前后置摄像头；分布式推流：这里是比较成熟的架构，用户在推流之前会通过名字服务，一般是DNS智能解析或是自有按IP调度系统获取最靠谱的推流节点，然后把流上传到服务器。
-
直播后台系统：在分布式推流节点“接入”了用户流之后，后续一系列的分发、转码、截图、录制、存储等构成了直播后台系统；这里根据不同的业务需求，需要有不同的后台服务来支撑。
-
直播内容播放：这个就比较好理解了，一般输出是PC屏幕、手机、现在还有VR头盔。
直播云的云化，主要是解决了视频流 上传、处理和分发 的一系列问题。用户只需要实现采集和播放即可。
直播云架构
直播云最核心、难度最大的部分是直播的流分发网络的架构和分发算法设计，直接决定了整套服务可支撑的并发数和质量以及服务成本。
以下重点分析UCloud核心分发网络这块的设计和演进。直播云架构主要有核心的流分发网络、运营子系统和业务逻辑子系统三大部分构成。
运营子系统包括了调度系统、监控系统和故障处理系统。
-
调度系统：实现直播索引及调度的能力，主要解决三个问题：用户去哪个IP推流？流如何分发？用户去哪个IP观看？
-
监控系统：实时监控整套分发体系的上行压力、下行压力、中间网络质量及服务状态等。
-
故障处理系统：负责IP、机房、片区网络不可用时的处理。
业务子系统包含了非常多的系统，这里列举几个常见的。
-
实时转码：是一个集群，作用是在用户推流码率较高（比如720P）、但是会有移动端观看的用户时，需要实时转成360P低清晰度的流；这个子系统实际服务能力非常有限，一台8核设备只能实时转10 路流，如果来1000路，就需要100台。这里给一个重要经验：如果做不到按流的按需实时转码，建议不要搭建实时转码集群。因为成本极高！
-
实时截图：架构和实时转码类似，一般单机可处理100 流。
-
实时录制：即将直播内容实时保存下来存储成点播文件。
核心架构演进
那么，庞大复杂的直播云背后，核心架构的挑战到底有哪些呢？以下介绍一下UCloud直播云最核心直播流的分发网络架构的演进。
直播流的分发网络主要挑战：
-
高并发，高上行，高在线。
5亿中国人已经离不开在线娱乐，2006年-2015年，月度覆盖人数增长5倍 ，每人每天花近一个小时用于在线娱乐，2007年到2014年，有效使用时长更是增长15倍 ；不同于传统的CDN分发模型，直播是流式的数据，主播产生内容、云服务进行实时的处理和分发，对上行的带宽和质量要求也非常高。以最近融资的映客为例，同时在线主播10000 ，观众50000 。
对比于传统的CDN，这里有个重要的架构考虑是需要支撑高上行的带宽。
-
热点时间集中直播流的分发网络。
透过我们对大量直播客户的带宽观察发现，直播的高峰期集中在晚上22点~0点，产品以“你丑你先睡，我美我直播”为宣言，在此期间的带宽是平时的5~10倍。
-
带宽成本高。
上行带宽，下行带宽，中间转发的带宽，总体带宽成本非常高。
-
分发质量要求高。
传统的视频点播，有一个源站，一份文件可以在发布的前一天把文件分发到离观众最近的节点，上行哪怕再慢些也无所谓，在直播的场景，越来越多的交互形式，需要实时把直播内容尽可能快且稳定的传输到观众端。
总结：这可能是迄今为止最难设计的分发网络。
核心架构演进
直播云最核心的架构－直播流的分发网络经历了三次大演进。
V1.0 版本——一级DC
使用多线BGP进行全国覆盖，凭借BGP技术解决解决了多运营商间转播的问题，电信主播、移动观看也流畅，同时也能兼顾到一些小运营商。
-
全国延迟区间在40ms~100ms；部分地区用户网离BGP距离长，路由极易不稳定，高峰期容易卡顿。
-
由于成本较高，在最初期仅支持4000路上下行，能满足较小规模的直播客户，并且需要设置较大的播放缓存来对抗网络丢包和延迟，直播内容延迟高。
-
容灾方面，单机房无异地容灾，遇到光纤挖断，机房变更等会是致命打击。
V1.5版本——高突发架构
-
高突发架构：引入了CDN供应商到架构中，快速优化下行瓶颈的问题，下行容量增大N倍，基本不成为瓶颈；
-
流转推：将热门主播推流到合作CDN进行分发，从架构层面看，是同一分出流量进行了多份的复制；
-
DNS智能解析：使用智能解析DNS按运营商、省份、用户比例将播放带宽切到CDN供应商。
对于中小型的UGC 产品来说，带宽上已够用了。但是BGP的瓶颈仍然存在，并且合作CDN的质量不可控。下行的延迟起到了一定的优化，但和行业最优还有不小的距离。于是又诞生了V2.0。
V2.0 版本——两级DC＋OC架构
-
架构优化：引入离用户最近的OC小机房，推流端也通过DNS智能解析的方式，将上行分散到各个OC点。
-
质量上，OC到BGP机房的路由是可控的，进行针对优化，拉城域或区域专线，流分发稳定性非常高，已可支持1秒播放buffer，整体的直播延迟最低可以做到1秒。
-
瓶颈：由于仍要通过BGP对跨运营商的流做中转，所以上行瓶颈问题没有得到解决。
-
缺点：BGP的分发带宽上升，对于不活跃的主播，从BGP 1 to N 的形式， 演变成 1 to M to N，在调度上需要算法来决策是否要下行放到OC上。
-
容灾能力：BGP机房仍然是链路单点。
架构V2.0 对于架构V1.5 来说， 单路流的成本其实是有上涨，但是质量上起到不小的优化。在V2.0 中我们也对BGP进行了带宽扩容以应对业务增长。
V3.0 版本
目前最新的架构V3.0，引入了区域三通点，为BGP机房做容灾，对于同一区域如都在华东的推流和分发，直接走区域三通机房，BGP机房和三通机房部署多个，故障是只要调整路由即可。
三级多通架构
架构优化：引入区域三通点，为BGP机房做容灾，对于同一区域如都在华东的推流和分发，直接走区域三通机房，BGP机房和三通机房部署多个，故障是只要调整路由即可。
-
分发策略：对同区域的同运营商的OC先进行分发，如广东电信有10个OC机房，如果推流和播放是发生在这10份机房内，就可以完全不经过BGP和三通点，降低了BGP和三通架构上的带宽瓶颈。
整套架构由BGP、三通机房、OC机房和合作CDN构成，中间的转发策略和链路非常多，需要通过主播所在地域、观众所在地域，热度、质量、成本的折中来实时调整分发的路由。
两级多路由回源容灾
除了引入三通点外，还做了一些容灾设计，这里介绍一个典型的多路由容灾。
-
客户端到接入OC：使用DNS做负载均衡，同时配置多个OC节点的IP，降低单点故障影响，同时监控单线路如广东电信配置是否存在单点。
-
OC回源：使用自有索引体系管理路由，为每个OC节点至少分配两个以上的回源路由，并实时监控上报各个oc回源质量与各中转节点负载信息。
前期静态纯人工路由维护，运维压力非常大，多路由容灾后起码节省了30%的故障处理人力。
故障自动处理
对于庞大数量的机房，故障的处理也不容易，比如一个机房IP down了，人工判断如何迁移 IP的带宽 是可以的，如果是一个OC机房或三通机房，纯靠人工计算带宽和配置，就很容易出错。
所以有了直播云非常重要的一个故障处理模块： 带宽、负载动态路由规划系统。