一种网络资源的管理方法以及相关装置与流程

一种网络资源的管理方法以及相关装置
[0001]
本申请为2020年3月4日提交中国专利局、申请号为202010143223.9、发明名称为“一种网络资源的管理方法以及相关装置”的中国专利申请的分案申请。
技术领域
[0002]
本申请涉及计算机技术领域，尤其涉及一种网络资源的管理方法以及相关装置。


背景技术：

[0003]
域名系统(domain name system，dns)服务是一项基础网络设施。用户访问域名，首先要获取到服务ip，需向本地域名系统(local domain name system，ldns)发起请求，ldns通过递归请求，向权威dns请求。对权威dns来说，通过答复ldns请求，回应不同服务ip，可将用户请求引导至相应设备上，服务用户请求的同时，也对用户流量作了调度控制。
[0004]
一般，为了减轻网络设备的负载情况，可以根据本地域名系统ldns的运营商地理属性，采取就近原则调度。即以同一片运营商地理属性的用户作为调度对象，进行网络资源的负载均衡。
[0005]
但是，由于实际场景中流量分布不均，当单域名流量达到t级别以上，片区用户基数大，需求流量存在过大的问题。权威dns答复此类请求时，存在最大答复资源数不满足需求的状况，造成调度精度及控制力下降，影响网络资源调度的稳定性和精确性。


技术实现要素：

