CN110830533B - 一种用于云分发网络的http调度方法和系统 - Google Patents

Abstract

本发明公开了一种用于云分发网络的HTTP调度方法和系统。该方法包括：中心策略服务器获取网络中所有边缘节点和边缘节点上设备的运行数据，并基于运行数据以第一周期的频率生成针对各边缘节点的调度策略；边缘节点服务器以第二周期的频率从中心策略服务器获取相应于该边缘节点服务器的调度策略；边缘节点服务器接收到访问请求时，若基于访问请求的信息判断存在与访问请求匹配的调度策略且访问请求未经过跳转，则基于该调度策略对访问请求进行调度。本发明的方法和系统增加了依赖数据的维度，提高了调度策略的准确性，并且减少了消耗。

Description

一种用于云分发网络的HTTP调度方法和系统

技术领域

本发明涉及互联网技术领域，尤其涉及一种用于云分发网络的HTTP调度方法及系统。

背景技术

随着互联网技术的发展，互联网内容量级日趋扩大，这使得内容分发网络(CDN，Content Delivery Network)扮演着越来越重要的角色。在CDN行业内，存在两个最核心的系统：缓存系统，用于提供缓存服务；调度系统，用于联通用户与缓存系统，提供全局负载均衡，引导用户到最合适的缓存服务器进行内容交互。

当前，CDN行业内全局负载均衡技术主要有两种：DNS(Domain Name System，域名系统)调度和HTTP(Hypertext transfer protocol，超文本传送协议)调度。其中，DNS调度因容易实现，且容错性相对较好，得到了广泛应用。但DNS调度也存在一些问题，其中最难解决的是域名解析变更生效周期长的问题。因为一般CDN厂商拥有自属权威DNS服务器，但localdns极大多数归属运营商持有维护，且引入了缓存技术，localdns作为用户域名解析的第一个环节，域名变更解析生效，需要localdns更新缓存；CDN厂商无法控制localdns的缓存过期时间，也就控制不了生效周期。HTTP调度，基于HTTP协议的30X状态码实现，技术门槛不高，在客户端支持的前提下，HTTP调度可以提供更快速和精准的负载均衡服务，可以弥补DNS调度的诸多缺陷。

通常HTTP调度有中心调度和边缘调度两种模式。

中心调度模式架构上包含中心策略服务器和中心调度服务器。通常中心策略服务器只需要一台服务器，通过收集全局的带宽数据来计算一定周期的调度策略。中心调度服务器根据请求量级的不同，会是一台设备或者一个集群，它们均向中心策略服务器同步调度策略。中心调度模式通过DNS将用户请求引导至中心调度服务器，然后根据中心调度服务器当前的策略进行调度。

边缘调度模式架构上包含边缘策略服务器和边缘调度服务器(集群)，每个边缘服务器集群包含至少一台边缘策略服务器，它收集所在边缘服务器集群的带宽负载信息，提供调度策略给边缘调度服务器。边缘调度模式同样通过DNS将用户请求引导至边缘调度服务器集群，再根据边缘调度服务器当前的策略进行调度。

以上两种模式各有特点。中心调度模式收集全局的带宽负载信息，可以提供较佳的调度策略，但缺点也很明显，主要是两点：一是全局带宽负载信息实时性不好，会导致调度策略误差；二是中心调度服务器(集群)本身并不提供内容交互服务，所有的请求都至少进行一次30X跳转，多了建立连接时的损耗。边缘调度模式只需要收集边缘节点相关带宽负载信息，实时性相对好，但缺乏全局信息，无法给出全局最佳的调度策略。

因此需要一种HTTP调度模式，以能够实现精准快速低损耗的负载均衡。

发明内容

为了解决现有技术中调度节点服务器的业务中的问题，提出了一种用于云分发网络的HTTP调度方法及系统。

根据本发明的一个方面，提供了一种用于云分发网络的HTTP调度方法，所述方法包括：

