CN114466069A

CN114466069A - 数据采集***

Info

Publication number: CN114466069A
Application number: CN202111617804.2A
Authority: CN
Inventors: 杨主决; 向校民; 王金土
Original assignee: Tianyi Cloud Technology Co Ltd
Current assignee: Tianyi Cloud Technology Co Ltd
Priority date: 2021-12-27
Filing date: 2021-12-27
Publication date: 2022-05-10
Anticipated expiration: 2041-12-27

Abstract

本发明实施例涉及一种数据采集***，该***包括：边缘服务器组中的每一个边缘服务器，用于接收用户请求；第一代理服务器，用于对用户请求进行第一归类处理，获取第一汇总数据；并将第一汇总数据发送至第二代理服务器；第二代理服务器，用于对第一汇总数据进行第二归类处理，获取第二汇总数据，并将第二汇总数据分别发送至每一个数据处理中心服务器；每一个数据处理中心服务器，分别用于当确定第二汇总数据为自身管辖范围内待处理的数据时，对第二汇总数据进行第三归类处理，获取第三汇总数据。避免由于数据处理中心服务器同时所有海量复杂的数据进行归类处理，所带来的负载过大和时效低的问题。

Description

数据采集***

技术领域

本发明实施例涉及通信技术领域，尤其涉及一种数据采集***及带宽采集方法。

背景技术

随着互联网的快速发展，并且随着5G的普及，内容分发网络(Content DeliveryNetwork，简称CDN)调度***需要承载越来越大的带宽量。由此带来以下挑战和存在的问题：

(1)客户在某个区域的带宽量，大部分都是不可预测，大多数客户都存在带宽需求突发的情况；

(2)无法实时采集CDN节点带宽，CDN节点带宽使用率已经超过阈值，无法及时进行切换；

(3)带宽数据数据采集方式不合理，导致数据丢失严重，从而影响合理进行客户资源规划。

CDN***自动化资源调度决策，什么时候开始调度，调度到哪里，完全依赖实时带宽的数据基础。带宽量大，对于实时调度也存在很大的挑战。

因此，现急需一种带宽采集方法，在边缘节点多和带宽量大的时候，能实时、准确和完整的采集客户以及机器所使用的实时带宽。使CDN调度***对于客户带宽需求突发或者资源故障时，能够对带宽资源进行有效的调度，从而保证客户的整体服务质量。

发明内容

本申请提供了一种数据采集***及带宽采集方法，以解决现有技术中上述技术问题。

第一方面，本申请提供了一种数据采集***，该***包括：所述数据采集***包括：多条数据采集通道，每条数据采集通道包括边缘服务器组、第一代理服务器、第二代理服务器，每条数据采集通道分别与至少一个数据处理中心服务器建立通信连接；

边缘服务器组中的每一个边缘服务器，用于接收用户请求；

第一代理服务器，用于对用户请求进行第一归类处理，获取第一汇总数据；并将第一汇总数据发送至第二代理服务器；

第二代理服务器，用于对第一汇总数据进行第二归类处理，获取第二汇总数据，并将第二汇总数据分别发送至每一个数据处理中心服务器；

至少一个数据处理中心服务器中的每一个数据处理中心服务器，分别用于对第二汇总数据进行第三归类处理，获取第三汇总数据。

本申请实施例提供的上述技术方案与现有技术相比具有如下优点：

本申请实施例提供的该数据采集***，采用分治算法思想，实现将复杂海量数据采集后，拆分成多个小模块的数据归类方案，也即是分成多条数据采集通道并行执行数据采集工作。而且，通过第一代理服务器执行一阶归类处理，然后再通过第二代理服务器执行二阶归类处理，最终将第二汇总数据传输到数据处理中心服务器处理。通过上述方式，实现分而治之的思想，所有工作都是细分到不同通道，不同模块执行。由此，减轻数据处理中心服务器的处理负担。避免由于某一个数据处理中心服务器同时对所有海量复杂的数据进行归类处理，所带来的负载过大和时效低的问题。保证在边缘节点多和带宽量大的时候，能实时、准确和完整的采集客户以及机器所使用的实时带宽。使CDN调度***对于客户带宽需求突发或者资源故障时，能够对带宽资源进行有效的调度，从而保证客户的整体服务质量。而且，边缘服务器组、第一代理服务器、第二代理服务器以及数据处理中心服务器之间采用流式传输，避免数据文件“落地”，减少中间损耗。

附图说明

图1为本发明实施例提供的一种数据采集***结构示意图；