[0006]
有鉴于此，本申请提供一种网络资源的管理的方法，可以有效避免在大流量的场景中调度不稳定的问题，提高网络资源的管理过程的稳定性和精确性。
[0007]
本申请第一方面提供一种网络资源的管理的方法，可以应用于服务器中包含网络资源的管理功能的系统或程序中，具体包括：获取多个终端的用户访问日志；
[0008]
确定所述用户访问日志对应的路径信息，所述路径信息包括本地域名系统中的前端缓存服务器、所述本地域名系统中的后端递归服务器和权威域名系统的关联关系；
[0009]
根据所述路径信息的相似度进行聚类，以得到路径簇；
[0010]
根据所述终端对于所述路径簇的隶属关系调度网络资源，所述隶属关系基于所述终端对于所述路径簇中对应路径的访问次数之间的比例确定。
[0011]
可选的，在本申请一些可能的实现方式中，所述根据所述路径信息的相似度进行聚类，以得到路径簇，包括：
[0012]
确定所述路径信息的特征向量，所述特征向量用于指示所述前端缓存服务器与所述后端递归服务器的关联关系；
[0013]
根据所述特征向量的相似度进行聚类，以得到路径簇。
[0014]
可选的，在本申请一些可能的实现方式中，所述确定所述路径信息的特征向量，包括：
[0015]
确定所述路径信息中指示的后端递归服务器；
[0016]
分别根据所述路径信息中指示的后端递归服务器为键遍历对应的前端缓存服务器，以生成路径特征；
[0017]
根据所述路径特征之间的相似性生成所述特征向量。
[0018]
可选的，在本申请一些可能的实现方式中，所述确定所述路径信息的特征向量，包括：
[0019]
控制所述终端向所述本地域名系统发送测试指令，以得到所述后端递归服务器和所述前端缓存服务器的对应关系；
[0020]
根据所述后端递归服务器和所述前端缓存服务器的对应关系进行聚类，以得到所述特征向量。
[0021]
可选的，在本申请一些可能的实现方式中，所述根据所述终端对于所述路径簇的隶属关系调度网络资源，包括：
[0022]
确定所述路径簇对应的路径集合；
[0023]
获取所述终端分别对于所述路径集合中路径的访问信息；
[0024]
根据所述访问信息确定所述隶属关系；
[0025]
基于所述隶属关系进行网络资源的调度。
[0026]
可选的，在本申请一些可能的实现方式中，所述基于所述隶属关系进行网络资源的调度，包括：
[0027]
获取实时流量信息；
[0028]
基于所述隶属关系确定资源分配信息；
[0029]
根据所述资源分配信息和所述实时流量信息确定偏差信息，以指示所述权威域名系统进行网络资源调度。
[0030]
可选的，在本申请一些可能的实现方式中，所述基于所述隶属关系确定资源分配信息，包括：
[0031]
确定所述权威域名系统的网络资源处理阈值；
[0032]
根据所述隶属关系对所述网络资源处理阈值进行分配，以得到所述资源分配信息。
[0033]
可选的，在本申请一些可能的实现方式中，所述确定所述权威域名系统的网络资源处理阈值，包括：
[0034]
确定所述终端对应的权重信息；
[0035]
根据所述权重信息确定所述权威域名系统对于所述终端的网络资源处理阈值。
[0036]
可选的，在本申请一些可能的实现方式中，所述确定所述用户访问日志对应的路径信息，包括：
[0037]
控制所述用户访问日志对应的终端进行递归查询，以得到所述终端与所述前端缓存服务器的关联关系、所述后端递归服务器与所述权威域名系统的关联关系；
[0038]
控制边缘服务器向所述前端缓存服务器向所述权威域名系统发送探询报文，以得到所述前端缓存服务器与所述后端递归服务器的关联关系；
[0039]
根据所述终端与所述前端缓存服务器的关联关系、所述后端递归服务器与所述权威域名系统的关联关系和所述前端缓存服务器与所述后端递归服务器的关联关系确定所述路径信息。
[0040]
可选的，在本申请一些可能的实现方式中，所述获取多个终端的用户访问日志，包括：
[0041]
获取终端的归属信息；
[0042]
根据所述归属信息信息筛选满足预设条件的所述用户访问日志，所述预设条件基于归属信息中不同维度的相似性确定。
[0043]
可选的，在本申请一些可能的实现方式中，所述获取多个终端的用户访问日志，包括：
[0044]
响应于所述终端发送的调度请求确定关联终端集合；
[0045]
获取所述关联终端集合中多个终端的用户访问日志。
[0046]
可选的，在本申请一些可能的实现方式中，所述网络资源的管理方法应用于区块链设备，所述区块链设备为区块链中的节点。
[0047]
本申请第二方面提供一种网络资源的管理的装置，包括：获取单元，用于获取多个终端的用户访问日志；
[0048]
确定单元，用于确定所述用户访问日志对应的路径信息，所述路径信息包括本地域名系统中的前端缓存服务器、所述本地域名系统中的后端递归服务器和权威域名系统的关联关系；
[0049]
聚类单元，用于根据所述路径信息的相似度进行聚类，以得到路径簇；
[0050]
管理单元，用于根据所述终端对于所述路径簇的隶属关系调度网络资源，所述隶属关系基于所述终端对于所述路径簇中对应路径的访问次数之间的比例确定。
[0051]
可选的，在本申请一些可能的实现方式中，所述聚类单元，具体用于确定所述路径信息的特征向量，所述特征向量用于指示所述前端缓存服务器与所述后端递归服务器的关联关系；
[0052]
所述聚类单元，具体用于根据所述特征向量的相似度进行聚类，以得到路径簇。
[0053]
可选的，在本申请一些可能的实现方式中，所述聚类单元，具体用于确定所述路径信息中指示的后端递归服务器；
[0054]
所述聚类单元，具体用于分别根据所述路径信息中指示的后端递归服务器为键遍历对应的前端缓存服务器，以生成路径特征；
[0055]
所述聚类单元，具体用于根据所述路径特征之间的相似性生成所述特征向量。
[0056]
可选的，在本申请一些可能的实现方式中，所述聚类单元，具体用于控制所述终端向所述本地域名系统发送测试指令，以得到所述后端递归服务器和所述前端缓存服务器的对应关系；
[0057]
所述聚类单元，具体用于根据所述后端递归服务器和所述前端缓存服务器的对应关系进行聚类，以得到所述特征向量。
[0058]
可选的，在本申请一些可能的实现方式中，所述管理单元，具体用于确定所述路径簇对应的路径集合；
[0059]
所述管理单元，具体用于获取所述终端分别对于所述路径集合中路径的访问信息；
[0060]
所述管理单元，具体用于根据所述访问信息确定所述隶属关系；
[0061]
所述管理单元，具体用于基于所述隶属关系进行网络资源的调度。
[0062]
可选的，在本申请一些可能的实现方式中，所述管理单元，具体用于获取实时流量信息；
[0063]
所述管理单元，具体用于基于所述隶属关系确定资源分配信息；
[0064]
所述管理单元，具体用于根据所述资源分配信息和所述实时流量信息确定偏差信息，以指示所述权威域名系统进行网络资源调度。
[0065]
可选的，在本申请一些可能的实现方式中，所述管理单元，具体用于确定所述权威域名系统的网络资源处理阈值；
[0066]
所述管理单元，具体用于根据所述隶属关系对所述网络资源处理阈值进行分配，以得到所述资源分配信息。
[0067]
可选的，在本申请一些可能的实现方式中，所述管理单元，具体用于确定所述终端对应的权重信息；
[0068]
所述管理单元，具体用于根据所述权重信息确定所述权威域名系统对于所述终端的网络资源处理阈值。
[0069]
可选的，在本申请一些可能的实现方式中，所述确定单元，具体用于控制所述用户访问日志对应的终端进行递归查询，以得到所述终端与所述前端缓存服务器的关联关系、所述后端递归服务器与所述权威域名系统的关联关系；
[0070]
所述确定单元，具体用于控制边缘服务器向所述前端缓存服务器向所述权威域名系统发送探询报文，以得到所述前端缓存服务器与所述后端递归服务器的关联关系；
[0071]
所述确定单元，具体用于根据所述终端与所述前端缓存服务器的关联关系、所述后端递归服务器与所述权威域名系统的关联关系和所述前端缓存服务器与所述后端递归服务器的关联关系确定所述路径信息。
[0072]
可选的，在本申请一些可能的实现方式中，所述获取单元，具体用于获取终端的归属信息；
[0073]
所述获取单元，具体用于根据所述归属信息信息筛选满足预设条件的所述用户访问日志，所述预设条件基于归属信息中不同维度的相似性确定。
[0074]
可选的，在本申请一些可能的实现方式中，所述获取单元，具体用于响应于所述终端发送的调度请求确定关联终端集合；
[0075]
所述获取单元，具体用于获取所述关联终端集合中多个终端的用户访问日志。
[0076]
本申请第三方面提供一种计算机设备，包括：存储器、处理器以及总线系统；所述存储器用于存储程序代码；所述处理器用于根据所述程序代码中的指令执行上述第一方面或第一方面任一项所述的网络资源的管理的方法。
[0077]
本申请第四方面提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述第一方面或第一方面任一项所述的网络资源的管理的方法。
[0078]
从以上技术方案可以看出，本申请实施例具有以下优点：
[0079]
通过获取多个终端的用户访问日志；然后确定用户访问日志对应的路径信息，其中路径信息包括本地域名系统中的前端缓存服务器、本地域名系统中的后端递归服务器和权威域名系统的关联关系；进而根据路径信息的相似度进行聚类，以得到路径簇；并根据终端对于路径簇的隶属关系调度网络资源。从而实现了基于用户需求进行网络资源调度的过
程，解决了域名流量过大造成设备流量承载过高的问题，提高了负载均衡能力以及稳定性；且基于用户需求进行调度粒度更细，使得在调度时可以做到充分使用容量而不跑超容量，提高了网络资源调度的精确度。
附图说明
[0080]
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
[0081]
图1为网络资源的管理系统运行的网络架构图；
[0082]
图2为本申请实施例提供的一种网络资源的管理的系统架构图；
[0083]
图3为本申请实施例提供的一种网络资源的管理的方法的流程图；
[0084]
图4为本申请实施例提供的一种网络资源管理方法的场景示意图；
[0085]
图5为本申请实施例提供的另一种网络资源的管理的方法的流程图；
[0086]
图6为本申请实施例提供的另一种网络资源管理方法的场景示意图；
[0087]
图7为本申请实施例提供的一种网络资源管理装置的结构示意图；
[0088]
图8为本申请实施例提供的一种服务器的结构示意图；
[0089]
图9a为本申请实施例提供的一种数据共享系统；
[0090]
图9b为本申请实施例提供的一种区块链的组成；
[0091]
图9c为本申请实施例提供的一种区块链节点的输入信息示意图。
具体实施方式
[0092]
本申请实施例提供了一种网络资源的管理的方法以及相关装置，可以应用于终端设备中包含网络资源的管理功能的系统或程序中，通过获取多个终端的用户访问日志；然后确定用户访问日志对应的路径信息，其中路径信息包括本地域名系统中的前端缓存服务器、本地域名系统中的后端递归服务器和权威域名系统的关联关系；进而根据路径信息的相似度进行聚类，以得到路径簇；并根据终端对于路径簇的隶属关系调度网络资源。从而实现了基于用户需求进行网络资源调度的过程，解决了域名流量过大造成设备流量承载过高的问题，提高了负载均衡能力以及稳定性；且基于用户需求进行调度粒度更细，使得在调度时可以做到充分使用容量而不跑超容量，提高了网络资源调度的精确度。
[0093]
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“对应于”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
[0094]
首先，对本申请实施例中可能出现的一些名词进行解释。
[0095]
域名系统(domain name system，dns)：一种分布式网络目录服务，主要用于域名
与ip地址的相互转换，以及控制因特网的电子邮件的发送。
[0096]
权威域名系统：用于域名解析，对特定域名持有最终管理权限。
[0097]
边缘服务器(outer center，oc)：分散在用户侧的节点，为用户提供就近内容服务。
[0098]
最大传输单元(maximum transmission unit，mtu)：通信双方对报文大小的约定限制。
[0099]
本地域名系统(local domain name system，ldns)：运营商设置在用户本地的服务节点。
[0100]
前端缓存服务器(front_ldns)：ldns服务节点的缓存dns，面向用户。
[0101]
后端递归服务器(back_ldns)：ldns服务节点的递归dns，面向权威dns。
[0102]
应理解，本申请提供的网络资源的管理方法可以应用于终端设备中包含网络资源的管理功能的系统或程序中，例如调度系统平台，具体的，网络资源的管理系统可以运行于如图1所示的网络架构中，如图1所示，是网络资源的管理系统运行的网络架构图，如图可知，网络资源的管理系统可以提供与多个信息源的网络资源的管理，终端通过网络建立与服务器的连接，向服务器发送需求的网络资源，服务器进行调度管理后进行网络资源的分配；可以理解的是，图1中示出了多种终端设备，在实际场景中可以有更多或更少种类的终端设备参与到网络资源的管理的过程中，具体数量和种类因实际场景而定，此处不做限定，另外，图1中示出了一个服务器，但在实际场景中，也可以有多个服务器的参与，特别是在多内容应用交互的场景中，具体服务器数量因实际场景而定。
[0103]
可以理解的是，上述网络资源的管理系统可以运行于个人移动终端，例如：作为dns调度系统这样的应用，也可以运行于服务器，还可以作为运行于第三方设备以提供网络资源的管理，以得到信息源的网络资源的管理处理结果；具体的网络资源的管理系统可以是以一种程序的形式在上述设备中运行，也可以作为上述设备中的系统部件进行运行，还可以作为云端服务程序的一种，具体运作模式因实际场景而定，此处不做限定。
[0104]
随着4g普及，移动互联网发展，直播视频等大流量业务发展，市场上的带宽翻倍增长。单域名流量已然跨过t级别，5g阶段大流量增长趋势仍将沿续。大宗流量使得调度规模增大，粒度见长，给设备负载，带宽成本控制带来挑战。
[0105]
ipv6的发展进一步加剧了调度粒度方面的影响。dns报文大小控制在最小物理链路mtu(500～520),则权威dns答复ldns请求的报文内容ip个数被限定在有限个数内，一般设为15个ip，此时dns交互过程效率最高。ipv6网络中，ipv6地址4倍于ipv4，进一步限制了报文所容纳ip个数。如何解决ip存在承担流量需求过载的风险成为难题。
[0106]
域名系统服务是一项基础网络设施。用户访问域名，首先要获取到服务ip，需向ldns发起请求，ldns通过递归请求，向权威dns请求。对权威dns来说，通过答复ldns请求，回应不同服务ip，可将用户请求引导至相应设备上，服务用户请求的同时，也对用户流量作了调度控制。
[0107]
一般，为了减轻网络设备的负载情况，可以根据本地域名系统ldns的运营商地理属性，采取就近原则调度。即以同一片运营商地理属性的用户作为调度对象，进行网络资源的负载均衡。
[0108]
但是，由于实际场景中流量分布不均，当单域名流量达到t级别以上，片区用户基
数大，需求流量存在过大的问题。权威dns答复此类请求时，存在最大答复资源数不满足需求的状况，造成调度精度及控制力下降，影响网络资源调度的稳定性和精确性。
[0109]
为了解决上述问题，本申请提出了一种网络资源的管理的方法，该方法应用于图2所示的网络资源的管理的系统框架中，如图2所示，为本申请实施例提供的一种网络资源的管理的系统架构图，即对于每个ldns基于路径簇(ldns_id)再次进行划分使得在进行网络资源管理时，权威dns可以根据ldns_id的流量需求进行资源的调度，从而精确的与边缘服务器进行交互实现调度过程。
[0110]
可以理解的是，将ldns划分为ldns_id的依据是终端(user_ip)、前端缓存服务器(front_ldns)、后端递归服务器(back_ldns)之间的关联关系；其中front_ldns面向用户，back_ldns面向权威dns，即权威dns的来访对象是back_ldns。通过将具有相似用户群体的back_ldns划分为同一个ldns_id，ldns_id所服务的用户群里是较为稳定的，则其背后的流量也较为稳定。而用户群体数量较为庞大，由于与用户直接关联的是front_ldns，则用户对应的front_ldns也较为固定，则推出具有相似front_ldns的back_ldns划分为同一个ldns_id，从而实现ldns基于用户需求的划分过程。
[0111]
可以理解的是，图2中示出了两个终端、两个ldns以及两个oc，但在实际场景中，可以有更多或更少的数量，具体数量因实际场景而定。
[0112]
可以理解的是，本申请所提供的方法可以为一种程序的写入，以作为硬件系统中的一种处理逻辑，也可以作为一种网络资源管理装置，采用集成或外接的方式实现上述处理逻辑。作为一种实现方式，该网络资源管理装置通过获取多个终端的用户访问日志；然后确定用户访问日志对应的路径信息，其中路径信息包括本地域名系统中的前端缓存服务器、本地域名系统中的后端递归服务器和权威域名系统的关联关系；进而根据路径信息的相似度进行聚类，以得到路径簇；并根据终端对于路径簇的隶属关系调度网络资源。从而实现了基于用户需求进行网络资源调度的过程，解决了域名流量过大造成设备流量承载过高的问题，提高了负载均衡能力以及稳定性；且基于用户需求进行调度粒度更细，使得在调度时可以做到充分使用容量而不跑超容量，提高了网络资源调度的精确度。
[0113]
结合上述流程架构，下面将对本申请中网络资源的管理的方法进行介绍，请参阅图3，图3为本申请实施例提供的一种网络资源的管理的方法的流程图，该网络资源的管理的方法可以应用于图2所示架构中的权威dns，本申请实施例至少包括以下步骤：
[0114]
301、权威dns获取多个终端的用户访问日志。
[0115]
本实施例中，终端即为与用户交互的设备，可以是手机、便携式电脑等；用户可以通过终端进行需求的网络服务，从而产生对应的用户访问日志；其中，用户访问日志可以是根据当前多个终端的数据流提取而得的，也可以是历史数据整合而成。
[0116]
可选的，由于在域名管理中，不同的运营商对应着不同的数据，故可以获取终端的归属信息，然后根据归属信息信息筛选满足预设条件的用户访问日志，例如：筛选用户访问日志中指示与用户处于同一省份同一运营商的用户访问日志；从而提高了数据的针对性，便于网络资源的管理。
[0117]
在一种可能的场景中，多个终端的网络数据可能存在一定的关联，为保证调度对象的完整性，可以响应于终端发送的调度请求确定关联终端集合，然后获取关联终端集合中多个终端的用户访问日志，从而提高了调度对象的准确性。
[0118]
302、权威dns确定用户访问日志对应的路径信息。
[0119]
本实施例中，路径信息包括本地域名系统中的前端缓存服务器、本地域名系统中的后端递归服务器和权威域名系统的关联关系；下面结合附图对该关联关系进行说明，如图4所示，为本申请实施例提供的一种网络资源管理方法的场景示意图，图中示出了ldns节点为参照，其分为前端缓存服务器front_ldns、后端缓存服务器back_ldns，其中front_ldns面向用户，back_ldns面向权威dns，即权威dns的来访对象是back_ldns。本实施例中，将ldns划分为ldns_id的依据是user_ip、front_ldns、back_ldns之间的关联关系。
[0120]
具体的，通过将具有相似用户群体的back_ldns划分为同一个ldns_id，ldns_id所服务的用户群里是较为稳定的，则其背后的流量也较为稳定。而用户群体数量较为庞大，由于与用户直接关联的是front_ldns，则用户对应的front_ldns也较为固定，则推出具有相似front_ldns的back_ldns划分为同一个ldns_id，从而实现ldns基于用户需求的划分过程，例如：图4中back_ldns1、back_ldns 2、back_ldns 3面向的用户相似，则划分为同一ldns_id。
[0121]
可选的，路径信息可以是权威dns内存储的历史信息，也可以是进行实时探测获取的，具体的，可以控制用户访问日志对应的终端进行递归查询，以得到终端与前端缓存服务器的关联关系、后端递归服务器与权威域名系统的关联关系；对应的，控制边缘服务器向前端缓存服务器向权威域名系统发送探询报文，以得到前端缓存服务器与后端递归服务器的关联关系；进而根据终端与前端缓存服务器的关联关系、后端递归服务器与权威域名系统的关联关系和前端缓存服务器与后端递归服务器的关联关系确定路径信息。
[0122]
可以理解的是，控制终端进行递归查询的过程可以是权威dns发起的，也可以是权威dns中的网络资源管理插件发起的，还可以是终端应用响应于用户的操作发起的，具体方式因实际场景而定。
[0123]
303、权威dns根据路径信息的相似度进行聚类，以得到路径簇。
[0124]
本实施例中，路径簇(ldns_id)即为具有相似路径特征的多条路径的集合，其中，路径特征即为路径中涉及的设备之间的关联关系，例如front_ldns、back_ldns以及终端。在一种可能的场景中，ldns中包含front_ldns1和front_ldns 2，以及back_ldns1。终端可以通过访问front_ldns1，然后访问back_ldns1，即可进行与权威dns的数据交互，该过程为路径1(ldnsip1)；终端还可以通过访问front_ldns2，然后访问back_ldns1，即可进行与权威dns的数据交互，该过程为路径2(ldnsip2)；由于ldnsip1和ldnsip2指示的终端都通过back_ldns1访问权威dns，则可以将ldnsip1和ldnsip2归为同一类路径，即ldnsip1和ldnsip2的集合为一个路径簇。
[0125]
具体的，路径信息的相似度可以是基于路径信息的特征向量进行的，下面结合图4，对特征向量的形成进行说明，首先以back_ldns为键，front_ldns为值，产生如下特征向量：
[0126]
back_ldns1(front_ldns1,front_ldns 2,front_ldns3,front_ldns4)
[0127]
back_ldns2(front_ldns1,front_ldns2)
[0128]
back_ldns3(front_ldns5,front_ldns6)
[0129]
然后，三者进行两两比较，相似个数为值；其中back_ldns1和back_ldns1比较，值为4，back_ldns1和back_ldns2比较，值为2，以此类推，最终产生特征向量：
[0130]
ldnsip1(4,2,0)
[0131]
ldnsip2(2,2,0)
[0132]
ldnsip3(0,0,2)
[0133]
进一步的，根据特征向量相似度，进行聚类，则可聚为以下两个路径簇ldns_id0和ldns_id1：
[0134]
ldns_id0：ldnsip1，ldnsip2
[0135]
ldns_id1：ldnsip3
[0136]
可以理解的是，特征向量即指示了front_ldns和back_ldns的对应关系，故还可以通过控制终端向本地域名系统发送测试指令，例如www.encode(user_ip，front_ldns).test.com，以得到后端递归服务器和前端缓存服务器的对应关系；然后根据后端递归服务器和前端缓存服务器的对应关系进行聚类，以得到特征向量。由于测试得到的数据会将(user_ip,front_ldns,back_ldns)进行强关联，使得路径信息的拓扑关系关联更直接，进而使得数据更清晰。
[0137]
304、权威dns根据终端对于路径簇的隶属关系调度网络资源。
[0138]
本实施例中，隶属关系基于终端对于路径簇中对应路径的访问次数之间的比例确定。这是由于流量需求是根据用户和ldns_id的隶属关系，并结合实时线上流量统计产生。
[0139]
可以理解的是，一个用户可能对应多个front_ldns，则该用户可同时隶属多个ldns_id，通过统计用户访问ldns_id的概率，即可计算出用户和ldns_id的隶属关系，具体的，首先确定路径簇对应的路径集合；然后获取终端分别对于路径集合中路径的访问信息；并根据访问信息确定隶属关系；进而基于隶属关系进行网络资源的调度。
[0140]
例如：一个用户7次访问ldnsip1，2次访问ldnsip2，1次访问ldnsip3，则用户和ldns_id的隶属度关系为ldns_id0:9，ldns_id1:1，即ldns_id0与ldns_id1的网络资源分配比为9:1；若有10g的流量需求，则其中9g来自ldns_id0，1g来自ldns_id1，进而调度边缘服务器进行相应的流量分配。
[0141]
在实际场景中，还可以基于事实的流量分配进行流量调整，即首先获取实时流量信息；然后基于隶属关系确定资源分配信息；进而根据资源分配信息和实时流量信息确定偏差信息，即调整比例，从而指示权威域名系统进行网络资源调度。
[0142]
可选的，由于权威dns可能出现网络资源处理能力有限的情况，此时，可以基于权威dns的网络资源处理阈值，进行基于隶属关系的分配过程，从而得到资源分配信息。
[0143]
在一种可能的场景中，相关人员还可以对流量分配进行限流，例如在流量控制的场景中，首先确定终端对应的权重信息；然后根据权重信息确定权威域名系统对于终端的网络资源处理阈值，从而提高了网络资源管理的灵活性。
[0144]
结合上述实施例可知，通过获取多个终端的用户访问日志；然后确定用户访问日志对应的路径信息，其中路径信息包括本地域名系统中的前端缓存服务器、本地域名系统中的后端递归服务器和权威域名系统的关联关系；进而根据路径信息的相似度进行聚类，以得到路径簇；并根据终端对于路径簇的隶属关系调度网络资源。从而实现了基于用户需求进行网络资源调度的过程，解决了域名流量过大造成设备流量承载过高的问题，提高了负载均衡能力以及稳定性；且基于用户需求进行调度粒度更细，使得在调度时可以做到充分使用容量而不跑超容量，提高了网络资源调度的精确度。
[0145]
上述实施例介绍了网络资源的管理的过程，其中，介绍了路径信息可以是实时获取的，下面对该场景进行说明；请参阅图5，图5为本申请实施例提供的另一种网络资源的管理的方法的流程图，本申请实施例至少包括以下步骤：
[0146]
501、终端发起调度。
[0147]
本实施例中，终端可以响应于权威dns发送的调度指令进行调度的过程；也可以响应于终端应用的发起，具体的可以是用户手动触发的，也可以是客户端应用自动发起的。
[0148]
502、终端向本地域名系统发送迭代请求。
[0149]
503、本地域名系统进行递归查询。即发起统一资源定位符(uniform resource locator，url)携带user_ip的http请求。
[0150]
504、本地域名系统向权威域名系统发送查询请求。其中，查询请求用于指示ldns通过递归查询访问权威dns。
[0151]
505、权威域名系统确定访问信息。其中，权威dns根据url解析出user_ip，结合来访的back_ldns，生成user_ip和back_ldns的关联信息，即访问信息。
[0152]
506、边缘服务器和权威域名系统之间发起路径测试。例如边缘oc下发dig@front_ldns www.encode(front_ldns).test.com命令，使报文定向经front_ldns节点，通过其相应的back_ldns，然后到达权威dns；从而得到front_ldns和back_ldns的关联关系。
[0153]
507、权威域名系统确定特征向量。权威dns获取到front_ldns和back_ldns的关联关系后，以back_ldns为键，front_ldns为值，产生特征向量。
[0154]
508、权威域名系统确定调度信息。即权威dns根据实时用户访问日志，及上述user_ip和back_ldns的关联信息,front_ldns和back_ldns的关联关系，计算路径簇的组成,进而求出ldns_id之间比例。
[0155]
509、权威域名系统和边缘服务器之间发起网络资源调度。
[0156]
本实施例中，根据上述ldns_id之间比例进行流量分配；另外还可以根据线上偏差反馈信息，实时校正ldns_id比例。
[0157]
下面结合一种具体的场景，对网络资源的调度过程进行说明，如图6所示，是本申请实施例提供的另一种网络资源管理的场景示意图。图中示出了通过上述步骤501-508可以得到路径簇信息、用户信息和用户访问日志。
[0158]
其中，路径簇信息中指示了路径簇1(ldns_id 60048)包含的ldns的ip为60.174.56.5；路径簇2(ldns_id 60049)包含的ldns的ip为120.10.32.7，120.10.32.8，120.10.32.11；
[0159]
而用户信息可以通过客户端发送请求指令http://encode(userip).learn.com，得到用户的ip地址为32.1.23.3，其对应的后端递归服务器(back_dns)的地址为60.174.56.5。
[0160]
另外，通过用户访问日志可以得到用户的ip地址为32.1.23.3，访问域名(domain)为dldir1.qq.com，大小为1024b；其实时需求为dldir1.qq.com需求2.8g。将上述信息进行离线计算，结合用户的访问情况得到同省同运营商路径簇之间的比例参数为0:0.25；60048:0.38；60049:0.37；从而得到调度信息并分发给oc进行网络资源的调度；在调度的同时，oc还会反馈当前实时的分配情况，并进行偏差计算，以使得权威dns调整网络资源分配的比例。
[0161]
结合上述实施例可见，由于调度粒度的缩小，解决了域名流量过大造成设备流量承载过高的问题，提高负载均衡能力。且由于调度精度提高，使得在调度时可以做到充分使用容量而不跑超容量，节省成本。
[0162]
为了更好的实施本申请实施例的上述方案，下面还提供用于实施上述方案的相关装置。请参阅图7，图7为本申请实施例提供的一种网络资源管理装置的结构示意图，网络资源管理装置700包括：
[0163]
获取单元701，用于获取多个终端的用户访问日志；
[0164]
确定单元702，用于确定所述用户访问日志对应的路径信息，所述路径信息包括本地域名系统中的前端缓存服务器、所述本地域名系统中的后端递归服务器和权威域名系统的关联关系；
[0165]
聚类单元703，用于根据所述路径信息的相似度进行聚类，以得到路径簇；
[0166]
管理单元704，用于根据所述终端对于所述路径簇的隶属关系调度网络资源，所述隶属关系基于所述终端对于所述路径簇中对应路径的访问次数之间的比例确定。
[0167]
可选的，在本申请一些可能的实现方式中，所述聚类单元703，具体用于确定所述路径信息的特征向量，所述特征向量用于指示所述前端缓存服务器与所述后端递归服务器的关联关系；
[0168]
所述聚类单元703，具体用于根据所述特征向量的相似度进行聚类，以得到路径簇。
[0169]
可选的，在本申请一些可能的实现方式中，所述聚类单元703，具体用于确定所述路径信息中指示的后端递归服务器；
[0170]
所述聚类单元703，具体用于分别根据所述路径信息中指示的后端递归服务器为键遍历对应的前端缓存服务器，以生成路径特征；
[0171]
所述聚类单元703，具体用于根据所述路径特征之间的相似性生成所述特征向量。
[0172]
可选的，在本申请一些可能的实现方式中，所述聚类单元703，具体用于控制所述终端向所述本地域名系统发送测试指令，以得到所述后端递归服务器和所述前端缓存服务器的对应关系；
[0173]
所述聚类单元703，具体用于根据所述后端递归服务器和所述前端缓存服务器的对应关系进行聚类，以得到所述特征向量。
[0174]
可选的，在本申请一些可能的实现方式中，所述管理单元704，具体用于确定所述路径簇对应的路径集合；
[0175]
所述管理单元704，具体用于获取所述终端分别对于所述路径集合中路径的访问信息；
[0176]
所述管理单元704，具体用于根据所述访问信息确定所述隶属关系；
[0177]
所述管理单元704，具体用于基于所述隶属关系进行网络资源的调度。
[0178]
可选的，在本申请一些可能的实现方式中，所述管理单元704，具体用于获取实时流量信息；
[0179]
所述管理单元704，具体用于基于所述隶属关系确定资源分配信息；
[0180]
所述管理单元704，具体用于根据所述资源分配信息和所述实时流量信息确定偏差信息，以指示所述权威域名系统进行网络资源调度。
[0181]
可选的，在本申请一些可能的实现方式中，所述管理单元704，具体用于确定所述权威域名系统的网络资源处理阈值；
[0182]
所述管理单元704，具体用于根据所述隶属关系对所述网络资源处理阈值进行分配，以得到所述资源分配信息。
[0183]
可选的，在本申请一些可能的实现方式中，所述管理单元704，具体用于确定所述终端对应的权重信息；
[0184]
所述管理单元704，具体用于根据所述权重信息确定所述权威域名系统对于所述终端的网络资源处理阈值。
[0185]
可选的，在本申请一些可能的实现方式中，所述确定单元702，具体用于控制所述用户访问日志对应的终端进行递归查询，以得到所述终端与所述前端缓存服务器的关联关系、所述后端递归服务器与所述权威域名系统的关联关系；
[0186]
所述确定单元702，具体用于控制边缘服务器向所述前端缓存服务器向所述权威域名系统发送探询报文，以得到所述前端缓存服务器与所述后端递归服务器的关联关系；
[0187]
所述确定单元702，具体用于根据所述终端与所述前端缓存服务器的关联关系、所述后端递归服务器与所述权威域名系统的关联关系和所述前端缓存服务器与所述后端递归服务器的关联关系确定所述路径信息。
[0188]
可选的，在本申请一些可能的实现方式中，所述获取单元701，具体用于获取终端的归属信息；
[0189]
所述获取单元701，具体用于根据所述归属信息信息筛选满足预设条件的所述用户访问日志，所述预设条件基于归属信息中不同维度的相似性确定。
[0190]
可选的，在本申请一些可能的实现方式中，所述获取单元701，具体用于响应于所述终端发送的调度请求确定关联终端集合；
[0191]
所述获取单元701，具体用于获取所述关联终端集合中多个终端的用户访问日志。
[0192]
通过获取多个终端的用户访问日志；然后确定用户访问日志对应的路径信息，其中路径信息包括本地域名系统中的前端缓存服务器、本地域名系统中的后端递归服务器和权威域名系统的关联关系；进而根据路径信息的相似度进行聚类，以得到路径簇；并根据终端对于路径簇的隶属关系调度网络资源。从而实现了基于用户需求进行网络资源调度的过程，解决了域名流量过大造成设备流量承载过高的问题，提高了负载均衡能力以及稳定性；且基于用户需求进行调度粒度更细，使得在调度时可以做到充分使用容量而不跑超容量，提高了网络资源调度的精确度。
[0193]
本申请实施例还提供了一种服务器，请参阅图8，图8是本申请实施例提供的一种服务器的结构示意图，该服务器800可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，cpu)822(例如，一个或一个以上处理器)和存储器832，一个或一个以上存储应用程序842或数据844的存储介质830(例如一个或一个以上海量存储设备)。其中，存储器832和存储介质830可以是短暂存储或持久存储。存储在存储介质830的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器822可以设置为与存储介质830通信，在服务器800上执行存储介质830中的一系列指令操作。
[0194]
服务器800还可以包括一个或一个以上电源826，一个或一个以上有线或无线网络
接口850，一个或一个以上输入输出接口858，和/或，一个或一个以上操作系统841，例如windows server
tm
，mac os x
tm
，unix
tm
,linuxtm，freebsd
tm
等等。
[0195]
上述实施例中由图像渲染装置所执行的步骤可以基于该图8所示的计算机设备结构。
[0196]
本申请实施例中还提供一种计算机可读存储介质，该计算机可读存储介质中存储有网络资源管理指令，当其在计算机上运行时，使得计算机执行如前述图2至图6所示实施例描述的方法中网络资源管理装置所执行的步骤。
[0197]
本申请实施例中还提供一种包括网络资源管理指令的计算机程序产品，当其在计算机上运行时，使得计算机执行如前述图2至图6所示实施例描述的方法中网络资源管理装置所执行的步骤。
[0198]
本申请实施例还提供了一种网络资源管理系统，所述网络资源管理系统可以包含图7所描述实施例中的网络资源管理装置，或者图8所描述的服务器。
[0199]
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
[0200]
在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
[0201]
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0202]
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
[0203]
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，网络资源管理装置，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
[0204]
在一种可能的场景中，本申请中的网络资源管理的方法应用于区块链设备中，即权威dns、ldns或终端为区块链设备，且该区块链设备为区块链中的节点，下面结合附图进行说明；参见图9a所示的数据共享系统，数据共享系统900是指用于进行节点与节点之间数据共享的系统，该数据共享系统中可以包括多个节点901，多个节点901可以是指数据共享
系统中各个客户端。每个节点901在进行正常工作可以接收到输入信息，并基于接收到的输入信息维护该数据共享系统内的共享数据。为了保证数据共享系统内的信息互通，数据共享系统中的每个节点之间可以存在信息连接，节点之间可以通过上述信息连接进行信息传输。例如，当数据共享系统中的任意节点接收到输入信息时，数据共享系统中的其他节点便根据共识算法获取该输入信息，将该输入信息作为共享数据中的数据进行存储，使得数据共享系统中全部节点上存储的数据均一致。
[0205]
对于数据共享系统中的每个节点，均具有与其对应的节点标识，而且数据共享系统中的每个节点均可以存储有数据共享系统中其他节点的节点标识，以便后续根据其他节点的节点标识，将生成的区块广播至数据共享系统中的其他节点。每个节点中可维护一个如下表所示的节点标识列表，将节点名称和节点标识对应存储至该节点标识列表中。其中，节点标识可为ip(internet protocol，网络之间互联的协议)地址以及其他任一种能够用于标识该节点的信息，表1中仅以ip地址为例进行说明。
[0206]
表1节点名称与节点标识的对应关系
[0207]
节点名称节点标识节点1117.114.151.174节点2117.116.189.145
……
节点n119.123.789.258
[0208]
数据共享系统中的每个节点均存储一条相同的区块链。区块链由多个区块组成，参见图9b，区块链由多个区块组成，创始块中包括区块头和区块主体，区块头中存储有输入信息特征值、版本号、时间戳和难度值，区块主体中存储有输入信息；创始块的下一区块以创始块为父区块，下一区块中同样包括区块头和区块主体，区块头中存储有当前区块的输入信息特征值、父区块的区块头特征值、版本号、时间戳和难度值，并以此类推，使得区块链中每个区块中存储的区块数据均与父区块中存储的区块数据存在关联，保证了区块中输入信息的安全性。
[0209]
在生成区块链中的各个区块时，参见图9c，区块链所在的节点在接收到输入信息时，对输入信息进行校验，完成校验后，将输入信息存储至内存池中，并更新其用于记录输入信息的哈希树；之后，将更新时间戳更新为接收到输入信息的时间，并尝试不同的随机数，多次进行特征值计算，使得计算得到的特征值可以满足下述公式：
[0210]
sha256(sha256(version+prev_hash+merkle_root+ntime+nbits+x))＜target
[0211]
其中，sha256为计算特征值所用的特征值算法；version(版本号)为区块链中相关区块协议的版本信息；prev_hash为当前区块的父区块的区块头特征值；merkle_root为输入信息的特征值；ntime为更新时间戳的更新时间；nbits为当前难度，在一段时间内为定值，并在超出固定时间段后再次进行确定；x为随机数；target为特征值阈值，该特征值阈值可以根据nbits确定得到。
[0212]
这样，当计算得到满足上述公式的随机数时，便可将信息对应存储，生成区块头和区块主体，得到当前区块。随后，区块链所在节点根据数据共享系统中其他节点的节点标识，将新生成的区块分别发送给其所在的数据共享系统中的其他节点，由其他节点对新生成的区块进行校验，并在完成校验后将新生成的区块添加至其存储的区块链中。
[0213]
以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。