中心策略服务器获取网络中所有边缘节点和所述边缘节点上设备的运行数据，并基于所述运行数据以第一周期的频率生成针对各边缘节点的调度策略；

边缘节点服务器以第二周期的频率从所述中心策略服务器获取相应于该边缘节点服务器的调度策略；

边缘节点服务器接收到访问请求时，若基于所述访问请求的信息判断存在与所述访问请求匹配的调度策略且所述访问请求未经过跳转，则基于该调度策略对所述访问请求进行调度。

其中，所述中心策略服务器基于所述运行数据以第一周期的频率生成各边缘节点的调度策略包括：

所述中心策略服务器预测所述运行数据中不满足实时性要求的运行数据，并基于获取的运行数据和预测的运行数据生成所述调度策略。

其中，所述中心策略服务器基于所述运行数据以第一周期的频率生成各边缘节点的调度策略包括：

所述中心策略服务器获取所述边缘节点的故障设备信息，若确定针对一边缘节点的调度策略中包括该边缘节点的故障设备，则取消所述调度策略中向所述故障设备分配的带宽；

并且，所述方法还包括：

所述边缘节点服务器从所述中心策略服务器获取相应于该边缘节点服务器的调度策略后，获取该边缘节点的故障设备，取消所述调度策略中向所述故障设备分配的带宽。

其中，所述边缘节点服务器判断所述访问请求未经过跳转包括：

所述边缘节点服务器基于接收的所述访问请求的信息，判断与所述访问请求相关的URL是否携带表示所述访问请求已经过跳转的标识符，若没有，则判断所述访问请求未经过跳转。

其中，所述中心策略服务器取消所述调度策略中向所述故障设备分配的带宽后，将被取消的带宽重新分配到下述设备中至少一个：

(1)待调出带宽的设备；

(2)调度策略中其他未出现故障的设备；

(3)与所述故障设备属于同一设备组但是尚未被分配带宽的设备；

所述边缘节点服务器取消所述调度策略中向所述故障设备分配的带宽后，将被取消的带宽重新分配到待调出带宽的设备。

根据本发明的另一个方面，还提供了一种用于云分发网络的HTTP调度系统，所述系统包括：

中心策略服务器，用于获取网络中所有边缘节点和所述边缘节点上设备的运行数据，并基于所述运行数据以第一周期的频率生成针对各边缘节点的调度策略；

边缘节点服务器，用于以第二周期的频率从所述中心策略服务器获取相应于该边缘节点服务器的调度策略；并且接收到访问请求时，若基于所述访问请求的信息判断存在与所述访问请求匹配的调度策略且所述访问请求未经过跳转，则基于该调度策略对所述访问请求进行调度。

其中，所述中心策略服务器还用于预测所述运行数据中不满足实时性要求的运行数据，并基于获取的运行数据和预测的运行数据生成所述调度策略。

其中，所述中心策略服务器还用于获取所述边缘节点的故障设备信息，若确定针对一边缘节点的调度策略中包括该边缘节点的故障设备，则取消所述调度策略中向所述故障设备分配的带宽。

并且，所述边缘节点服务器还用于从所述中心策略服务器获取相应于该边缘节点服务器的调度策略后，获取该边缘节点的故障设备，取消所述调度策略中向所述故障设备分配的带宽。

其中，所述边缘节点服务器还用于基于接收的所述访问请求的信息，判断与所述访问请求相关的URL是否携带表示所述访问请求已经过跳转的标识符，若没有，则判断所述访问请求未经过跳转。

其中，所述中心策略服务器还用于在取消所述调度策略中向所述故障设备分配的带宽后，将被取消的带宽重新分配到下述设备中至少一个：

(1)待调出带宽的设备；

(2)调度策略中其他未出现故障的设备；

(3)与所述故障设备属于同一设备组但是尚未被分配带宽的设备；

所述边缘节点服务器还用于在取消所述调度策略中向所述故障设备分配的带宽后，将被取消的带宽重新分配到待调出带宽的设备。