图2为本发明提供的分而治之思想的原理性结构示意图；

图3为本发明提供的数据上报流程框图；

图4本发明提供的数据采集***中各本发明提供的数据处理中心服务器根据协议中的数据头，将实时数据调度分发到不同的通道，根据业务规则并行处理的结构示意图；

图5为本发明提供的包括配置中心管理服务器、数据采集***等的整体***架构图；

图6为本发明提供的多条数据采集路径分别和多个数据处理中心(服务器)建立通信连接的流程框图。

具体实施方式

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

为便于对本发明实施例的理解，下面将结合附图以具体实施例做进一步的解释说明，实施例并不构成对本发明实施例的限定。

针对背景技术中所提及的技术问题，本申请实施例提供了一种数据采集***，具体参见图1所示。在介绍本实施例中数据采集***所包括的模块之前，首先介绍与数据采集***建立通信连接的配置管理中心服务器。配置管理中心服务器包括客户域名模块、资产管理模块、客户资源规划模块，以及配置下发模块等。

其中，客户域名模块：主要维护客户在公司进行CDN加速的客户域名信息以及客户套餐信息。

资产管理模块：用于维护节点信息，机房信息，机器资源信息，按地理位置和运营商维度划分加速区域：将所有得边缘机器按照地理位置和运营商维度，划分到归属区域；为每个区域创建一个区域节点自治机；这样每个边缘服务器，在逻辑上就与所属区域的节点自治机产生了逻辑上的关系。

客户资源规划：维护客户域名在各个加速区域上规划的资源列表。

配置下发模块：用于将规划好客户的机器资源信息，下发至每个边缘机器，边缘机器即可知道有服务哪些客户域名，以及边缘服务器所要上报的区域节点自治机；将每个区域节点自治机控制的边缘服务器列表，下发至各个区域节点自治机器；将区域节点自治机列表下发到所有的数据处理中心。

由此，边缘服务器可以知道自身的统计数据需要上报至哪个区域节点资质机。而区域节点自治机则能够明确自身统计的数据需要上报至哪个数据处理中心。通过该方式，可以为数据采集***配置多条数据采集通道。每一条数据采集通道可以包括边缘服务器组、第一代理服务器、第二代理服务器以及数据处理中心服务器。其中，第一代理服务器是边缘服务器组中的代理服务器，用于对边缘服务器组中的每一个边缘服务器收集的用户请求进行归类处理。第二代理服务器为区域节点自治机器对应的代理服务器，用于直接和第一代理服务器，以及数据处理中心服务器建立通信连接，保证数据不落地，减少中间损耗。

具体的，数据采集***的结构示意图参见图1所示，该***包括：多条数据采集通道，每条数据采集通道包括边缘服务器组、第一代理服务器、第二代理服务器，每条数据采集通道分别与至少一个数据处理中心服务器建立通信连接。图1示出的是3条数据采集通道，以及两个数据处理中心服务器。

边缘服务器组中的每一个边缘服务器，用于接收用户请求；

至少一个数据处理中心服务器中的每一个数据处理中心服务器分别用于确定第二汇总数据是否为自身管辖范围内待处理的数据；

当确定第二汇总数据为自身管辖范围内待处理的数据时，对第二汇总数据进行第三归类处理，获取第三汇总数据。

本申请实施例中采用分而治之的思想，将数据采集工作划分为多条数据采集通道采集。具体的分而治之的思想可以参见图2所示。也即是，将某一个父问题，拆分为多个子问题，通过相应处理后，得到多个子结果，最终将这些子结果进行汇总得到父问题结果。

每个数据采集通道都包括多个模块分别执行不同的工作(相同于分别对多个子问题进行处理)。进而对采集的数据进行归类处理。使得最终采集的数据到达数据处理中心时，基本已经归类成型，方便后续处理。为后续的处理工作减轻负担。最终至少一个数据处理中心服务器中的每个数据处理中心服务器对归类后内容进行识别，获取自身处理的部分，并获取相应的处理结果。当所有处理结果进行汇总后，则即为父问题结果。也即是，最后生成不同维度的调度指标。这些内容都将在下文中进行一一介绍。

具体的，边缘服务器是CDN的一个边缘节点。用于在CDN加速时，方便用户访问的节点。用户在访问时，边缘服务器可以接收用户访问请求，然后记录日志数据。

在一个可选的例子中，用户请求可以包括但不限于如下字段信息：请求时间、第一IP、第二IP、访问域名、访问流量，以及请求次数，其中，第一IP为访客客户端对应的IP，第二IP为访客客户端待访问的IP。

