业务调度方法、装置、设备及存储介质与流程

1.本公开实施例涉及cdn技术领域，尤其涉及一种业务调度方法、装置、设备及存储介质。


背景技术：

2.在内容分发网络(content delivery network，简称cdn)中，中心调度设备可以调度距离用户距离较近的边缘节点为用户提供服务。但是不同的调度方式对cdn业务的质量和成本有不同的影响，因此，如何在调度过程中兼顾cdn业务的质量和/或成本是本领域技术人员需要解决的技术问题。


技术实现要素：

3.为了解决上述技术问题或者至少部分地解决上述技术问题，本公开实施例提供了一种业务调度方法、装置、设备及存储介质。
4.本公开实施例的第一方面提供了一种业务调度方法，该方法适用于一种内容分发网络(content delivery network，简称cdn)，所述cdn中包括用于定期确定所述cdn中各边缘节点的业务质量和成本带宽值的中心服务平台，所述成本带宽值是指所述边缘节点成本最优时的带宽值，该方法包括所述cdn中的第一边缘节点接收客户端的业务请求，所述业务请求中包括业务类型和所述客户端的ip地址；至少根据自身当前的带宽值和成本带宽值，判断是否需要对业务请求进行重新调度；若是，则基于所述ip地址和所述业务类型向所述中心服务平台请求与所述客户端同属一个区域，且与所述业务类型相匹配的至少一个第二边缘节点的带宽余量和业务质量，其中，所述带宽余量是指所述第二边缘节点的成本带宽值与所述第二边缘节点当前的带宽值之间的差值；根据所述至少一个第二边缘节点的带宽余量和业务质量，将业务请求重新调度到一个或多个第二边缘节点上。
5.本公开实施例的第二方面提供了一种业务调度装置，所述业务调度装置设置在cdn的第一边缘节点中，所述cdn中包括用于定期确定所述cdn中各边缘节点的业务质量和成本带宽值的中心服务平台，所述业务调度装置包括：
6.接收模块，用于接收客户端的业务请求，所述业务请求中包括业务类型和所述客户端的ip地址；
7.判断模块，用于至少根据所述第一边缘节点当前的带宽值和所述第一边缘节点当前的成本带宽值，判断是否需要对所述业务请求进行重新调度；
8.请求模块，用于在判断需要对所述业务请求进行重新调度时，基于所述ip地址和所述业务类型向所述中心服务平台请求与所述客户端同属一个区域，且与所述业务类型相匹配的至少一个第二边缘节点的带宽余量和业务质量，其中，所述带宽余量是指所述第二边缘节点的成本带宽值与所述第二边缘节点当前的带宽值之间的差值；
9.执行模块，根据所述至少一个第二边缘节点的带宽余量和业务质量，将所述业务请求重新调度到一个或多个第二边缘节点上。
10.本公开实施例的第三方面提供了一种边缘节点，包括存储器和处理器，其中，所述存储器中包括计算机程序，当所述计算机程序被所述处理器执行时，所述处理器可以执行上述第一方面所述的方法。
11.本公开实施例的第四方面提供了一种计算机可读存储介质，该存储介质中存储有计算机程序，当所述计算机程序被处理器执行时，使得所述处理器执行上述第一方面所述的方法。
12.本公开实施例提供的技术方案与现有技术相比具有如下优点：
13.本公开实施例通过中心服务平台定期确定cdn中各边缘节点的业务质量和成本带宽值。当cdn中的第一边缘节点接收到客户端的业务请求时，使得第一边缘节点至少根据自身当前的带宽值和成本带宽值判断是否需要对业务请求进行重新调度，并在判断需要重新调度时，基于业务请求中携带的ip地址和业务类型向中心服务平台请求至少一个与客户端同属一个区域，且与客户端请求的业务类型相匹配的第二边缘节点的带宽余量和业务质量，然后再根据请求到的至少一个第二边缘节点的带宽余量和业务质量，将业务请求重新调度到其中的一个或多个第二边缘节点上。与相关技术提供的中央302调度方式和域名系统(domain name system，简称dns)调度方式不同的是，本公开实施例中的第一边缘节点在接收到客户端的业务请求之后，并不是默认由自身来处理该业务请求，而是会根据自身当前的实际带宽和自身的成本带宽来判断是否需要进行重新调度，当判断需要重新调度时，再向中心服务平台请求至少一个第二边缘节点的带宽余量和业务质量，并根据请求到的至少一个第二边缘节点的宽余量和业务质量将业务请求重新调度到其他边缘节点上。这种调度方式不但满足了cdn的业务调度要求，还兼顾了cdn中各边缘节点的成本和业务质量，从而实现了cdn成本的精细化控制，保证了cdn的服务质量。
附图说明
14.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
15.为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
16.图1是本公开实施例提供的一种业务调度方法的流程图；
17.图2是本公开实施例提供的一种cdn的网络架构图；
18.图3是本公开实施例提供的另一种业务调度方法的流程图；
19.图4是本公开实施例提供的又一种业务调度方法的流程图；
20.图5是本公开实施例提供的一种业务调度装置的结构示意图；
21.图6是本公开实施例提供的一种边缘节点的结构示意图。
具体实施方式
22.为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。
23.在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。
24.为了方便理解，下面首先对本公开实施例中涉及到的部分专业术语进行解释：
25.边缘节点：边缘节点指在靠近用户的网络边缘侧构建的业务平台，用于向用户提供存储、计算、网络等资源。
26.成本带宽值，边缘节点的成本带宽值是指边缘节点取得最优成本时的带宽值。成本带宽值与边缘节点的计费方式相关，在计费方式确定时边缘节点的成本带宽值可以基于计费方式计算得到，成本带宽值的计算方法可以参见相关技术，这里不再赘述。
27.带宽余量，边缘节点的带宽余量是指边缘节点的成本带宽值与边缘节点的实际带宽值之间的差值。
28.在相关技术中，cdn的业务调度方式主要包括如下两种，
29.一、dns调度方式
30.在dns调度方式中，客户端的业务请求首先会发送给本地dns系统。本地dns系统根据该业务请求向cdn的中心调度设备请求用于处理该业务请求的边缘节点的地址，并将该边缘节点的地址反馈给客户端。客户端接收到该边缘节点的地址后，向该边缘节点发起业务请求，以使该边缘节点为客户端提供业务服务。
31.但是在dns调度方式中，经常会出现域名劫持、调度不准确或不及时等问题，这些问题对cdn的业务质量和成本带来了一定的不可控性。
32.二、中央302调度方式
33.在中央302调度方式中，客户端的业务请求首先会发送给本地dns系统，本地dns系统根据该业务请求向cdn业务运营商专用的dns系统请求中心调度设备的地址，然后将中心调度设备的地址反馈给客户端。客户端接收到中心调度设备的地址后，根据该地址向中心调度设备发送业务请求。中心调度设备接收到客户端的业务请之后，根据客户端的ip地址分配一个与客户端在同一区域的边缘节点来处理客户端的业务请求，并将该边缘节点的地址反馈给客户端，客户端向该边缘节点重新发起业务请求。
34.在中央302调度方式中，业务调度缺乏对边缘节点的成本和业务质量的感知，存在无法精细化控制成本、不能保障服务质量的问题。并且中心调度设备在将客户端的业务调度到某个边缘节点上后，该边缘节点一般会默认由自身来为客户端来提供服务，而不会再次进行302调度，因而存在调度路径单一的问题。
35.针对相关技术存在的上述问题，本公开实施例提供了一种可用于cdn的业务调度方案。该方案创新性的在cdn中设置了一种中心服务平台，该中心服务平台可以定期确定得到cdn中各边缘节点的业务质量和成本带宽值，并在cdn中的边缘节点需要重新调度业务请求(302调度)时，为边缘节点提供其他边缘节点的业务质量数据和带宽余量数据，使得边缘节点可以根据其他边缘节点的业务质量和带宽余量，将业务请求重新调度到其他的一个或多个边缘节点上。
36.示例的，图1是本公开实施例提供的一种业务调度方法的流程图，如图1所示，该方法可以包括如下步骤：
37.步骤101、cdn中的第一边缘节点接收客户端的业务请求，该业务请求中包括业务
类型和客户端的ip地址。
38.步骤102、第一边缘节点至少根据自身当前的带宽值和成本带宽值，判断是否需要对业务请求进行重新调度，其中若是则执行步骤103。
39.步骤103、第一边缘节点基于业务请求中的ip地址和业务类型向中心服务平台请求与客户端同属一个区域，且与客户端请求的业务类型相匹配的至少一个第二边缘节点的带宽余量和业务质量。
40.步骤104、第一边缘节点根据请求获得的至少一个第二边缘节点的带宽余量和业务质量，将客户端的业务请求重新调度到一个或多个第二边缘节点上。
41.本实施例中对于“第一边缘节点”和“第二边缘节点”的命名仅是为了便于区分而不具有其他含义。
42.示例的，图2是本公开实施例提供的一种cdn的网络架构图，如图2所示，在图2的cdn网络架构中至少包括客户端、本地dns、cdn专用的dns、中心调度设备、中心服务平台和n个边缘节点，n为大于1的整数。其中，n个边缘节点的计费方式可以相同也可以不同，并且各边缘节点的计费方式并非固定不变，而是可以根据需要进行调整，比如在不同的时段采用不同的计费方式等。
43.在本公开实施例中，中心服务平台按照预设的周期确定各边缘节点成本带宽值和业务质量等数据，并将边缘节点的成本带宽值和业务质量反馈给边缘节点。其中，中心服务器确定各边缘节点成本带宽值和业务质量的方法可以有多种：
44.比如，在一种实施方式中，边缘节点可以被配置为定期将自身的计费方式、实时带宽值，以及多个维度的质量参数(比如，边缘节点在预设时间端内收集到的4xx、5xx、卡顿率等参数)上报给中心服务平台，中心服务平台在收到这些数据后，基于这些数据分别计算得到边缘节点的成本带宽值和业务质量。其中，边缘节点的成本带宽值，可以基于边缘节点的计费方式，采用与该计费方式相对应的第一预设算法计算得到。边缘节点的业务质量可以基于边缘节点上报的质量参数，采用第二预设算法计算得到，其中，第一预设算法和第二预设算法可以根据需要进行设定，而不必局限于某一种特定的算法。例如，当第二预设算法被具体为加权求和算法时，中心服务平台可以先根据各维度质量参数对应的权值，对各维度的质量参数进行加权处理，然后再对加权后的质量参数进行求和处理，并将求和处理的结果作为边缘节点的业务质量。
45.再比如，在本公开实施例的另一种实施方式中，中心服务器也可以通过定期向边缘节点发送测试数据的方式，测量得到诸如4xx、5xx、卡顿率等参数，然后再基于这些参数计算得到边缘节点的业务质量。与此类似的，边缘节点的计费方式和实时的带宽值也可以通过定期发送请求消息的方式，从边缘节点上获取得到，然后再基于得到的计费方式计算得到边缘节点的成本带宽值，基于得到的实时带宽值和成本带宽值计算得到边缘节点的带宽余量。
46.需要说明的是本公开实施例为了减少边缘节点的计算压力，示例性的将成本带宽值和业务质量的计算能力集成在了中心服务平台上，而在其他实施方式中如果不考虑边缘节点的计算压力，也可以将该计算能力集成在边缘节点上，即由边缘节点定期计算自身的成本带宽值和业务质量，并将计算得到的成本带宽值和业务质量上报到中心服务平台进行存储，其中边缘节点计算成本带宽值和业务质量的方法与上述方法类似，在这里不在赘述。
47.参见图2，基于上述中心服务平台定期得到的带宽余量数据和成本带宽值数据，本实施例的业务调度方法可以描述如下：
48.客户端先向本地dns发送业务请求，业务请求中包括客户端的ip地址和请求的业务类型。本地dns从cdn专用的dns中获取中心调度设备的地址，并将该地址反馈给客户端，客户端基于该地址向中心调度设备发送业务请求，中心调度设备根据客户端的ip地址和请求的业务类型将支持该业务类型，且距离客户端距离最近的边缘节点1(即第一边缘节点)的地址反馈给客户端，客户端根据边缘节点1的地址向边缘节点1发送业务请求。
49.边缘节点1在接收到客户端的业务请求之后，至少根据自身当前的带宽值和成本带宽值，判断是否需要对该业务请求进行重新调度。其中，根据当前的带宽值和成本带宽值判断是否需要重新调度的方法有多种，比如在一种可行判断方法中，边缘节点1可以将自身当前的带宽值和自身当前的成本带宽值进行比较，如果自身当前的带宽值大于或等于自身当前的成本带宽值，即自身当前的带宽值已经超出了最优成本的带宽值了，则判断需要对客户端的业务请求进行重新调度。再比如，在另一种可行判断方法中，还可以先对自身当前的成本带宽值和自身当前的实际带宽值进行求差处理，得到带宽余量，然后将计算得到的带宽余量与预设的第一带宽阈值进行比较，如果计算得到的带宽余量小于第一带宽阈值，则判断需要对客户端的业务请求进行重新调度，否则判断不需要重新调度。这种判断方式通过对第一带宽阈值进行设置，可以保证边缘节点不会因为处理该客户端的业务请求而导致带宽超出成本带宽值，从而实现了对成本的精细控制。需要说明的是上述两种判断方法仅是示例性说明，而不是唯一限定，实际上基于带宽值和成本带宽值判断是否需要重新调度的方法可以根据需要进行设定。
50.进一步的，如果需要对客户端的业务请求进行重新调度，边缘节点1会将客户端的ip地址和客户端请求的业务类型携带在请求消息中，向中心服务平台请求cdn中其他边缘节点的带宽余量和业务质量。其中，中心服务平台在接收到边缘节点1的请求后，至少可以基于如下中的一种处理方式进行处理：
51.第一种处理方式，根据客户端的ip地址和请求的业务类型从cdn中筛选出与客户端在同一区域，且与客户端请求的业务类型相匹配的边缘节点。然后再将这些边缘节点中的至少一个边缘节点(即至少一个第二边缘节点)的带宽余量和业务质量反馈给边缘节点1。其中，与客户端请求的业务类型相匹配的边缘节点，比如可以理解为能够支持该业务类型的边缘节点。
52.第二种处理方式，中心服务平台在从所有的边缘节点中筛选出与客户端在同一区域，且与客户端请求的业务类型相匹配的边缘节点后，将这些边缘节点中，带宽余量和业务质量大于预设值的至少一个边缘节点(即至少一个第二边缘节点)的带宽余量和业务质量反馈给边缘节点1。而若是cdn中不存在带宽余量和业务质量大于预设值的边缘节点，则按照第一种处理方式进行处理。
53.进一步的，在从中心服务平台中请求到至少一个第二边缘节点的带宽余量和业务质量之后，边缘节点1至少可以采用如下中的一种方法来对客户端的业务请求进行重新调度：
54.在一种调度方法中，边缘节点1在请求到至少一个第二边缘节点的带宽余量和业务质量后，先从这些第二边缘节点中确定出带宽余量大于或等于第二带宽阈值，业务质量
大于或等于客户端请求的业务类型所对应的质量阈值的边缘节点，然后再从中心调度设备上请求这些边缘节点的地址，并将这些边缘节点的地址反馈给客户端，使得客户端向这些边缘节点发送业务请求。而若是请求到的第二边缘节点中不存在带宽余量大于或等于第二带宽阈值，且业务质量大于或等于客户端请求的业务类型所对应的质量阈值的边缘节点时，则通过对每个第二边缘节点的业务质量和带宽余量进行加权求和处理，得到每个第二边缘节点对应的加权求和结果，然后再向中心调度设备请求加权求和结果大于第一预设阈值的第二边缘节点的地址，并将请求到的地址发送给客户端，使得客户端根据这些地址重新发起业务请求。
55.在另一种调度方法中，边缘节点1在请求到至少一个第二边缘节点的带宽余量和业务质量后，还可以先从请求到的至少一个第二边缘节点中确定出带宽余量大于或等于第二带宽阈值，业务质量大于或等于客户端请求的业务类型对应的质量阈值的第二边缘节点，作为候选边缘节点；然后再对每个候选边缘节点的业务质量和带宽余量进行加权求和处理，并将加权求和结果大于第二预设阈值的候选边缘节点作为目标边缘节点，通过向中心调度设备请求目标边缘节点的地址，并将目标边缘节点的地址反馈给客户端，使得客户端的业务请求被重新调度到目标边缘节点上。
56.需要说明的是，上述虽然仅提供了两种调度方法，但是本实施例的调度方法并于局限于上述两种，而是可以根据需要进行设定。实际上凡是能够基于边缘节点的带宽余量和/或业务质量实现的业务重新调度方法均可被应用在本公开实施例的方案中。
57.本公开实施例通过中心服务平台定期确定cdn中各边缘节点的业务质量和成本带宽值。当cdn中的第一边缘节点接收到客户端的业务请求时，使得第一边缘节点至少根据自身当前的带宽值和成本带宽值判断是否需要对业务请求进行重新调度，并在判断需要重新调度时，基于业务请求中携带的ip地址和业务类型向中心服务平台请求至少一个与客户端同属一个区域，且与客户端请求的业务类型相匹配的第二边缘节点的带宽余量和业务质量，然后再根据请求到的至少一个第二边缘节点带宽余量和业务质量，将业务请求重新调度到其中的一个或多个第二边缘节点上。与相关技术提供的中央302调度方式和域名系统(domain name system，简称dns)调度方式不同的是，本公开实施例中的第一边缘节点在接收到客户端的业务请求之后，并不是默认由自身来处理该业务请求，而是会根据自身当前的实际带宽和自身的成本带宽来判断是否需要进行重新调度，当判断需要重新调度时，再向中心服务平台请求至少一个第二边缘节点的带宽余量和业务质量，并根据请求到的至少一个第二边缘节点的宽余量和业务质量将业务请求重新调度到其他边缘节点上。这种调度方式不但满足了cdn的业务调度要求，还兼顾了cdn中各边缘节点的成本和业务质量，从而实现了cdn成本的精细化控制，保证了cdn的服务质量。
58.示例的，图3是本公开实施例提供的另一种业务调度方法的流程图，如图3所示，该方法包括：
59.步骤301、cdn中的第一边缘节点接收客户端的业务请求，业务请求中包括业务类型和客户端的ip地址：
60.步骤302、第一边缘节点基于自身当前的带宽值和预先得到的自身的带宽变化趋势，确定预设时间后的带宽值。
61.在本实施例中，边缘节点的带宽变化趋势可由边缘节点自身处理得到，比如可以
配置cdn中的边缘节点每隔预设时长采集一次自身的实时带宽值，然后定期对一段时间内采集到的多个实时带宽值进行统计处理得到边缘节点实时的带宽变化趋势。当第一边缘节点接收到客户端的业务请求之后根据最新得到的带宽变化趋势和自身当前的带宽值来预测得到预设时间后的带宽值。
62.步骤303、第一边缘节点判断预设时间后的带宽值是否大于或等于自身当前的成本带宽值，若是，则执行步骤304。
63.举例来说，假设第一边缘节点的成本带宽值为10gb，基于预先得到的带宽变化趋势预测得到第一边缘节点在1秒后的带宽可能会达到12gb，那么，这时第一边缘节点会对客户端的业务请求进行重新调度。
64.步骤304、第一边缘节点基于业务请求中的ip地址和业务类型向中心服务平台请求与客户端同属一个区域，且与客户端请求的业务类型相匹配的至少一个第二边缘节点的带宽余量和业务质量。
65.步骤305、第一边缘节点根据请求获得的至少一个第二边缘节点的带宽余量和业务质量，将客户端的业务请求重新调度到一个或多个第二边缘节点上。
66.本实施例根据第一边缘节点的带宽变化趋势和第一边缘节点当前的带宽值对第一边缘节点在预设时间后的带宽值进行预测，并根据预测结果判断是否需要进行重新调度，能够防止第一边缘节点客的带宽值超过成本带宽值，从而实现了对成本的精细化控制。
67.示例的，图4是本公开实施例提供的又一种业务调度方法的流程图，如图4所示，该方法包括：
68.步骤401、cdn中的第一边缘节点接收客户端的业务请求，业务请求中包括业务类型和客户端的ip地址。
69.步骤402、第一边缘节点根据自身当前的带宽值、成本带宽值以及业务质量，判断是否需要对所述业务请求进行重新调度，其中，若是，则执行步骤403。
70.在本实施例中，第一边缘节点根据自身当前的带宽值、成本带宽值以及业务质量，判断是否需要对客户端的业务请求进行重新调度的方法可以有多种：
71.比如，在一种实施方式中，第一边缘节点可以先根据自身当前的成本带宽值和自身当前的带宽值，计算得到当前的带宽余量，然后将自身当前的带宽余量与预设的第一带宽阈值进行比较，将自身当前的业务质量与客户端请求的业务类型相对应的质量阈值进行比较。如果自身当前的带宽余量小于第一带宽阈值，且自身当前的业务质量小于所述质量阈值，则判断需要对客户端的业务请求进行重新调度，否则判断不需要重新调度。
72.再比如，在另一种实施方式中，第一边缘节点在计算得到的自身当前的带宽余量后，还可以根据预先设定的带宽余量对应的权值和业务质量对应的权值对自身当前的带宽余量和业务质量进行加权处理，然后，将加权后的带宽余量和加权后的业务质量进行求和处理，若求和结果小于预设的阈值，则判断需要进行重新调度，否则判断不需要重新调度。
73.本领域技术人员应该理解的是上述两种实施方式仅是两种示例性的方式而不是本实施例的全部实施方式，实际上，凡是基于边缘节点的带宽余量和业务质量执行的业务重新调度方法均可以被应用到本实施例中。
74.步骤403、第一边缘节点基于业务请求中的ip地址和业务类型向中心服务平台请求与客户端同属一个区域，且与客户端请求的业务类型相匹配的至少一个第二边缘节点的
带宽余量和业务质量。
75.步骤404、第一边缘节点根据请求获得的至少一个第二边缘节点的带宽余量和业务质量，将客户端的业务请求重新调度到一个或多个第二边缘节点上。
76.本实施例中的第一边缘节点根据自身当前的带宽值、成本带宽值和业务质量来判断是否需要对客户端的业务请求进行重新调度，能够同时兼顾成本和业务质量，实现了成本的精细控制，保障了业务质量。
77.需要说明的是，上述实施例中第一边缘节点在判断需要进行重新调度之后的方法也可以由客户端来执行，也就是说，第一边缘节点在判断需要进行重新调度之后会向客户端反馈一个通知消息，客户端在接收到该通知消息后，从中心服务平台上获取至少一个第二边缘节点的带宽余量和业务质量，然后根据获取到的第二边缘节点的带宽余量和业务质量，将业务请求重新调度到一个或多个第二边缘节点上，其执行方式和有意效果与上述实施例类似在这里不在赘述。
78.图5是本公开实施例提供的一种业务调度装置的结构示意图，该业务调度装置可以示例性的理解为上述实施例中的第一边缘节点或者第一边缘节点中的部分功能模块。如图5所示，业务调度装置50包括：
79.接收模块51，用于接收客户端的业务请求，所述业务请求中包括业务类型和所述客户端的ip地址；
80.判断模块52，用于至少根据所述第一边缘节点当前的带宽值和所述第一边缘节点当前的成本带宽值，判断是否需要对所述业务请求进行重新调度；
81.请求模块53，用于在判断需要重新调度时，基于所述ip地址和所述业务类型向所述中心服务平台请求与所述客户端同属一个区域，且与所述业务类型相匹配的至少一个第二边缘节点的带宽余量和业务质量，其中，所述带宽余量是指所述第二边缘节点的成本带宽值与所述第二边缘节点当前的带宽值之间的差值；
82.执行模块54，根据所述至少一个第二边缘节点的带宽余量和业务质量，将所述业务请求重新调度到一个或多个第二边缘节点上。
83.在一种实施方式中，判断模块52，包括：
84.第一判断子模块，用于判断所述第一边缘节点当前的带宽值和所述第一边缘节点当前的成本带宽值之间的大小；
85.第二判断子模块，用于在第一边缘节点当前的带宽值大于或等于第一边缘节点当前的成本带宽值时判断需要对所述业务请求进行重新调度。
86.在一种实施方式中，判断模块52，包括：
87.第一确定子模块，用于基于所述第一边缘节点当前的带宽值和预先得到的所述第一边缘节点的带宽变化趋势，确定所述第一边缘节点在预设时间后的带宽值；
88.第三判断子模块，用于判断所述第一边缘节点在预设时间后的带宽值与所述第一边缘节点当前的成本带宽值之间的大小；
89.第四判断子模块，用于在第一边缘节点在所述预设时间后的带宽值大于或等于第一边缘节点当前的成本带宽值时判断需要重新调度。
90.在一种实施方式中，判断模块52，还用于：根据第一边缘节点当前的带宽值、成本带宽值以及业务质量，判断是否需要对所述业务请求进行重新调度。
91.在一种实施方式中，判断模块52，包括：
92.第二确定子模块，用于根据第一边缘节点当前的带宽值和成本带宽值，确定第一边缘节点当前的带宽余量；
93.第五判断子模块，用于判断第一边缘节点当前的带宽余量是否小于第一带宽阈值，以及第一边缘节点当前的业务质量是否小于所述业务类型对应的质量阈值，若是，则判断需要对所述业务请求进行重新调度。
94.在一种实施方式中，执行模块54，包括：
95.第一执行子模块，用于根据所述至少一个第二边缘节点的带宽余量和业务质量，将所述业务请求重新调度到带宽余量大于或等于第二带宽阈值，业务质量大于或等于所述业务类型对应的质量阈值的第二边缘节点上。
96.在一种实施方式中，执行模块54，还包括：
97.第一处理子模块，用于在所述至少一个第二边缘节点中不包括所述带宽余量大于或等于所述第二带宽阈值，业务质量大于或等于所述质量阈值的第二边缘节点时，分别对每个第二边缘节点的业务质量和带宽余量进行加权求和处理，得到每个第二边缘节点对应的加权求和结果；
98.第二执行子模块，用于将所述业务请求重新调度到所述加权求和结果高于第一预设阈值的第二边缘节点上。
99.在一种实施方式中，执行模块54，包括：
100.第三确定子模块，用于从所述至少一个第二边缘节点中确定出带宽余量大于或等于第二带宽阈值，业务质量大于或等于所述业务类型对应的质量阈值的第二边缘节点，作为候选边缘节点；
101.第二处理子模块，用于分别对每个候选边缘节点的业务质量和带宽余量进行加权求和处理，并将加权求和结果大于第二预设阈值的候选边缘节点作为目标边缘节点；
102.第三执行子模块，用于将所述业务请求重新调度到所述目标边缘节点上。
103.本实施例提供的装置能够执行上述图1-图4中任一实施例的方法，其执行方式和有益效果类似，在这里不在赘述。
104.示例的，图6是本公开实施例提供的一种边缘节点的结构示意图，如图6所示，边缘节点1600包括处理器1601和存储器1602。
105.处理器1601可以是中央处理单元(cpu)或者具有数据处理能力和/或指令执行能力的其他形式的处理单元，并且可以控制边缘节点1600中的其他组件以执行期望的功能。
106.存储器1602可以是各种形式的计算机可读存储介质，例如易失性存储器和/或非易失性存储器。易失性存储器例如可以包括随机存取存储器(ram)和/或高速缓冲存储器(cache)等。非易失性存储器例如可以包括只读存储器(rom)、硬盘、闪存等。存储器1602上存储有计算机程序，当该计算机程序被处理器1601运行时，处理器1601执行上述图1-图4中任一实施例的方法。
107.在一个示例中，边缘节点1600还可以包括：接收装置1603和发送装置1604，这些组件通过总线系统和/或其他形式的连接机构(未示出)互连。
108.其中，接收装置1603可以接收cdn中的客户端、中心服务平台、中心调度设备等设备的发送的数据或者信息。发送装置1604可以向cdn中的客户端、中心服务平台、中心调度
设备等设备发送数据或者信息。
109.当然，为了简化，图6中仅示出了边缘节点1600的部分组件而非全部组件，实际中边缘节点1600还可以包括其他任意的组件。
110.本公开实施例还提供了一种计算机可读存储介质，该存储介质中存储有计算机程序，当所述计算机程序被处理器执行时，使得处理器可以执行上述图1-图4中任一实施例的方法。
111.需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
112.以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。