本发明中的用于云分发网络的HTTP调度方法及系统，能够实现下述有益效果：

(1)中心策略服务器生成调度策略时，针对实时性不够好的数据，如节点带宽数据，使用算法进行预测，提高了依赖数据的实时性和准确性；

(2)在提供全局调度策略的同时，并不需要经由中心调度服务器集群，减少了一次30X跳转，减少了消耗；

(3)中心策略服务器和边缘节点服务器，均采用故障设备剔除机制，保障了调度后的服务质量；

(4)中心策略服务器生成调度策略时，除基于全局带宽负载信息外，还基于全局网络链路质量数据，增加了依赖数据的维度，提高了调度策略的准确性；

(5)本发明对原有全局的DNS调度系统侵入性为零，不需要做任何变更，这也提高了调度系统的整体容错性。

附图说明

构成本发明的一部分的附图用来提供对本发明的进一步理解，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明的HTTP调度方法的流程图；

图2是根据本发明的HTTP调度系统的模块图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。

目前的HTTP调度有中心调度和边缘调度两种模式。中心调度模式收集全局的带宽负载信息，可以提供较佳的调度策略，但缺点也很明显，主要是两点：一是全局带宽负载信息实时性不好，会导致调度策略误差；二是中心调度服务器(集群)本身并不提供内容交互服务，所有的请求都至少进行一次30X跳转，多了建立连接时的损耗。边缘调度模式只需要收集边缘节点相关带宽负载信息，实时性相对好，但缺乏全局信息，无法给出全局最佳的调度策略。

本发明提出了一种不同于现有的调度模式，充分利用中心调度和边缘调度的优点，通过中心策略服务器和边缘节点服务器的交互对访问请求进行调度。这里的边缘节点服务器是设置于边缘节点上的服务器，其同时具备边缘调度服务和缓存服务的功能，其可以任何合适的形式布置于边缘节点上。需要说明的是，为了克服中心策略服务器相对于边缘节点策略服务器获取数据较慢的问题，引入了能够让中心策略服务器实时获取边缘节点运行数据的监控子系统，同时，对获取数据中实时性较差的数据进行预测，以保证获取数据的准确性和可靠性。

本发明中的中心策略服务器的作用与中心调度模式的不同在于：(1)在收集全局带宽负载信息时，增加了全局网络链路质量数据(最主要是链路丢包数据)和设备硬件负载数据；同时针对实时性不够好的数据，如全局节点带宽数据，使用算法进行预测。这样不仅增加了数据信息量，也提高了数据的实时性和准确性，最终可计算出全局最佳的负载均衡策略。(2)与边缘节点服务器进行策略信息交互。边缘节点服务器本身即可提供内容交互服务(作为相应边缘缓存服务器的代理)，会定时向中心策略服务器同步策略。用户请求经过DNS引导至边缘节点服务器后，若找到匹配的调度策略且未经过30X跳转，则以该调度策略进行30X跳转；否则，直接通过缓存服务进行内容交互。这样做的好处是，无需对DNS调度做任何改动，提高了调度系统的容错性。

本发明提供了一种用于云分发网络的HTTP调度方法，该方法包括：

步骤101，中心策略服务器获取网络中所有边缘节点和所述边缘节点上设备的运行数据，并基于所述运行数据以第一周期的频率生成针对各边缘节点的调度策略；

步骤102，边缘节点服务器以第二周期的频率从所述中心策略服务器获取相应于该边缘节点服务器的调度策略；

步骤103，边缘节点服务器接收到访问请求时，若基于所述访问请求的信息判断存在与所述访问请求匹配的调度策略且所述访问请求未经过跳转，则基于该调度策略对所述访问请求进行调度。