边缘服务器节点将上述数据以日志的形式进行记录。

边缘服务器部署代理服务(也即是第一代理服务器)，当接收到配置中心下发的配置后，就可以获知自己归属哪个区域节点自治机进行管理，进而通过第一代理服务器与对应的区域节点自治机服务建立长连接。

第一代理服务器，则用于对用户请求进行第一归类处理，获取第一汇总数据。然后将第一汇总数据发送至第二代理服务器。

在一个具体的例子中，第一代理服务器可以周期性的统计日志数据，然后进行归类。例如，每间隔5分钟统计一次日志数据。

具体的日志数据其中一种体现形式如下：

#时间戳VIP访客IP客户域名流量(B)请求数量

2021-07-05 19:00:00 61.134.42.12 14.220.30.197www.ctyun.cn 5277011810

2021-07-05 19:00:00 61.134.42.12 10.125.30.101www.ctyun.cn 33388 10

2021-07-05 19:00:00 61.134.42.12 5.220.18.105www.ctyun.cn 515 10

2021-07-05 19:00:00 61.134.42.12 222.193.25.156www.ctyun.cn 108551 10

第一代理服务器每5分钟对日志数据进行一次汇总，数据汇总依赖配置中心下发的配置。在一个可选的实施例中，配置规则可以包括但不限于如下内容：

根据第一IP,确定访客的客户端所属区域；根据第二IP，从多条数据采集通道分别对应的边缘服务器组中，确定发出用户请求的边缘服务器组。

在一个具体的例子中，第一IP为用户所使用的客户端对应的IP，而第二IP为用户访问请求对应的上游IP。

因此，第一代理服务器，可以根据第一IP确定用户(访客)的客户端所属区域，也即是确定用户当前所在区域。

具体的，可以将访客IP，也即是第一IP，到IP库数据去匹配，按照地理位置和运营商划分的，匹配到对应的区域，如匹配到的结果为：

dianxin_fujian,yidong_fujian。

以及，根据第二IP确定从多条数据采集通道分别对应的边缘服务器组中，确定发出用户请求的边缘服务器组。

由于边缘服务器有可能当前时刻是接受该用户访问的请求，但是在下一时刻，该边缘服务器发生故障，而后续与用户的交互，则需要通过该边缘服务器组中的其他边缘服务器完成。因此，第一代理服务器并非是根据第二IP直接匹配到对应的边缘服务器，而是直接匹配到对应的边缘服务器组。

然后，按照请求时间、发出用户请求的边缘服务器组、访客的客户端所属区域、访问域名、访问流量，以及请求次数构成的第一汇总规范，对用户请求进行汇总，获取第一汇总数据。

如上的例子，汇总所得到的第一汇总数据格式可以参见如下示例：

#时间戳集群名称访客所属区域客户域名流量(B)请求数量

2021-07-05 19:00:00dianxin_cluster1 dianxin_fujianwww.ctyun.cn2000000 10

2021-07-05 19:00:00dianxin_cluster1 dianxin_beijingwww.ctyun.cn2800000 50

2021-07-05 19:00:00dianxin_cluster1 dianxin_fujianwww.ctyun1.cn10000000 100

2021-07-05 19:00:00dianxin_cluster1 dianxin_fujianwww.ctyun1.cn35000000 120

在每个区域节点自治机器上同样部署一个代理服务，用来初步处理数据，每个边缘缓存服务器直接区域中心的服务器进行直连，区域中心服务器必然会扛不住，所以通过代理(第二代理服务器)进行分布式汇总。

即，每个数据采集通道中，第一代理服务器将第一汇总数据发送至第二代理服务器。第二代理服务器，用于对第一汇总数据进行第二归类处理，获取第二汇总数据。

在一个可选的例子中，第二代理服务器提供数据接收端口，供第一代理服务器与第二代理服务器建立通信连接，第一代理服务器对数据进行汇总后，数据不落地，直接上报到区域中心的第二代理服务器。

第二代理服务器具体用于，从第一汇总数据中提取每个用户请求中的如下字段构成第二汇总规范：请求时间、发出用户请求的边缘服务器组、访客的客户端所属区域，以及访问域名；

根据第二汇总规范，对第一汇总数据执行精简归类处理，获取第二汇总数据。

然后，并将第二汇总数据分发至每一个数据处理中心服务器。

至少一个数据处理中心服务器中的每一个数据处理中心服务器分别用于，确定第二汇总数据是否为自身管辖范围内待处理的数据；

