依赖关系的视图生成方法、系统、设备及存储介质与流程

1.本技术涉及大数据的数据展示领域，尤其涉及一种依赖关系的视图生成方法、系统、设备及存储介质。


背景技术：

2.应用系统包括应用程序、it域、业务域，应用程序可以划分到不同it域中，不同it域又属于不同业务域，且应用程序由多个子程序构成，其中，子程序包括：页面、服务实体、数据调用接口等。将子程序、应用程序等可统称为对象，则对象间往往存在复杂的依赖关系，该依赖关系可以是调用关系或从属关系。
3.在开发人员对依赖关系进行维护或修改时，应用系统间复杂的依赖关系不便于开发人员理解，进而降低了开发效率较低。


技术实现要素：

4.本技术提供了一种依赖关系的视图生成方法、系统、设备及计算机可读存储介质，该方法可以通过将对象为节点，依赖关系为边生成第一视图，且获取基于第一视图的第一操作，其中，第一操作用于修改第一视图中的依赖关系，并对该第一操作进行验证，若验证通过，则将生成第二视图，使得依赖关系能通过视图形式展示，便于依赖关系的理解，且能对修改的依赖关系进行验证，提高了维护依赖关系的效率。
5.目标和其他目标将通过独立权利要求中的特征来达成。进一步的实现方式在从属权利要求、说明书和附图中体现。
6.第一方面，本技术提供了一种依赖关系的视图生成方法，其特征在于，包括：根据应用系统中至少一个依赖关系生成第一视图，依赖关系用于指示对象之间的调用关系或从属关系，该对象为应用程序或者子程序；获取基于第一视图的第一操作，第一操作用于修改第一视图中的依赖关系；根据预设规则对第一操作进行验证，预设规则用于指示任意两个对象间能否建立依赖关系；若验证通过，则根据第一视图以及所述第一操作生成第二视图。
7.第二方面，本技术提供了一种一种依赖关系的视图生成系统，包括：生成单元、获取单元以及验证单元：生成单元用于根据应用系统中至少一个依赖关系生成第一视图，所述依赖关系用于指示对象之间的调用关系或从属关系，所述对象为应用程序或者子程序；获取单元用于获取基于所述第一视图的第一操作，所述第一操作用于修改所述第一视图中的依赖关系；验证单元用于根据预设规则对所述第一操作进行验证，所述预设规则用于指示任意两个对象间能否建立依赖关系；生成单元还用于，在验证通过时，根据第一视图以及基于所述第一操作生成第二视图。
8.第三方面，本技术提供了一种计算机设备，其特征在于，包括：处理器和存储器，所述存储器存储有计算机程序，上述处理器执行上述存储器中的计算机程序以实现执行如第一方面所描述的方法。
9.第四方面，本技术提供了一种计算机可读存储介质，所述计算机可读存储介质存
储有计算机程序，其特征在于，当上述计算机程序在计算机上运行时，使得上述计算机执行如第一方面所描述的方法。
10.综上所述，本技术实施例提供的依赖关系的视图生成方法将依赖关系通过视图形式展示，便于依赖关系的理解，且能通过修改视图对依赖关系进行修改，并对修改的依赖关系进行验证，提高了维护依赖关系的效率。
附图说明
11.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍。
12.图1为本技术实施例提供的一种应用系统架构示意图；
13.图2为本技术实施例提供的一种应用程序逻辑架构示意图；
14.图3为本技术实施例提供的一种依赖关系的视图生成方法的流程示意图；
15.图4为本技术实施例提供的一种应用场景下应用程序逻辑架构示意图；
16.图5为本技术实施例提供的一种依赖关系的视图生成系统的结构示意图；
17.图6为本技术实施例提供的一种电子设备结构示意图。
具体实施方式
18.本技术以下实施例中所使用的术语只是为了描述特定实施例的目的，而并非旨在作为对本技术的限制。如在本技术的说明书和所附权利要求书中所使用的那样，单数表达形式“一个”、“一种”、“所述”、“上述”、“该”和“这一”旨在也包括复数表达形式，除非其上下文中明确地有相反指示。还应当理解，本技术中使用的术语“和/或”是指并包含一个或多个所列出项目的任何或所有可能组合。
19.首先，对本技术涉及的应用系统的逻辑架构进行详细介绍。
20.如图1所示，应用系统包括应用程序、互联网技术(internettechnology，it)域、业务域。应用程序可以划分到不同it域中,每个应用程序只属于一个it域，但可以属于多个业务域，且每个业务域中包括多个it域以及多个it域下的应用程序。不同应用程序可以通过消息队列(massagequeue，mq)传输信息。应理解，本技术实施例对业务域的逻辑架构划分不作具体限定。
21.每个应用程序又有不同子程序组成，各个子程序相互依赖实现应用程序的具体功能。下面结合图2对本技术涉及的应用程序的逻辑架构进行详细介绍。如图2所示，应用程序的逻辑架构从上至下依次为表示层、聚合层、业务逻辑层、数据访问层。
22.表示层，又称ui(user interface)层，包括一个或多个应用程序的网页(web页面)，每个web页面需要调用一个或多个聚合层的聚合服务，表示层的主要功能是实现系统数据的传入与输出，可以直接与用户交互，获取用户输入的数据以及将数据展示给用户。具体实现过程为：表示层的页面接收用户的操作，并将用户操作对应的请求发送给聚合层，由聚合层完成处理后，表示层将以web页面形式展示处理结果。
23.聚合层聚合了业务逻辑层提供的服务实体，每个聚合服务都聚合了多个服务实体。聚合层可以接受用户基于表示层发送的操作请求，并向业务逻辑层发送调用命令，将业务逻辑层的服务实体进行关联来实现各种功能。
24.业务逻辑层主要用于为聚合层提供服务实体。一个应用程序的业务逻辑层包括了一个或多个服务实体，每个服务实体都需要通过数据访问层中的调用接口，调用一个或多个数据类型。业务逻辑层接收到聚合层的调用命令后，将对调用命令对应的具体问题进行逻辑判断，将经过逻辑判断后的调用命令发送给数据访问层，由数据访问层实现具体地操作。
25.数据访问层是数据库的主要操控单元，数据访问层包括多个数据类型的调用接口，使用该数据调用接口可以使数据类型被业务逻辑层中的服务实体调用。数据访问层可以接收业务逻辑层经过逻辑处理后的数据的增加、删除、修改、查询等操作，并基于上述操作最数据对象进行修改，并将操作结果反馈到业务逻辑层，进而由业务逻辑层反馈到聚合层，聚合层再将操作结果发送到表示层，由表示层将操作结果以界面形式进行展示。
26.在一些实施例中，应用程序的逻辑架构还可以被划分为接入交互层、产品业务层、业务平台层、公共服务层、技术平台层、运营管理层以及安全运营层等等。应理解，本技术实施例对应用程序的逻辑架构划分不作具体限定。
27.综上所述，应用程序由表示层、聚合层、业务逻辑层、数据访问层等多个层次单元中的多个子程序构成，该子程序包括：页面、服务实体以及数据调用接口等，不同子程序间存在依赖关系，如调用关系。不同应用程序又被划分到不同it域与业务域中，形成应用系统，各个应用程序与it域、业务域间的从属关系也呈复杂的网状关系。因此，将子程序、应用程序等可统称为对象，依赖关系具体可以是应用程序中子程序的远程过程接口调用(remote procedure call，rpc)关系，也可以是业务域、it域与应用程序的从属关系，以及应用程序间mq的订阅与发布关系，即应用程序间mq的生产与消费的关系。
28.由上可知，各个依赖关系存在于不同层级的对象、应用程序之间，整体呈现网状结构，当应用程序功能越多时，应用系统的依赖关系也会越来越复杂，且还存在不同应用程序间相互复用服务实体以及数据调用接口等情况，使得开发人员需要花大量时间分析应用程序的依赖关系，进而，使得应用程序需要添加新的服务实体或新的页面，或者对原有依赖关系进行修改时，开发人员添加或修改依赖关系难度较大，且容易产生错误的依赖关系，降低了开发效率。
29.为了解决应用程序的依赖关系较为复杂，不便于开发人员理解依赖关系，以及基于原有依赖关系进行维护较为困难的问题，本技术提供了一种依赖关系的视图生成方法，通过将应用程序的依赖关系用图结构进行展示，并能获取基于该图结构的修改操作，对该修改操作进行验证，若验证成功将生成新的依赖关系以及新的依赖关系对应的图结构。
30.下面对本技术提供的一种依赖关系的视图生成方法进行详细描述，如图3所示，该依赖关系的视图生成方法可以包括以下步骤：
31.s310、根据应用系统中至少一个依赖关系生成第一视图。
32.具体地，获取对象的依赖关系；以对象作为图结构的节点，依赖关系作为图结构的边构建第一视图；并将第一视图以页面形式进行展示。
33.在一具体实施例中，获取对象的依赖关系，具体包括：通过数据总线的方式从应用系统中获取对象的依赖关系。数据总线可以获取配置管理数据库、配置中心、消息中心等的数据，其中，配置管理数据库中存储有业务域、it域和应用程序的数据信息，配置中心中存储有应用程序的子程序信息，消息中心中存储有应用程序发布和订阅数据的信息；对象可
以为：应用程序、应用程序中的子程序以及业务域、it域；依赖关系可以为：应用程序中子程序的rpc依赖关系、应用程序之间mq的发布与订阅关系、业务域、it域和应用程序的从属关系。
34.在一些实施例中，所述依赖关系还可以为应用程序对硬件部署资源的占用关系、部门与人事对业务域和应用程序的责任关系等。应理解，本技术实施例对依赖关系的类型不作具体限定。
35.下面结合具体实例对以对象作为图结构的节点，依赖关系作为图结构的边构建第一视图进行详细说明。其中，若对象为应用程序的子程序，依赖关系为应用程序中子程序之间的rpc依赖关系，则第一视图以子程序为节点，rpc依赖关系为边；若对象为应用程序，依赖关系为应用程序之间mq的发布与订阅关系，则第一视图中以应用程序为节点，mq的发布与订阅关系为边；若对象为业务域、it域和应用程序，依赖关系为业务域、it域和应用程序之间的从属关系，则第一视图以业务域、it域和应用程序为节点，从属关系为边。
36.下面对以子程序为节点，rpc依赖关系为边对构建的视图进行详细说明。如图4所示，表示层共有用户信息界面mission
‑
web与商品信息界面market
‑
web两个web网页；聚合层中聚合服务market
‑
app为用户信息界面mission
‑
web与商品信息界面market
‑
web两个web网页提供聚合后的服务实体，聚合服务market
‑
app是将业务逻辑层的服务实体list
‑
app以及服务实体user
‑
app聚合在一起，其中，list
‑
app用于提供商品信息服务，user
‑
app用于提供用户信息服务；数据访问层共有list
‑
svc、collect
‑
svc、bank
‑
svc以及user
‑
svc四个数据调用接口，其中，list
‑
svc、collect
‑
svc以及bank
‑
svc为服务实体list
‑
app提供了商品信息等数据对象的调用接口，user
‑
svc为服务实体user
‑
app提供用户信息的数据调用接口。
37.在一具体实施例中，将第一视图以页面形式进行展示，具体包括：第一视图的展示形式可以为环状式、链路式、分层分域式等不同形式。其中，分层分域图采用自适应有向无环图分层算法，示例性地，若第一视图以业务域、it域和应用程序为节点，从属关系为边：则将各个应用程序按所属的it域、业务域等维度进行划分，以调用链上游到下游的顺序进行展示。
38.综上所述，本技术提供的依赖关系的视图生成方法可以获取不同对象的依赖关系，并将对象与依赖关系构建图结构，并以图结构形式进行展示，进而使得复杂的依赖关系变于查看，利于开发人员理解对象间的依赖关系。
39.s320、获取基于所述第一视图的第一操作，根据预设规则对所述第一操作进行验证。
40.具体地，用户可以根据第一视图对对象与依赖关系进行修改，可以在第一视图对应的操作界面上进行添加、删除、移动等操作。获取第一操作后，将根据预设规则对所述操作进行验证，预设规则用于指示任意两个对象间能否建立依赖关系。
41.在一具体实施例中，获取到用户的操作后，将根据预设规则对所述操作进行验证，具体包括：基于对象与依赖关系计算每个对象的依赖深度，并分析第一视图中各个对象的类别；获取到用户的操作后，查找到所述操作对应的依赖关系；根据预设规则判断用户操作对应的新的依赖关系是否合理，其中，预设规则用于指示不同类别间对象间的依赖原则，例如：同一类别间对象是否可以依赖，不同类别对象间是否可以依赖以及最大依赖深度的阈
值，最大依赖深度用于指示经过第一操作后依赖关系中所有对象间的对象个数的最大值。若第一操作对应的两个对象属于同一类别，当预设规则表示两个对象间能建立依赖关系，则验证通过；若两个对象属于不同类别，当预设规则中表示两个对象间能建立依赖关系，且所述最大依赖深度小于阈值，则验证通过。
42.下面对基于对象与依赖关系计算每个对象的依赖深度，并分析第一视图中各个对象的层级进行详细说明。首先，在所有对象中确定第一对象，所述第一对象可以为任一对象，根据其余每个对象与第一对象的距离，确定每个对象的依赖深度；并根据依赖深度将应用系统中的对象进行分类，其中，同一类别的对象的依赖深度相同。举例来说，如图4所示，若将mission
‑
web作为第一对象，则mission
‑
web与market
‑
web的依赖深度为1，market
‑
app的依赖深度为2，list
‑
app与user
‑
app依赖深度为3，list
‑
svc、collect
‑
svc、bank
‑
svc以及user
‑
svc的依赖深度为4。
43.下面结合具体实施例对获取到用户的操作后，将根据预设规则对所述操作进行验证进行举例说明。如图4所示，以子程序为节点，rpc依赖关系为边构建的视图为例，获取到用户基于该视图添加了list
‑
app与user
‑
app之间的依赖关系，则首先基于该视图计算得到该视图最大依赖深度为4，从下至上的数据访问层、业务逻辑层、聚合层、表示层，每个对象属于上述不同层级；根据用户的操作，查找到用户的操作对应业务逻辑层中的list
‑
app与user
‑
app两个对象；再根据预设规则验证该依赖关系是否合理，其中，预设规则包括：上层结构中的子程序可以依赖下层架构中的子程序，但子程序不能跨层级依赖，比如聚合层的子程序不能直接依赖数据访问层的子程序；同层级中的子程序不能相互依赖；最大依赖深度为4；该用户操作对应的依赖关系属于同层级中的子程序相互依赖，则验证不通过，将拦截该用户操作。若添加一个新的对象，并将该对象与数据访问层的对象建立了依赖，则此时最大依赖深度为5，验证也不通过。
44.在一些实施例中，还可以对用户操作对应的依赖关系的验证设置最大验证深度，举例来说，设置最大验证深度为3，在对用户操作对应的依赖关系进行验证后，还验证执行该操作后对应的对象上下三层的对象间依赖关系是否符合预设规则。
45.综上所述，本技术提供的依赖关系的视图生成方法可以让用户直接对依赖关系对应的视图进行添加、删除、移动操作，并通过预设规则验证新的依赖关系是否合理，防止了不合理的依赖关系的产生，提高了系统稳定性。
46.s330、若验证通过，则根据所述第一视图以及所述第一操作生成第二视图。
47.具体地，若在步骤s320中新的依赖关系验证通过，电子设备将根据所述操作生成新的依赖关系，根据第一视图与新的依赖关系将生成第二视图；并根据新的依赖关系生成对应程序代码，所述程序代码用于将新的依赖关系对应的对象之间产生实际的调用。
48.下面对根据新的依赖关系生成对应程序代码举例说明。
49.若第一视图以应用程序为节点，mq的发布与订阅关系为边，根据新的依赖关系生成对应的程序代码为对applicationcontext.xml文件进行操作对应的程序代码，其中，applicationcontext.xml存储有消息中心中应用程序的mq的发布与订阅关系。若用户操作为删除操作，则对应的程序代码就是把对应的factorybean删除，factorybean为调用接口函数，若用户操作为更新操作，则对应的程序代码就是把对应factorybean更新，若用户操作为创建操作，则对应的程序代码就是添加factorybean。程序代码再根据
applicationcontext配置，将java对象初始化，并进行编译。
50.在一些实施例中，修改后的依赖关系对应的第二视图还具备分享功能，可将第二视图分享给其余用户，该分享功能还可支持只读、可编辑等不同管理权限级别。
51.在一些实施例中，若验证不通过，将拒绝基于第一视图的第一操作，并保留第一视图，不对第一视图进行修改。
52.综上所述，本技术提供的依赖关系的视图生成方法可以将对象作为节点，依赖关系作为边生成第一视图，且获取基于第一视图的修改操作，并对该操作进行验证，若验证通过，则将生成第二视图，使得依赖关系能通过视图形式展示，便于依赖关系的理解，且能通过修改视图对依赖关系进行修改，提高了维护依赖关系的效率。
53.为了解决应用程序的依赖关系较为复杂，不便于开发人员理解依赖关系，以及基于原有依赖关系进行维护较为困难的问题，本技术提供了一种依赖关系的视图生成系统500，如图5所示，该依赖关系的视图生成系统500包括：生成单元510、获取单元520以及验证单元530：
54.生成单元510用于根据应用系统中至少一个依赖关系生成第一视图，依赖关系用于指示对象之间的调用关系或从属关系，对象为应用程序或者子程序。
55.获取单元520用于获取基于第一视图的第一操作，第一操作用于修改所述第一视图中的依赖关系。
56.验证单元530用于根据预设规则对第一操作进行验证，预设规则用于指示任意两个对象间能否建立依赖关系；
57.生成单元510还用于在验证通过时，根据第一视图以及基于第一操作生成第二视图。
58.在一些实施例中，生成单元510还用于根据第一操作生成第一操作对应的程序代码，程序代码在运行时执行第一操作。
59.在一些实施例中，获取单元520还用于在应用系统中的对象中确定第一对象；根据依赖关系，获得每个对象的依赖深度，每个对象的依赖深度为每个对象与第一对象的距离；并根依赖深度将用系统中的对象进行分类，得到多个类别，其中，同一类别的对象的依赖深度相同，多个类别用于预设规则对第一操作关联进行验证。
60.在一些实施例中，验证单元530还用于获取第一操作关联的两个对象；若两个对象属于同一类别，根据同一类别的对象对应的预设规则，对第一操作进行验证；若两个对象属于不同类别，根据不同类别的对象对应的预设规则，对第一操作进行验证。
61.在一些实施例中，验证单元530还用于在第一操作关联的两个对象属于不同类别时，在根据不同类别的对象对应的预设规则，对第一操作进行验证之后，根据依赖关系以及第一操作，获得依赖关系的最大依赖深度，最大依赖深度用于指示依赖关系中对象间的最远的距离；根据预设规则对最大依赖深度进行验证。
62.在一些实施例中，生成单元510还用于根据应用系统中至少一个依赖关系生成图结构，该图结构中的节点为对象，该图结构中的边为依赖关系；根据图结构生成第一视图。
63.在一些实施例中，验证单元530还用于在若验证不通过时，拒绝基于第一视图的操作且保留第一视图。
64.综上所述，本技术提供的依赖关系的视图生成系统500可以将对象作为节点，依赖
关系作为边生成第一视图，且获取基于第一视图的修改操作，并对该操作进行验证，若验证通过，则将生成第二视图，使得依赖关系能通过视图形式展示，便于依赖关系的理解，且能通过修改视图对依赖关系进行修改，提高了维护依赖关系的效率。
65.参见图6，图6为本技术实施例提供的一种电子设备的结构示意图。其中，所述电子设备600可以是前述内容中的依赖关系的视图生成系统500。如图6所示，电子设备600包括：处理器610、通信接口620以及存储器630，所示处理器610、通信接口620以及存储器630通过内部总线640相互连接。
66.处理器610、通信接口620和存储器630可通过总线方式连接，也可通过无线传输等其他手段实现通信。本技术实施例以通过总线640连接为例，其中，总线640可以是外设部件互连标准(peripheral component interconnect,pci)总线或扩展工业标准结构(extended industry standard architecture,eisa)总线等。所述总线640可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
67.所述处理器610可以由一个或者多个通用处理器构成，例如中央处理器(central processing unit，cpu)，或者cpu和硬件芯片的组合。上述硬件芯片可以是专用集成电路(application
‑
specific inegrated circuit，asic)、可编程逻辑器件(programmable logic device，pld)或其组合。上述pld可以是复杂可编程逻辑器件(complex programmable logic device，cpld)、现场可编程逻辑门阵列(field
‑
programmable gate array，fpga)、通用阵列逻辑(generic array logic，gal)或其任意组合。处理器610执行各种类型的数字存储指令，例如存储在存储器630中的软件或者固件程序，它能使电子设备600提供较宽的多种服务。
68.具体地，所述处理器610可以由至少一个通用处理器构成，例如中央处理器(central processing unit，cpu)，或者cpu和硬件芯片的组合。上述硬件芯片可以是专用集成电路(application
‑
specific integrated circuit，asic)、可编程逻辑器件(programmable logic device，pld)或其组合。上述pld可以是复杂可编程逻辑器件(complex programmable logic device，cpld)、现场可编程逻辑门阵列(field
‑
programmable gate array，fpga)、通用阵列逻辑(generic array logic，gal)或其任意组合。处理器610执行各种类型的数字存储指令，例如存储在存储器630中的软件或者固件程序，它能使电子设备600提供较宽的多种服务。
69.存储器630可以包括易失性存储器(volatile memory)，例如随机存取存储器(random access memory，ram)；存储器630也可以包括非易失性存储器(non
‑
volatile memory)，例如只读存储器(read
‑
only memory，rom)、快闪存储器(flash memory)、硬盘(hard disk drive，hdd)或固态硬盘(solid
‑
state drive，ssd)；存储器630还可以包括上述种类的组合。其中，存储器630可以存储有应用程序代码以及程序数据。程序代码可以通过将对象为节点，依赖关系为边生成第一视图，且获取基于第一视图的第一操作，其中，第一操作用于修改第一视图中的依赖关系，并对该第一操作进行验证，若验证通过，则将生成第二视图等等。还可以用于执行图3实施例描述的其他步骤，这里不再进行赘述。所述存储器630的代码可以包括实现生成单元、获取单元以及验证单元功能的代码，生成单元的功能包括图5中的生成单元510的功能，例如根据应用系统中至少一个依赖关系生成第一视图，
所述依赖关系用于指示对象之间的调用关系或从属关系，所述对象为应用程序或者子程序，具体可用于执行前述方法的步骤s310、步骤s330及其可选步骤，这里不再进行赘述。获取单元的功能包括图5中的获取单元520的功能，例如获取基于所述第一视图的第一操作，所述第一操作用于修改所述第一视图中的依赖关系，具体可用于执行前述方法的步骤s320及其可选步骤，这里不再进行赘述。验证单元的功能包括图5中的验证单元530的功能，例如根据预设规则对所述第一操作进行验证，所述预设规则用于指示任意两个对象间能否建立依赖关系，具体可用于执行前述方法的步骤s320及其可选步骤，这里不再进行赘述。
70.通信接口620可以为有线接口(例如以太网接口)，可以为内部接口(例如高速串行计算机扩展总线(peripheral component interconnect express,pcie)总线接口)、有线接口(例如以太网接口)或无线接口(例如蜂窝网络接口或使用无线局域网接口)，用于与与其他设备或模块进行通信。
71.需要说明的，图6仅仅是本技术实施例的一种可能的实现方式，实际应用中，所述电子设备还可以包括更多或更少的部件，这里不作限制。关于本技术实施例中未示出或未描述的内容，可参见前述图3所述实施例中的相关阐述，这里不再赘述。图6示的电子设备还可以是多个计算节点构成的计算机集群，本技术不作具体限定。
72.本技术实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在处理器上运行时，图3所示的方法流程得以实现。
73.本技术实施例还提供一种计算机程序产品，当所述计算机程序产品在处理器上运行时，图3所示的方法流程得以实现。
74.上述实施例，可以全部或部分地通过软件、硬件、固件或其他任意组合来实现。当使用软件实现时，上述实施例可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载或执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以为通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line,dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集合的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，高密度数字视频光盘(digital video disc,dvd)、或者半导体介质。半导体介质可以是ssd。
75.以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。