中心策略服务器以一定周期收集全网所有节点及设备的运行数据，包括网络中所有边缘节点的带宽数据、所述边缘节点上设备的带宽数据、所述设备的硬件负载数据、网络全局链路质量数据。这种方法相比于现有技术中由边缘节点生成调度策略的模式，由于中心策略服务在生成针对各边缘节点的调度策略时考虑了全网的质量数据，即上面列举的数据，因此生成的调度策略反应了全网的信息，调度质量更佳。

中心策略服务器生成调度策略的定时周期，即第一周期的设定依赖于各项信息的反馈，不可过小，亦不可过大。通过大量的实际测试，认为可以将第一周期设置为10秒-3分钟，例如30秒，1分钟，2分钟等，可以实现较佳的效果。过大的周期将导致策略更新的不及时，无法保障全局负载均衡的效果。另外，由于策略的生成依赖于边缘节点反馈的数据，因此第一周期最好稍大于边缘节点反馈数据的周期，以基于最新的数据生成调度策略。这里所依赖的数据信息，主要是指全局边缘节点的带宽数据，边缘节点上各设备的带宽数据，设备的硬件负载数据，及全局链路质量数据等。

另外，调度策略是针对每个边缘节点生成的，即中心策略服务器结合调度质量和调度成本两方面综合决策，生成以每个边缘节点为单位的调度策略。调度策略包括三个维度的信息：(1)针对每个边缘节点，(2)针对边缘节点中的每个设备组，(3)针对每个设备组中的具体设备。因此，该调度策略可以以边缘节点上的各设备为粒度，包括针对每台设备的具体内容，具体包括设备需调出的域名，及该域名可调出至哪些设备及其调出比例(例如，按访问请求的数量)。具体的基于各数据信息生成调度策略的方法可采用现有方法实现，在此不再赘述。

边缘节点服务器，执行策略同步和规则生成及匹配的功能。策略同步是指以一定周期，即第二周期(不大于中心策略服务器的调度策略生成周期，即第一周期)主动向中心策略服务器同步属于自己的最新的调度策略。即第二周期小于或等于第一周期，以保证能及时同步到最新的调度策略。规则生成及匹配是指由同步到的调度策略生成调度规则，并对进来的客户端请求进行特征匹配及相应调度，下面将详细描述调度规则的生成。

边缘节点服务器同步调度策略所采用的第二周期从理论上说越小越好，以更早同步到中心的最新策略。边缘节点服务器将获取到属于自己设备粒度的调度信息，其中，对于负载不高的边缘节点或边缘节点的设备组或各设备，通常并不会有调度策略，而对于负载较高的边缘节点或边缘节点的设备组或各设备，调度策略则可能一致也可能不一致，通常同组设备策略可以一致，而不同组设备策略基本不一致。

其中，中心策略服务器基于运行数据以第一周期的频率生成各边缘节点的调度策略包括：中心策略服务器预测运行数据中不满足实时性要求的运行数据，并基于获取的运行数据和预测的运行数据生成所述调度策略。

中心策略服务器确定出其所获取的运行数据中不满足实时性要求的运行数据，并针对这些不满足实时性要求的数据，如网络中所有边缘节点的带宽数据，使用算法进行预测。这里需要说明的是，中心策略服务器会周期性地从边缘节点获取运行数据，但是由于某些数据需要通过汇聚其他数据才能反馈给中心策略服务器，因此可能边缘节点反馈这些数据的周期较长，对于这种反馈周期较长的数据，中心策略服务器就认为不满足实时性要求。就需要对这些数据进行预测。这样提高了数据的实时性和准确性，最终可计算出全局最佳的负载均衡策略。另外，将实时性不够高的数据信息进行预测，以确保信息反馈足够快速及准确；定时周期也因此可以适当减小，从而生成时效性更好的调度策略。

具体地，对不满足实时性要求的数据进行预测时，可以使用例如最小二乘法进行线性拟合预测。例如边缘节点A的带宽数据，取边缘节点A前10分钟的带宽数据(1分钟粒度)，为规避单点抖动问题,去掉10分钟带宽数据中的最大值和最小值，然后使用最小二乘法预测出当前时刻的带宽值，及1分钟后的带宽值。由于这里的最小二乘法为现有算法，因此不再赘述。