具体的，如上所介绍的，第二汇总数据中包括访客所属区域，那么不同的数据管理中心服务器可以是分管不同的区域的数据。当识别该访客区域为自身管辖区域时，则可以确定该数据为自身所待处理的数据，进而对第二汇总数据进行汇总处理。当然，也可以通过其他方式识别第二汇总数据是否属于自身待处理的数据。例如，根据第二汇总数据中的客户域名来确定，亦或是服务器集群等。具体根据何种标识信息确定可以根据实际情况设定，这里不再做过多限定。当然，如果某些数据处理中心服务器发现第二汇总数据不是自身需要处理的数据时，则可以删除(丢弃)第二汇总数据，以避免占用内部资源。

将第二汇总数据分发到不同的数据处理中心服务器，是防止数据漏报。比如某个数据处理中心需要处理某部分数据，但是第二代理服务器发送数据时出错，发送至其他数据处理中心服务器处。当然，在一个可实施的方式中，在数据不能漏报的情况下，也可以直接在第二代理服务器处区分要发送的数据处理中心服务器，而不用分别分发到不同的数据处理中心服务器。

在一个可选的例子中，数据处理中心服务器同样提供数据端口供第二代理服务器上报数据，而且，可以同时支持TCP和HTTP等数据传输方式进行上报数据。具体参见图3所示。图3示意处理数据上报流程框图。

具体参见图3所示，在具体的数据上报时，需要将数据抽象成一条一条的数据流，上报的方式不同，但是使用统一的数据协议，具体格式如下：

#数据头时间戳数据主键(支持多个字段)数据值…

数据一:

DOMAIN_BANDWIDTH 1625484000www.ctyun.cn dx_fujian dx_cluster1 3750000100

DOMAIN_BANDWIDTH 1625484000www.ctyun.cn dx_beijing dx_cluster13750000 100

DOMAIN_BANDWIDTH 1625484000www.ctyun1.cn dx_fujian dx_cluster13750000 100

DOMAIN_BANDWIDTH 1625484000www.ctyun2.cn dx_fujian dx_cluster13750000 100

数据二：

CLUSTER_BANDWIDTH 1625484000dx_cluster1 3750000 100

CLUSTER_BANDWIDTH 1625484000dx_cluster2 3750000 100

CLUSTER_BANDWIDTH 1625484000yd_cluster2 3750000 100

进一步可选的，数据处理中心接收到上报的数据后，为了避免数据上报与多个数据处理耦合在一起，比如可能上报数据夹带在一起的，同一个客户的带宽数据和请求数据同时上报的，则需要根据数据头进行区分，拆分数据后执行不同的处理。数据处理中心服务器，还用于对第二汇总数据进行预处理。

在一个可行的实施例中，数据处理中心服务器可以利用责任链FilterChain对数据初步预处理，包括数据清洗和过滤等。

在责任链中，可以自行配置过滤规则：例如配置数据头过滤，字段长度，带宽大小范围等过滤规则。

可选的，数据处理中心服务器在对第二汇总数据进行预处理后，再执行对第二汇总数据进行第三归类处理，具体可以如下步骤实现：

对第二汇总数据进行分类，获取多个第四汇总数据；

并按照与每一个第四汇总数据的类别对应的处理规则，并行对第四汇总数据进行处理，分别获取与每一个第四汇总数据对应的第三汇总数据。

其中，数据处理中心服务器，对第二汇总数据进行分类，获取多个第四汇总数据，可以参见如下方式：

从第二汇总数据中的每一条数据中提取数据头；

根据数据头中的信息，对第二汇总数据进行分类，获取多个第四汇总数据。

在一个具体例子中，具体参见图4所示，图4示出了数据处理中心服务器根据协议中的数据头，将实时数据调度分发到不同的通道，根据业务规则并行处理的结构示意图。

处理器-记录数据-缓存-将数据划分到不同的渠道(包括平滑处理、更新、分析，以及快照等)，最终将经过处理后的数据进行缓存。

可选的，除了上述操作外，还需要考虑到对于缓存机器数据量大的时候，机器上下架，机房割接，网络波动，服务升级等情况，会造成短暂的数据缺失。

因此，数据处理中心服务器还用于，对第三汇总数据进行容灾处理，以及数据平滑处理。

具体的，对于带宽数据来讲，除非客户突发或者高峰时间段，一个时间点的前后左右几个点的带宽数据，带宽量差别不大，因此，当某几个时刻数据缺失时，可以采用最近时间点的带宽数据来进行容灾处理。

