直播边缘节点资源管控方法及系统与流程

1.本技术涉及直播技术领域，尤其涉及一种直播边缘节点资源管控方法、系统、电子装置及计算机可读存储介质。


背景技术：

2.在现有直播体系中，主播分布在全国各地，接受主播推流的物理机器节点也部署在全国各地。主播推流的时候，根据域名系统(domain name system，dns)解析获取离主播最佳的节点进行推流。但是，这种技术架构缺乏数据支撑，不具有科学性和严谨性，并且比较浪费资源，物理机器部署也难于扩展。


技术实现要素：

3.本技术的主要目的在于提出一种直播边缘节点资源管控方法、系统、电子装置及计算机可读存储介质，旨在解决如何科学部署边缘节点、既节省资源又能便于扩展的问题。
4.为实现上述目的，本技术实施例提供了一种直播边缘节点资源管控方法，应用于中心服务器，所述方法包括：
5.实时采集所有边缘节点的状态信息，所述边缘节点为连接于所述中心服务器的多个云服务器；
6.根据采集到的所述状态信息和预设逻辑综合判断所述边缘节点是否需要调整；及
7.当需要时对所述边缘节点进行调整。
8.可选地，所述实时采集所有边缘节点的状态信息包括：
9.采集每个所述边缘节点的资源使用信息、推流数目、每个流的实时卡顿率。
10.可选地，所述资源使用信息包括实际使用带宽、实际使用cpu核数、实际使用内存。
11.可选地，所述对所述边缘节点进行调整包括新增边缘节点、删除边缘节点、增加或减少所述边缘节点中配置的资源。
12.可选地，所述根据采集到的所述状态信息和预设逻辑综合判断所述边缘节点是否需要调整包括：
13.计算所述边缘节点上的实时总推流数目和所有流的实时卡顿率；
14.当所述实时总推流数目大于第一阈值或所述实时卡顿率大于第二阈值时，判断需要在所述边缘节点所在区域增加边缘节点。
15.可选地，所述根据采集到的所述状态信息和预设逻辑综合判断所述边缘节点是否需要调整还包括：
16.当所述实时总推流数目小于等于所述第一阈值且所述实时卡顿率小于等于所述第二阈值时，根据所述边缘节点的资源使用率判断是否需要删除所述边缘节点或调整所述边缘节点中配置的资源。
17.可选地，所述根据所述边缘节点的资源使用率判断是否需要删除所述边缘节点或调整所述边缘节点中配置的资源包括：
18.计算所述边缘节点的资源使用率，包括带宽使用率、cpu使用率和内存使用率；
19.分别设置各个所述资源使用率的等级阈值；
20.根据各个所述资源使用率的计算结果和所述等级阈值，判断所述资源使用率所处的等级，从而按照所述等级对应的方式判断是否删除所述边缘节点或调整所述边缘节点中配置的资源。
21.可选地，所述等级阈值包括阈值q、w、e且q>w>e，所述判断所述资源使用率所处的等级，从而按照所述等级对应的方式判断是否删除所述边缘节点或调整所述边缘节点中配置的资源包括：
22.当计算出的某个资源的使用率大于所述阈值q时，判断需要增加所述边缘节点中的所述资源；
23.当计算出的某个资源的使用率小于等于所述阈值q且大于所述阈值w时，判断所述边缘节点不需要进行调整；
24.当计算出的某个资源的使用率小于等于所述阈值w且大于等于所述阈值e时，判断需要减小所述边缘节点中的所述资源。
25.可选地，所述判断所述资源使用率所处的等级，从而按照所述等级对应的方式判断是否删除所述边缘节点或调整所述边缘节点中配置的资源还包括：
26.当计算出的各个所述资源使用率均小于所述阈值e时，判断需要删除所述边缘节点。
27.此外，为实现上述目的，本技术实施例还提供一种直播边缘节点资源管控系统，所述系统包括：
28.采集模块，用于实时采集所有边缘节点的状态信息，所述边缘节点为连接于所述中心服务器的多个云服务器；
29.判断模块，用于根据采集到的所述状态信息和预设逻辑综合判断所述边缘节点是否需要调整；
30.调整模块，用于当需要时对所述边缘节点进行调整。
31.为实现上述目的，本技术实施例还提供一种电子装置，所述电子装置包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的直播边缘节点资源管控程序，所述直播边缘节点资源管控程序被所述处理器执行时实现如上述的直播边缘节点资源管控方法。
32.为实现上述目的，本技术实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有直播边缘节点资源管控程序，所述直播边缘节点资源管控程序被处理器执行时实现如上述的直播边缘节点资源管控方法。
33.本技术实施例提出的直播边缘节点资源管控方法、系统、电子装置及计算机可读存储介质，抛弃传统的物理服务器部署方式，使用云服务器进行边缘节点部署，可以根据各个边缘节点的实时状态信息来综合判断分析每个边缘节点的使用情况，从而按照预设逻辑动态新增或删除边缘节点、增加或减少所述边缘节点中配置的资源，实现资源的最大利用效率，节省资源和人力。
附图说明
34.图1为实现本技术各个实施例的一种应用环境架构图；
35.图2为本技术第一实施例提出的一种直播边缘节点资源管控方法的流程图；
36.图3为图2中步骤s202的细化流程示意图；
37.图4为所述直播边缘节点资源管控方法另一种形式的流程示意图；
38.图5为本技术第二实施例提出的一种电子装置的硬件架构示意图；
39.图6为本技术第三实施例提出的一种直播边缘节点资源管控系统的模块示意图。
具体实施方式
40.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本技术，并不用于限定本技术。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
41.需要说明的是，在本技术实施例中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本技术要求的保护范围之内。
42.请参阅图1，图1为实现本技术各个实施例的一种应用环境架构图。本技术可应用于包括，但不仅限于中心服务器2和多个云服务器4的应用环境中。
43.现有直播体系在主播推流时主要根据域名系统解析获取离主播最佳的节点进行推流。但是，这种技术架构的缺点如下：
44.(1)缺乏数据支撑，部署节点盲目：主播分布在全国各地，由于人口流动性和人口集中性，一般部署逻辑为每个省份或者相邻省份部署一到两个节点。这样虽然可以保证全国各地均有节点，但是完全是经验主义，不具有科学性和严谨性。
45.(2)机器资源配置一致，资源浪费严重，扩大成本：在部署的节点中，由于缺乏数据支持，每个节点申请的资源均为一样的。但是由于人员的分布不同，各个省份的资源使用率也有很大差别。例如在东部的一些省份使用率为90％，而在西部地区则只有10％
‑
20％。成本计算是按照申请资源计算，故大多数节点的资源使用率较低，会导致资源浪费，浪费成本。
46.(3)物理机器部署扩展难：传统方案使用物理机器部署推流节点，物理机器的部署需要经过发起采购、采购完成、运维配置机器基本信息、研发同步部署程序等流程。整体流程流程较长，人工参与程度大，扩展的难度较大。
47.基于上述问题，本技术各个实施例在直播体系中部署中心服务器2和多个云服务器4，主播向云服务器4上进行推流。所述云服务器4为部署在全国各地的小型推流节点(边缘节点)，是一种可弹性伸缩的计算、网络、存储服务器，成本低，使用docker容器部署，其管理方式比物理服务器更加高效便捷，可以在使用过程中进行硬盘、内存、带宽、中央处理器(central processing unit，cpu)的随时升级。中心服务器2实时采集所有所述云服务器4
的状态因素，根据所采集到的实时数据进行细化处理，按照预设的逻辑进行综合判断，从而动态部署和配置直播边缘节点(云服务器4)。
48.所述中心服务器2和多个所述云服务器42之间通过有线或无线网络通信连接，以进行数据传输和交互。
49.实施例一
50.如图2所示，为本技术第一实施例提出的一种直播边缘节点资源管控方法的流程图。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。下面以中心服务器2作为执行主体对该方法进行说明。
51.该方法包括以下步骤：
52.s200，实时采集所有边缘节点的状态信息。
53.本技术实施例抛弃传统的物理服务器部署方式，使用云机器部署。第三方的内容分发网络(content delivery network，cdn)云服务器是可以动态申请和删除的，可以按需申请和使用。因此对接第三方cdn云服务资源，对接cdn接口，将每个云服务器作为该直播体系中的边缘节点，支持动态新增和删除、缩小和扩大配置的云服务器的操作。
54.所述状态信息用以判断云服务器(边缘节点)资源是否满足当前主播推流需求。在本实施例中，所述状态信息主要包括每个所述边缘节点的资源使用信息、推流数目、每个流的实时卡顿率等。所述资源使用信息包括但不限于实际使用带宽、实际使用cpu核数、实际使用内存。后续判断时需要考虑以下因素：
55.(1)带宽使用率
56.带宽分为进带宽和出带宽，是一个节点传输数据的最大考量因素。带宽使用率＝实际使用带宽/申请的带宽。如果申请的带宽数小于使用的带宽数，则机器上接收的流信息无法传输出去，会出现数据丢包的情况，进而影响流的质量，导致用户观看卡顿。如果申请的带宽数远大于使用的带宽数，虽然不会影响用户，但是会浪费资源，从而提升成本。
57.(2)cpu使用率
58.cpu是计算机系统的运算和控制核心，cpu的大小影响了机器的处理速度和承载力。cpu越大，机器的处理速度越快，能够同时处理的任务越多，但是价格也越贵。
59.cpu使用率＝实际使用cpu核数/申请的cpu核数。理想情况下，cpu的申请核数应该和该机器上接收推流的数目是相匹配的。接收的推流数目越多则应该申请的cpu核数越大，否则应该申请的cpu核数越小。
60.(3)内存使用率
61.内存用于存放cpu中的运算数据，计算机系统中所有程序的运行都在内存中进行，内存性能的强弱影响计算机系统整体发挥的水平。内存越大，机器的处理速度越快，能够同时处理的任务越多，但是价格也越贵。
62.内存使用率＝实际使用内存/申请的内存(单位gb)。理论情况下，内存申请的容量应该和该机器上接收推流的数目是相匹配的。接收的推流数目越多则应该申请的内存越大，否则应该缩小。
63.(4)推流数目
64.在满足cpu和内存的情况下，并非一个机器上能接收的流的数目越多越好，而是应
该保持一个合适的值。因为接收的推流数目越多，该机器发生故障的时候影响的推流数目也越多，即影响的主播数目越多。因此，为了降低机器发生故障时的影响面积，应该让一个机器上能够接收的推流数目保持在一个合理范围内。若接收的推流数目较少，整个机器的使用率便不高；若接收的推流数目越大，影响面积也越大。
65.(5)流卡顿率
66.带宽、cpu和内存均是物理层面的信息，是从实际数据分析得出的理论值，在超过一定使用率的时候，确实会发生卡顿，但这仅仅是从硬件层面上的判断。有时候使用率较高，并不实际影响用户推流，则也可以认为该机器是正常的，故需要从应用层面上合理判断一个机器的状态。
67.因此，本实施例还引入了流卡顿率。整体流卡顿率＝卡顿的流数目/总流数目。其中，单个流的卡顿是指：当一个流的每秒传输帧数(frames per second，fps)在短时间内发生变化并超过一定的幅度，则说明该流发生流抖动，会导致用户观看卡顿。
68.使用fps作为卡顿的判断因素的原因是：fps是每秒传输的帧数，在直播中，主播通过恒定的fps传输速率向云服务器发送数据。若云服务器发送数据一切正常，则收到的fps数值始终是恒定的。若云服务器发生数据异常或者负载过高，则云服务器发送数据时无法处理更多的帧数，只能接收用户传输的部分帧数，其他帧数会存储在用户端。等待机器负载恢复正常后，云服务器发送数据会在瞬间接收之前未接收的传输帧数，这样就导致前后传输的帧率变动幅度较大。
69.卡顿计算公式如下：以一段时间t为周期，计算该周期内接收到的该流的所有fps值，并且计算平均fps＝总fps值/时间t。判断一个时间点是否发生卡顿的条件为：绝对值(该时间点的fps
‑
平均fps)/平均fps>30％(一个预定的阈值，也可以根据实际情况设置为其他阈值)，当满足该条件时，表示该流该时间点发生流卡顿。
70.在本步骤中，所述中心服务器实时采集所有作为边缘节点的云服务器的实际使用带宽、实际使用cpu核数、实际使用内存、推流数目、每个流的实时卡顿率等状态信息，为后续判断和部署做准备。
71.s202，根据采集到的所述状态信息和预设逻辑综合判断所述边缘节点是否需要调整。
72.具体而言，进一步参阅图3，为上述步骤s202的细化流程示意图。可以理解，该流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。在本实施例中，所述步骤s202具体包括：
73.s2020，计算所述边缘节点(例如云服务器a)上的实时总推流数目和所有流的实时卡顿率。
74.s2022，当所述实时总推流数目大于第一阈值或所述实时卡顿率大于第二阈值时，判断需要增加边缘节点。
75.若所述实时总推流数目大于第一阈值(预设的理想推流数目)或所述实时卡顿率大于第二阈值(根据实际情况预先设定)，即两个条件满足其中一个时，说明已经从应用层面上影响流用户使用，在本实施例中不再考虑云服务器的硬件信息，直接判断所述边缘节点(云服务器a)所在区域需要增加一个边缘节点(云服务器c)，用于分担流数量。
76.s2024，当所述实时总推流数目小于等于所述第一阈值且所述实时卡顿率小于等
于所述第二阈值时，根据所述边缘节点的资源使用率判断是否需要删除所述边缘节点或调整所述边缘节点中配置的资源。
77.当步骤s2022中的两个条件均不满足，也就是所述实时总推流数目小于等于所述第一阈值且所述实时卡顿率小于等于所述第二阈值时，进一步计算所述边缘节点(云服务器a)的各种资源使用率(带宽使用率、cpu使用率和内存使用率)，再根据这些资源使用率判断是否需要删除所述边缘节点、增加或减少所述边缘节点中配置的资源。具体包括：
78.(1)计算所述边缘节点的资源使用率，包括但不限于带宽使用率、cpu使用率和内存使用率。
79.根据步骤s200中采集的实际使用带宽、实际使用cpu核数、实际使用内存以及各种使用率的计算方式，可以分别计算得到所述边缘节点的带宽使用率、cpu使用率和内存使用率。
80.(2)分别设置所述资源使用率的三个阈值q、w、e，且q>w>e。
81.在本实施例中，将各个资源使用率按照等级划分，q为使用率较高，w为使用率正常，e为使用率较低(也就是设置三个使用率阈值q、w、e，且q>w>e)。值得注意的是，针对每一种资源使用率，均可以设置不同的等级划分标准，也就是对每一种资源使用率设置不同的q、w、e阈值。
82.(3)当计算出的某个资源使用率大于阈值q时，判断需要增加所述边缘节点中的该资源；当计算出的某个资源使用率小于等于阈值q且大于阈值w时，判断所述边缘节点不需要进行调整；当计算出的某个资源使用率小于等于阈值w且大于等于阈值e时，判断需要减小所述边缘节点中的该资源；当计算出的各个资源使用率均小于阈值e时，判断需要删除所述边缘节点。
83.值得注意的是，在本实施例中，若带宽使用率、cpu使用率和内存使用率中的一个或两个小于阈值e，也是判断需要减小所述边缘节点中的该资源。若三者的使用率均小于e则说明所述边缘节点中各种资源的使用率极低，中心服务需要在所述边缘节点(云服务器a)上流数较少的情况下，删除所述边缘节点，将所述边缘节点上的流调往其他节点。
84.回到图2，s204，当需要时对所述边缘节点进行调整。
85.根据步骤s202中的判断结果，中心服务器针对每个所述边缘节点(云服务器)进行对应的调整，包括新增边缘节点、删除边缘节点、增加或减少所述边缘节点中配置的资源，当然还有一种情况是不进行调整。
86.参阅图4所示，为所述直播边缘节点资源管控方法另一种形式的流程示意图。图4中各个步骤的具体内容已在上述图2和图3相关描述中详细说明，在此不再赘述。
87.本实施例提出的直播边缘节点资源管控方法，抛弃传统的物理服务器部署方式，使用云服务器进行边缘节点部署，可以根据各个边缘节点的实时状态信息来综合判断分析每个边缘节点的使用情况，从而按照预设逻辑动态新增或删除边缘节点、增加或减少所述边缘节点中配置的资源，实现资源的最大利用效率，节省资源和人力。
88.实施例二
89.如图5所示，为本技术第二实施例提出一种电子装置20的硬件架构示意图。本实施例中，所述电子装置20可包括，但不仅限于，可通过系统总线相互通信连接的存储器21、处理器22、网络接口23。需要指出的是，图5仅示出了具有组件21
‑
23的电子装置20，但是应理
解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。在本实施例中，所述电子装置20可以是所述中心服务器2。
90.所述存储器21至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，sd或dx存储器等)、随机访问存储器(ram)、静态随机访问存储器(sram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、可编程只读存储器(prom)、磁性存储器、磁盘、光盘等。在一些实施例中，所述存储器21可以是所述电子装置20的内部存储单元，例如该电子装置20的硬盘或内存。在另一些实施例中，所述存储器21也可以是所述电子装置20的外部存储设备，例如该电子装置20上配备的插接式硬盘，智能存储卡(smart media card,smc)，安全数字(secure digital,sd)卡，闪存卡(flash card)等。当然，所述存储器21还可以既包括所述电子装置20的内部存储单元也包括其外部存储设备。本实施例中，所述存储器21通常用于存储安装于所述电子装置20的操作系统和各类应用软件，例如直播边缘节点资源管控系统60的程序代码等。此外，所述存储器21还可以用于暂时地存储已经输出或者将要输出的各类数据。
91.所述处理器22在一些实施例中可以是cpu、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器22通常用于控制所述电子装置20的总体操作。本实施例中，所述处理器22用于运行所述存储器21中存储的程序代码或者处理数据，例如运行所述直播边缘节点资源管控系统60等。
92.所述网络接口23可包括无线网络接口或有线网络接口，该网络接口23通常用于在所述电子装置20与其他电子设备之间建立通信连接。
93.实施例三
94.如图6所示，为本技术第三实施例提出一种直播边缘节点资源管控系统60的模块示意图。所述直播边缘节点资源管控系统60可以被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本技术实施例。本技术实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，以下描述将具体介绍本实施例各程序模块的功能。
95.在本实施例中，所述直播边缘节点资源管控系统60包括：
96.采集模块600，用于实时采集所有边缘节点的状态信息。
97.本技术实施例抛弃传统的物理服务器部署方式，使用云机器部署。第三方的cdn云服务器是可以动态申请和删除的，可以按需申请和使用。因此对接第三方cdn云服务资源，对接cdn接口，将每个云服务器作为该直播体系中的边缘节点，支持动态新增和删除、缩小和扩大配置的云服务器的操作。
98.所述状态信息用以判断云服务器(边缘节点)资源是否满足当前主播推流需求。在本实施例中，所述状态信息主要包括每个所述边缘节点的资源使用信息、推流数目、每个流的实时卡顿率等。所述资源使用信息包括但不限于实际使用带宽、实际使用cpu核数、实际使用内存。后续判断时需要考虑以下因素：
99.(1)带宽使用率
100.带宽分为进带宽和出带宽，是一个节点传输数据的最大考量因素。带宽使用率＝实际使用带宽/申请的带宽。如果申请的带宽数小于使用的带宽数，则机器上接收的流信息无法传输出去，会出现数据丢包的情况，进而影响流的质量，导致用户观看卡顿。如果申请
的带宽数远大于使用的带宽数，虽然不会影响用户，但是会浪费资源，从而提升成本。
101.(2)cpu使用率
102.cpu是计算机系统的运算和控制核心，cpu的大小影响了机器的处理速度和承载力。cpu越大，机器的处理速度越快，能够同时处理的任务越多，但是价格也越贵。
103.cpu使用率＝实际使用cpu核数/申请的cpu核数。理想情况下，cpu的申请核数应该和该机器上接收推流的数目是相匹配的。接收的推流数目越多则应该申请的cpu核数越大，否则应该申请的cpu核数越小。
104.(3)内存使用率
105.内存用于存放cpu中的运算数据，计算机系统中所有程序的运行都在内存中进行，内存性能的强弱影响计算机系统整体发挥的水平。内存越大，机器的处理速度越快，能够同时处理的任务越多，但是价格也越贵。
106.内存使用率＝实际使用内存/申请的内存(单位gb)。理论情况下，内存申请的容量应该和该机器上接收推流的数目是相匹配的。接收的推流数目越多则应该申请的内存越大，否则应该缩小。
107.(4)推流数目
108.在满足cpu和内存的情况下，并非一个机器上能接收的流的数目越多越好，而是应该保持一个合适的值。因为接收的推流数目越多，该机器发生故障的时候影响的推流数目也越多，即影响的主播数目越多。因此，为了降低机器发生故障时的影响面积，应该让一个机器上能够接收的推流数目保持在一个合理范围内。若接收的推流数目较少，整个机器的使用率便不高；若接收的推流数目越大，影响面积也越大。
109.(5)流卡顿率
110.带宽、cpu和内存均是物理层面的信息，是从实际数据分析得出的理论值，在超过一定使用率的时候，确实会发生卡顿，但这仅仅是从硬件层面上的判断。有时候使用率较高，并不实际影响用户推流，则也可以认为该机器是正常的，故需要从应用层面上合理判断一个机器的状态。
111.因此，本实施例还引入了流卡顿率。整体流卡顿率＝卡顿的流数目/总流数目。其中，单个流的卡顿是指：当一个流的fps在短时间内发生变化并超过一定的幅度，则说明该流发生流抖动，会导致用户观看卡顿。
112.使用fps作为卡顿的判断因素的原因是：fps是每秒传输的帧数，在直播中，主播通过恒定的fps传输速率向云服务器发送数据。若云服务器发送数据一切正常，则收到的fps数值始终是恒定的。若云服务器发生数据异常或者负载过高，则云服务器发送数据时无法处理更多的帧数，只能接收用户传输的部分帧数，其他帧数会存储在用户端。等待机器负载恢复正常后，云服务器发送数据会在瞬间接收之前未接收的传输帧数，这样就导致前后传输的帧率变动幅度较大。
113.卡顿计算公式如下：以一段时间t为周期，计算该周期内接收到的该流的所有fps值，并且计算平均fps＝总fps值/时间t。判断一个时间点是否发生卡顿的条件为：绝对值(该时间点的fps
‑
平均fps)/平均fps>30％(一个预定的阈值，也可以根据实际情况设置为其他阈值)，当满足该条件时，表示该流该时间点发生流卡顿。
114.所述采集模块600实时采集所有作为边缘节点的云服务器的实际使用带宽、实际
使用cpu核数、实际使用内存、推流数目、每个流的实时卡顿率等状态信息，为后续判断和部署做准备。
115.判断模块602，用于根据采集到的所述状态信息和预设逻辑综合判断所述边缘节点是否需要调整。具体包括：
116.(一)计算所述边缘节点(例如云服务器a)上的实时总推流数目和所有流的实时卡顿率。
117.(二)当所述实时总推流数目大于第一阈值或所述实时卡顿率大于第二阈值时，判断需要增加边缘节点。
118.若所述实时总推流数目大于第一阈值(预设的理想推流数目)或所述实时卡顿率大于第二阈值(根据实际情况预先设定)，即两个条件满足其中一个时，说明已经从应用层面上影响流用户使用，在本实施例中不再考虑云服务器的硬件信息，直接判断所述边缘节点(云服务器a)所在区域需要增加一个边缘节点(云服务器c)，用于分担流数量。
119.(三)当所述实时总推流数目小于等于所述第一阈值且所述实时卡顿率小于等于所述第二阈值时，根据所述边缘节点的资源使用率判断是否需要删除所述边缘节点或调整所述边缘节点中配置的资源。
120.当(二)中的两个条件均不满足，也就是所述实时总推流数目小于等于所述第一阈值且所述实时卡顿率小于等于所述第二阈值时，进一步计算所述边缘节点(云服务器a)的各种资源使用率(带宽使用率、cpu使用率和内存使用率)，再根据这些资源使用率判断是否需要删除所述边缘节点、增加或减少所述边缘节点中配置的资源。具体包括：
121.(1)计算所述边缘节点的资源使用率，包括但不限于带宽使用率、cpu使用率和内存使用率。
122.根据(一)中采集的实际使用带宽、实际使用cpu核数、实际使用内存以及各种使用率的计算方式，可以分别计算得到所述边缘节点的带宽使用率、cpu使用率和内存使用率。
123.(2)分别设置所述资源使用率的三个阈值q、w、e，且q>w>e。
124.在本实施例中，将各个资源使用率按照等级划分，q为使用率较高，w为使用率正常，e为使用率较低(也就是设置三个使用率阈值q、w、e，且q>w>e)。值得注意的是，针对每一种资源使用率，均可以设置不同的等级划分标准，也就是对每一种资源使用率设置不同的q、w、e阈值。
125.(3)当计算出的某个资源使用率大于阈值q时，判断需要增加所述边缘节点中的该资源；当计算出的某个资源使用率小于等于阈值q且大于阈值w时，判断所述边缘节点不需要进行调整；当计算出的某个资源使用率小于等于阈值w且大于等于阈值e时，判断需要减小所述边缘节点中的该资源；当计算出的各个资源使用率均小于阈值e时，判断需要删除所述边缘节点。
126.值得注意的是，在本实施例中，若带宽使用率、cpu使用率和内存使用率中的一个或两个小于阈值e，也是判断需要减小所述边缘节点中的该资源。若三者的使用率均小于e则说明所述边缘节点中各种资源的使用率极低，中心服务需要在所述边缘节点(云服务器a)上流数较少的情况下，删除所述边缘节点，将所述边缘节点上的流调往其他节点。
127.调整模块604，用于当需要时对所述边缘节点进行调整。
128.根据判断模块602的判断结果，调整模块604针对每个所述边缘节点(云服务器)进
行对应的调整，包括新增边缘节点、删除边缘节点、增加或减少所述边缘节点中配置的资源，当然还有一种情况是不进行调整。
129.本实施例提出的直播边缘节点资源管控系统，抛弃传统的物理服务器部署方式，使用云服务器进行边缘节点部署，可以根据各个边缘节点的实时状态信息来综合判断分析每个边缘节点的使用情况，从而按照预设逻辑动态新增或删除边缘节点、增加或减少所述边缘节点中配置的资源，实现资源的最大利用效率，节省资源和人力。
130.实施例四
131.本技术还提供了另一种实施方式，即提供一种计算机可读存储介质，所述计算机可读存储介质存储有直播边缘节点资源管控程序，所述直播边缘节点资源管控程序可被至少一个处理器执行，以使所述至少一个处理器执行如上述的直播边缘节点资源管控方法的步骤。
132.需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
133.上述本技术实施例序号仅仅为了描述，不代表实施例的优劣。
134.显然，本领域的技术人员应该明白，上述的本技术实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本技术实施例不限制于任何特定的硬件和软件结合。
135.以上仅为本技术实施例的优选实施例，并非因此限制本技术实施例的专利范围，凡是利用本技术实施例说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本技术实施例的专利保护范围内。