本发明方法中还包括故障设备剔除机制，具体体现为下面两个方面。

中心策略服务器基于运行数据以第一周期的频率生成各边缘节点的调度策略包括：中心策略服务器获取边缘节点的故障设备信息，若确定针对一边缘节点的调度策略中包括该边缘节点的故障设备，则取消调度策略中向故障设备分配的带宽。

另外，本发明的方法还包括：边缘节点服务器从中心策略服务器获取相应于该边缘节点服务器的调度策略后，获取该边缘节点的故障设备，取消调度策略中向故障设备分配的带宽。即，边缘节点服务器同步到调度策略后，定时剔除策略中故障设备，以保障服务质量。

HTTP请求跳转到一台故障设备时，若得不到正常服务，就会影响该请求来源客户的体验质量。因此，中心生成调度策略时，会剔除相应调度策略中的故障设备，同时，边缘节点服务器获取到最新的调度策略时，也会更实时地剔除调度策略的相关列表中的故障设备，尽最大程度保障跳转后的设备是可正常服务的，从而保障服务质量。

具体地，在剔除故障设备时，中心策略服务器和边缘节点服务器分别以各自的设定周期向监控子系统拉取故障设备列表(边缘节点服务器的拉取周期比中心策略服务器的拉取周期短)，据此检查调度策略中是否含有故障设备的IP。如有，中心策略服务器采用下述方式将分配到被剔除的设备IP的带宽进行重新分配：(1)由待调出带宽的设备承接；(2)由调度策略中其他未出现故障的设备承接(这些设备可以是与故障设备属于同一设备组并已分配了带宽的设备)；(3)引入新的设备承接(这些设备可以是与故障设备属于同一设备组但是尚未被分配带宽的设备)；边缘节点服务器采用下述方式将分配到被剔除的设备IP的带宽进行重新分配：由待调出带宽的设备承接。具体可以为包含针对不同域名的承接设备IP及其带宽分配比例的列表，承接设备IP带宽分配比例之和为需要调度到其他设备IP的带宽比例)。

客户端的访问请求被DNS引导至边缘节点服务器后，边缘节点服务器判断其上是否存在匹配的HTTP调度策略且所述访问请求未经过跳转，若满足上述两个条件，将执行该调度策略；否则正常响应该访问请求。其中，主要根据访问请求包含的域名、URL特征以及HTTP头部特征来进行是否存在匹配的HTTP调度策略的判断。即将上述内容与调度策略列表中的内容进行比对，看是否存在匹配的调度策略。

另外，判断访问请求是否经过跳转主要是判断是否经过30X跳转，若已经过30X跳转，则不再进行跳转，否则会导致响应时间过长。

另外，边缘节点服务器判断访问请求未经过跳转包括：

边缘节点服务器基于接收的访问请求的信息，判断与访问请求相关的URL是否携带表示访问请求已经过跳转的标识符，若没有，则判断访问请求未经过跳转。

需要说明的是，若存在匹配的调度策略，边缘节点服务器将按策略中的比例及设备信息，基于一致性HASH算法生成设备的匹配规则。这里可以采用现有技术中的一致性HASH算法。例如，可以将存储有2^32次方个key的空间，可以想象成一个闭合的环形，将调度策略中的某一域名下的所有设备IP，通过某种HASH算法A生成key，处理后映射到环上，客户端访问请求的URL通过HASH算法A生成key1，映射到环上，按顺时针方向找到离key1最近的设备IP。可以按照上述过程对特征一致的客户端访问请求进行逐一调度。值得说明的是，边缘节点服务器在对客户端请求进行调度时，30X跳转的目标设备都是根据前述的规则判定的，目标设备及权重占比由同步到的调度策略决定。因此每次新进来的客户端请求，30X跳转的目标设备均在进行规则匹配之前是非确定的，但整个周期内，最终的调度结果是与调度策略中的权重占比是基本符合的。若不存在调度策略，边缘节点服务器直接响应200OK状态码，并正常响应内容交互。