此外，考虑到在数据采集过程中，难免会产生噪点数据，特别是对于带宽数据会发生突增突降，这对于资源调度会产生比较明显的频繁切换。因此，数据处理中心服务器还可以用于，对第三汇总数据进行去噪处理。

具体的，可以采用指数平滑算法去噪点。具体参见如下：

给定平滑系数α，取值范围(0,1.0]，那么二次指数平滑的计算公式为：

S′_t＝α*x_t+(1-α)*S′_t-1 (公式1)

S″_t＝α*S′_t+(1-α)*S″_t-1 (公式2)

平滑未来T期的值的计算公式为：

Y_t+T＝A_T-B_T*T (公式3)

其中：

A_t＝2*S′_t-S″_t (公式4)

去噪过程可以通过上述方式实现，这里不再过多赘述。

进一步可选的，执行上述操作后，数据处理中心还用于按照预设分类维度，对第三汇总数据进行分类，获取分类维度对应的调度指标。

在一个具体的例子中，最后生成不同维度调度指标，以以下为几个代表性指标数据为例：

客户在各个加速区域的实时带宽量

www.ctyun.com dianxin_beijing时间戳带宽量

www.ctyun.com dianxin_xiamen时间戳带宽量

节点带宽实时使用情况

厦门电信机房时间戳上限带宽带宽量冗余带宽量

北京电信机房时间戳上限带宽带宽量冗余带宽量

厦门移动机房时间戳上限带宽带宽量冗余带宽量

服务器集群实时带宽使用情况以及冗余情况

dianxin_xiamen_cluster1时间戳上限带宽带宽量冗余带宽量

yidong_xiamen_cluster1时间戳上限带宽带宽量冗余带宽量

识别客户在加速区域突发情况

www.ctyun.com dianxin_beijing时间戳1(1：突发,0：未突发)

www.ctyun.com yidong_beijing时间戳1(1：突发,0：未突发)

www.ctyun.com dianxin_xiamen时间戳0(1：突发,0：未突发)

另外，考虑到数据采集的完整性以及稳定性，对于CDN自动化调度来讲至关重要，所以对于边缘服务器和区域节点自治机的带宽采集稳定性也要采用一定监控的手段。

例如，边缘服务器定时10s上报一次心跳包到对应的区域节点自治机，区域节点自治机器对自己所控制的边缘机器的心跳包进行汇总和统计，将异常的边缘机器列表上报至数据处理中心。

同理，区域节点自治机定时10s上报一次心跳包到数据处理中心，数据处理中心负责区域节点自治机的监控

其中，心跳包的监控规则，可以是实时接收心跳包数据，维护一个hash表，用于记录每个服务器的心跳包数据。

每个周期定时10s扫描hash表，检测心跳包的有效性，心跳包过期后，则从hash表中移除,如果curr_timestamp–timestamp>max_times*timing_cycle成立，则代表心跳包失效。

其中，curr_timestamp:代表当前时间戳

timestamp:代表心跳包对应时间戳

timing_cycle:代表扫描周期时间

max_times:代表有效周期数

遍历当前机器控制的服务器列表，进行匹配心跳包数据，如果不存在，则服务异常，进行监控告警，人工介入修复。

图5中示意出了包括配置中心管理服务器、数据采集***中各功能模块，以及其他需要的元件所组成的整体***架构图。

具体参见图5所示，包括：

业务访问请求通过负载均衡设备，分别传输到与目标请求所属区域对应的边缘服务器组。各边缘服务器组采集数据后，(通过第一代理服务器)传输到区域节点资质机(传输到第二代理服务器)。区域节点资质机将数据传输到实时数据处理中心(数据处理中心服务器)。

图6示出了3条数据采集路径(包括边缘服务器到区域中心，隐藏了第一代理服务器和第二代理服务器)分别和2个数据处理中心(服务器)建立通信连接的流程框图。图6仅为一种具体示例，具体数据采集通道，以及数据处理中心服务器等的数量可根据实际情况设定。

图5和图6中的数据采集过程均在上图中做了详细的描述，因此这里不再过多赘述。

