开发视频直播app开发光知道框架设计是不行的

 新闻资讯     |      2020-08-03 14:10

开发视频直播app开发光知道框架设计是不行的

开发视频直播app开发光知道框架设计是不行的

开发直播过程中的点播业务我们需要了解其中的架构设计,这是直播app开发中至关重要的一步,更加的需要谨慎。

我们先简单的了解一下所谓的上行和下行是怎么一回事吧。

1.推流

主播端推流到上行边缘节点,然后再由上行边缘节点将流推到汇聚核心。如果在某些环境下,上行边缘节点到汇聚核心的网络状况不好,就需要多走一层中转。当汇聚核心收到流以后,并不需要主动将流分发到边缘节点上。像直播过程中的转码、录制等业务都是在汇聚核心完成的。

2.回源拉流

当有用户访问到汇聚核心时,汇聚核心会向其中一个回源节点进行拉流,此时回源节点会向客户源站拉流下行观看流程。

3.拉取直播流

如果边缘节点上有音视频流,则可以直接发送给观众。如果此时没有音视频流,则会向上一级回源。(上一级节点可能是中转节点,也可能是汇聚核心)这里需要注意的是,在以下两种情况下回选取是否走中转节点:汇聚核心的处理能力和下行边缘到汇聚核心的链路质量。

通常,下行观看流程与传统的CDN类似,存在直播数据cache,但由于时效性问题,cache的时间是直播最近几秒的数据,大多会采用内存cache的方式。

从网络架构的角度考虑,CDN是不可能只使用一个汇聚核心的。因为一个汇聚核心就意味着如果机房或网络出现故障,整个直播业务就会瘫痪。况且,一个汇聚核心无法覆盖全国甚至是国外所有的边缘节点。所以,在直播业务中为了节省资源和成本,大都会使用多汇聚核心的架构。

1.保证每个汇聚核心都有流,这样一来下行边缘无论到哪个核心都能拉到流。不需要使用数据库去记录流是推到哪个核心的。从架构的设计上来看比较简单直接,但是也容易存在一些问题。比如:容易造成带宽浪费、上行边缘到两个核心的质量无法保证、造成成本浪费等。

2.链路选优,也就是上行到一个链路最优的核心,下行也到一个链路最优的核心,将两个核心之间“打通”从而保证质量。通常国内使用3个核心就足够覆盖国内的区域和运营商,并且核心与核心之间可以采取专线为主、公网为辅的方式,从而起到一定的容错性。