本发明还提供了一种用于云分发网络的HTTP调度系统，所述系统包括：

中心策略服务器201，用于获取网络中所有边缘节点和所述边缘节点上设备的运行数据，并基于所述运行数据以第一周期的频率生成针对各边缘节点的调度策略；

边缘节点服务器202，用于以第二周期的频率从所述中心策略服务器获取相应于该边缘节点服务器的调度策略；并且接收到访问请求时，若基于所述访问请求的信息判断存在与所述访问请求匹配的调度策略且所述访问请求未经过跳转，则基于该调度策略对所述访问请求进行调度。

其中，所述中心策略服务器201还用于预测所述运行数据中不满足实时性要求的运行数据，并基于获取的运行数据和预测的运行数据生成所述调度策略。

其中，所述中心策略服务器201还用于获取所述边缘节点的故障设备信息，若确定针对一边缘节点的调度策略中包括该边缘节点的故障设备，则取消所述调度策略中向所述故障设备分配的带宽。

其中，所述边缘节点服务器202还用于从所述中心策略服务器获取相应于该边缘节点服务器的调度策略后，获取该边缘节点的故障设备，取消所述调度策略中向所述故障设备分配的带宽。

其中，所述边缘节点服务器202还用于基于接收的所述访问请求的信息，判断与所述访问请求相关的URL是否携带表示所述访问请求已经过跳转的标识符，若没有，则判断所述访问请求未经过跳转。

其中，所述中心策略服务器还用于在取消所述调度策略中向所述故障设备分配的带宽后，将被取消的带宽重新分配到下述设备中至少一个：

(1)待调出带宽的设备；

(2)调度策略中其他未出现故障的设备；

(3)与所述故障设备属于同一设备组但是尚未被分配带宽的设备；

所述边缘节点服务器还用于在取消所述调度策略中向所述故障设备分配的带宽后，将被取消的带宽重新分配到待调出带宽的设备。

本发明中的用于云分发网络的HTTP调度方法及系统，能够实现下述有益效果：

(1)中心策略服务器生成调度策略时，针对实时性不够好的数据，如节点带宽数据，使用算法进行预测，提高了依赖数据的实时性和准确性；

(2)在提供全局调度策略的同时，并不需要经由中心调度服务器集群，减少了一次30X跳转，减少了消耗；

(3)中心策略服务器和边缘节点服务器，均采用故障设备剔除机制，保障了调度后的服务质量；

(4)中心策略服务器生成调度策略时，除基于全局带宽负载信息外，还基于全局网络链路质量数据，增加了依赖数据的维度，提高了调度策略的准确性；

(5)本发明对原有全局的DNS调度系统侵入性为零，不需要做任何变更，这也提高了调度系统的整体容错性。

上面描述的内容可以单独地或者以各种方式组合起来实施，而这些变型方式都在本发明的保护范围之内。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括所述要素的物品或者设备中还存在另外的相同要素。

以上实施例仅用以说明本发明的技术方案而非限制，仅仅参照较佳实施例对本发明进行了详细说明。本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或者等同替换，而不脱离本发明技术方案的精神和范围，均应涵盖在本发明的权利要求范围当中。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些组件或所有组件可以被实施为由处理器，如数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

Claims (8)

1.一种用于云分发网络的HTTP调度方法，其特征在于，所述方法包括：

中心策略服务器获取网络中所有边缘节点和所述边缘节点上设备的运行数据，并基于所述运行数据以第一周期的频率生成针对各边缘节点的调度策略；

边缘节点服务器以第二周期的频率从所述中心策略服务器获取相应于该边缘节点服务器的调度策略；

