app直播源码“助力”直播架构，走上探索之路

对于直播 app的开发来讲，app直播源码是一个非常重要的存在。直播架构在开发过程中也是一件非常重要的事情，如果架构的设立不能从根本上解决问题或防止问题的发生，那么在前端app运行时就会出现一定的运行错误。接下来主要跟大家简单分享一下关于直播架构方面的内容。

1.直播架构的演进

（ 1）CDN直播架构

目前最流行的直播架构就是 CDN直播架构，主播通过手机或电脑等设备，将自己的视频流上传到服务器，然后接入对应的CDN服务，通过CDN 进行网络分发，分发到各地的用户，然后所有的用户都可以看到主播的表演了。

（ 2）实时互动直播架构

实时互动直播并不能使用 CDN方案，因为CDN方案的性质决定了延时达不到实时的需求。通常，实现实时互动的架构中，主播把自己的视频流上传到服务器，再通过这台服务器分发给其他用户，再次采用合适的传输协议，并且延时可以做到很小，从主播到服务器再到观众的延时，加上编解码和抖动的延时，可以将延时控制在几百毫秒以内。虽然这个结构很简单，大势有一个缺点就是没有考虑到覆盖不同地区和用户的问题。

（ 3）分布式实时互动直播架构

主播的视频流在上传到接入服务器后，这个服务器会把这个视频流分发到我们所部署在世界各地的服务器，然后这些服务器可以接入本地的用户，再把视频传下去。在这个架构里，部署在世界各地的服务器，可以让用户快速就近地接入，整个视频流通过我们在互联网上做的分布式传输算法将它实时传输到世界各地的机房，而且可以避免机房或者骨干性网络的故障，从而对传输造成一定的影响。

2. 解决覆盖问题

需要先部署大量边缘服务器，边缘服务器的地理位置越接近用户约越好，最好是同一个 SP。在这里举个简单的例子，比如在中国国内，我们有的是大量的电信、联通和移动服务器，当我们发现接入的用户是联通用户，这时候就会去找到联通的线路，但是如果有边缘地区的用户观看直播，那么就必须部署很多边缘服务器。还需要有分配服务，如果部署了边缘服务器之后，用户还是没办法接入边缘服务器，所以就需要配套的算法，根据用户的SP，从而找到与其最为匹配的边缘服务器，进行接入分配。

3.DNS解析问题

目前的无线互联网，也就是我们常用的 WiFi已经非常普及。但是在使用WiFi时，会出现一个比有线宽带还严重的问题：DNS解析。在用户接入时，第一步就是通过域名解析到最近的服务器，但是做DNS解析式，无线网络的信号就会收到一定的影响，从而导致DNS解析失败，所以就需要优先使用解析，如果解析不到再用静态IP配置。

4.“骨干型”网络故障问题

在 “骨干型”的网络中，经常会出现问题，如果出现故障，可以通过路由的方式构建想用的应对方式。先连接到分配服务，分配服务会给出一批可接入的机房，如果接入机房坏了，就会立即切换到下一个可用机房，如果切换到下一个机房发现还是坏的，就会再次接入分配服务，从而继续寻找当前可用的服务器。

5.  蜂拥

这是一种在实时互动直播过程中非常突出的一种现象，在短时间内大量的用户进入频道或者使用服务就可以称之为是蜂拥，对于后台的冲击力也十分巨大。大多数直播后台的服务器每秒接入大概千的量级，但是对于蜂拥而来的用户，处理量还远远不够。这时候通常就会出现一个问题就是，后台处理响应的速度越来越慢，很多用户的请求就会出现超时。超时之后就会进入更多的请求，导致整个后台系统不能响应。

      总而言之， app直播源码固然重要，但是在开发过程中，如果不注意直播架构方面的问题，那么在前端运行的过程中也会出现不少问题。毕竟对于直播app来说，最重要的还是用户的体验感受。

本文声明原创，转载请注明出处。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/69907981/viewspace-2565163/，如需转载，请注明出处，否则将追究法律责任。