本发明实施例提供的数据采集***，采用分治算法思想，实现将复杂海量数据采集后，拆分成多个小模块的数据归类方案，也即是分成多条数据采集通道并行执行数据采集工作。而且，通过第一代理服务器执行一阶归类处理，然后再通过第二代理服务器执行二阶归类处理，最终将第二汇总数据传输到数据处理中心服务器处理。通过上述方式，实现分而治之的思想，所有工作都是细分到不同通道，不同模块执行。由此，减轻数据处理中心服务器的处理负担。避免由于某一个数据处理中心服务器同时对所有海量复杂的数据进行归类处理，所带来的负载过大和时效低的问题。保证在边缘节点多和带宽量大的时候，能实时、准确和完整的采集客户以及机器所使用的实时带宽。使CDN调度***对于客户带宽需求突发或者资源故障时，能够对带宽资源进行有效的调度，从而保证客户的整体服务质量。而且，边缘服务器组、第一代理服务器、第二代理服务器以及数据处理中心服务器之间采用流式传输，避免数据文件“落地”，减少中间损耗。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上仅是本发明的具体实施方式，使本领域技术人员能够理解或实现本发明。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。

Claims

1.一种数据采集***，其特征在于，所述数据采集***包括：多条数据采集通道，每条数据采集通道包括边缘服务器组、第一代理服务器、第二代理服务器，每条数据采集通道分别与至少一个数据处理中心服务器建立通信连接；

所述边缘服务器组中的每一个边缘服务器，用于接收用户请求；

所述第一代理服务器，用于对所述用户请求进行第一归类处理，获取第一汇总数据；并将所述第一汇总数据发送至所述第二代理服务器；

所述第二代理服务器，用于对所述第一汇总数据进行第二归类处理，获取第二汇总数据，并将所述第二汇总数据分别发送至每一个所述数据处理中心服务器；

至少一个数据处理中心服务器中的每一个所述数据处理中心服务器，分别用于确定所述第二汇总数据是否为自身管辖范围内待处理的数据；

当确定所述第二汇总数据为自身管辖范围内待处理的数据时，对所述第二汇总数据进行第三归类处理，获取第三汇总数据。

2.根据权利要求1所述的***，其特征在于，所述***还包括：所述用户请求中包括如下字段信息：请求时间、第一IP、第二IP、访问域名、访问流量，以及请求次数，其中，所述第一IP为访客客户端对应的IP，所述第二IP为所述访客客户端待访问的IP；

所述第一代理服务器，具体用于：根据所述第一IP，确定所述访客的客户端所属区域；

根据所述第二IP，从多条数据采集通道分别对应的所述边缘服务器组中，确定发出所述用户请求的边缘服务器组；

按照所述请求时间、发出所述用户请求的边缘服务器组、所述访客的客户端所属区域、所述访问域名、所述访问流量，以及所述请求次数构成的第一汇总规范，对所述用户请求进行汇总，获取所述第一汇总数据。

3.根据权利要求2所述的***，其特征在于，所述第二代理服务器具体用于，从所述第一汇总数据中提取每个用户请求中的如下字段构成第二汇总规范：所述请求时间、发出所述用户请求的边缘服务器组、所述访客的客户端所属区域，以及所述访问域名；

根据所述第二汇总规范，对所述第一汇总数据执行精简归类处理，获取第二汇总数据。

4.根据权利要求1-3任一项所述的***，其特征在于，所述数据处理中心服务器，还用于对所述第二汇总数据进行预处理。

5.根据权利要求1-3任一项所述的***，其特征在于，所述数据处理中心服务器，具体用于：

对所述第二汇总数据进行分类，获取多个第四汇总数据；

并按照与每一个所述第四汇总数据的类别对应的处理规则，并行对所述第四汇总数据进行处理，分别获取与每一个第四汇总数据对应的第三汇总数据。

6.根据权利要求5所述的***，其特征在于，所述数据处理中心服务器，具体用于：

从所述第二汇总数据中的每一条数据中提取数据头；

根据所述数据头中的信息，对所述第二汇总数据进行分类，获取多个第四汇总数据。

7.根据权利要求1-3或6任一项所述的***，其特征在于，所述数据处理中心服务器还用于，对所述第三汇总数据进行容灾处理，以及数据平滑处理。

8.根据权利要求1-3或6任一项所述的***，其特征在于，所述数据处理中心服务器还用于，根据所述第三汇总数据，生成调度指标。

9.根据权利要求8所述的***，其特征在于，所述数据处理中心服务器，还用于：

按照预设分类维度，对所述第三汇总数据进行分类，获取所述分类维度对应的调度指标。

10.根据权利要求1-3或6任一项所述的***，其特征在于，所述数据处理中心服务器还用于，当确定所述第二汇总数据不属于自身管辖范围内的待处理数据时，丢弃所述第二汇总数据。