边缘节点服务器接收到访问请求时，若基于所述访问请求的信息判断存在与所述访问请求匹配的调度策略且所述访问请求未经过跳转，则基于该调度策略对所述访问请求进行调度；

所述边缘节点服务器判断所述访问请求未经过跳转包括：

所述边缘节点服务器基于接收的所述访问请求的信息，判断与所述访问请求相关的URL是否携带表示所述访问请求已经过跳转的标识符，若没有，则判断所述访问请求未经过跳转。

2.如权利要求1所述的HTTP调度方法，其特征在于，所述中心策略服务器基于所述运行数据以第一周期的频率生成各边缘节点的调度策略包括：

所述中心策略服务器预测所述运行数据中不满足实时性要求的运行数据，并基于获取的运行数据和预测的运行数据生成所述调度策略。

3.如权利要求1所述的HTTP调度方法，其特征在于，所述中心策略服务器基于所述运行数据以第一周期的频率生成各边缘节点的调度策略包括：

所述中心策略服务器获取所述边缘节点的故障设备信息，若确定针对一边缘节点的调度策略中包括该边缘节点的故障设备，则取消所述调度策略中向所述故障设备分配的带宽；

并且，所述方法还包括：

所述边缘节点服务器从所述中心策略服务器获取相应于该边缘节点服务器的调度策略后，获取该边缘节点的故障设备，取消所述调度策略中向所述故障设备分配的带宽。

4.如权利要求3所述的HTTP调度方法，其特征在于，所述中心策略服务器取消所述调度策略中向所述故障设备分配的带宽后，将被取消的带宽重新分配到下述设备中至少一个：

(1)待调出带宽的设备；

(2)调度策略中其他未出现故障的设备；

(3)与所述故障设备属于同一设备组但是尚未被分配带宽的设备；

所述边缘节点服务器取消所述调度策略中向所述故障设备分配的带宽后，将被取消的带宽重新分配到待调出带宽的设备。

5.一种用于云分发网络的HTTP调度系统，其特征在于，所述系统包括：

中心策略服务器，用于获取网络中所有边缘节点和所述边缘节点上设备的运行数据，并基于所述运行数据以第一周期的频率生成针对各边缘节点的调度策略；

边缘节点服务器，用于以第二周期的频率从所述中心策略服务器获取相应于该边缘节点服务器的调度策略；并且接收到访问请求时，若基于所述访问请求的信息判断存在与所述访问请求匹配的调度策略且所述访问请求未经过跳转，则基于该调度策略对所述访问请求进行调度；

所述边缘节点服务器还用于基于接收的所述访问请求的信息，判断与所述访问请求相关的URL是否携带表示所述访问请求已经过跳转的标识符，若没有，则判断所述访问请求未经过跳转。

6.如权利要求5所述的HTTP调度系统，其特征在于，

所述中心策略服务器还用于预测所述运行数据中不满足实时性要求的运行数据，并基于获取的运行数据和预测的运行数据生成所述调度策略。

7.如权利要求5所述的HTTP调度系统，其特征在于，

所述中心策略服务器还用于获取所述边缘节点的故障设备信息，若确定针对一边缘节点的调度策略中包括该边缘节点的故障设备，则取消所述调度策略中向所述故障设备分配的带宽；

并且，所述边缘节点服务器还用于从所述中心策略服务器获取相应于该边缘节点服务器的调度策略后，获取该边缘节点的故障设备，取消所述调度策略中向所述故障设备分配的带宽。

8.如权利要求7所述的HTTP调度系统，其特征在于，所述中心策略服务器还用于在取消所述调度策略中向所述故障设备分配的带宽后，将被取消的带宽重新分配到下述设备中至少一个：

(1)待调出带宽的设备；

(2)调度策略中其他未出现故障的设备；

(3)与所述故障设备属于同一设备组但是尚未被分配带宽的设备；

所述边缘节点服务器还用于在取消所述调度策略中向所述故障设备分配的带宽后，将被取消的带宽重新分配到待调出带宽的设备。

Images