分布式Dubbo系统的服务调用方法及装置

技术领域

本发明涉及计算机技术领域，尤其涉及一种分布式Dubbo系统的服务调用方法及装置。

背景技术

在分布式系统中，消费端服务调用都采用RPC(Remote Procedure CallProtocol,远程过程调用协议)框架进行，业界流行的RPC框架主要有Dubbo和Spring Cloud等。而Dubbo在业界中使用更广泛。在Dubbo实现中，多个提供端共用一个消费端线程池，当一个提供端下线时，线程池随之关闭。当消费端继续调用其他提供端时，需要再重新建立线程池，从而导致一个线程池在反复的关闭和重建，容易造成内存溢出问题。

发明内容

本发明的一个目的在于提供一种分布式Dubbo系统的服务调用方法，解决基于分布式Dubbo系统的服务调用易造成内存溢出的问题。本发明的另一个目的在于提供一种分布式Dubbo系统的服务调用装置。本发明的再一个目的在于提供一种计算机设备。本发明的还一个目的在于提供一种可读介质。

为了达到以上目的，本发明一方面公开了一种分布式Dubbo系统的服务调用方法，包括：

当服务提供端停止提供服务时，获取所有能够提供服务的存活提供端的提供端信息；

根据所述存活提供端的提供端信息确定是否存在与线程池设置信息中的方法类型对应的存活提供端，所述线程池设置信息包括线程池信息及对应的方法类型；

若是，保留所述线程池，若否，关闭所述线程池。

优选的，进一步包括预先形成所述线程池设置信息的步骤：

获取服务提供端的提供端信息；

根据所述提供端信息确定所述提供端提供的服务对应的方法类型；

建立用于所述提供端获取待处理任务的线程池，并将所述线程池的线程池信息与所述服务提供端的方法类型对应形成线程池设置信息。

优选的，所述建立用于所述提供端获取待处理任务的线程池具体包括：

当调用服务提供端的服务时，调用wrap Channel Handler程序，建立名称为DubboClient Handler，类型为cache的线程池，所述线程池信息包括线程池的名称和类型；

通过所述wrap Channel Handler程序将所述线程池信息发送至所述提供端。

优选的，进一步包括：

若存在与线程池设置信息中的方法类型对应的存活提供端，从所述存活提供端中重新确定服务提供端；

将所述线程池与所述服务提供端连接以使所述服务提供端从所述线程池获取待处理的任务。

优选的，所述将所述线程池与所述服务提供端连接具体包括：

通过wrap Channel Handler程序将保留的所述线程池的线程池信息发送至所述服务提供端。

优选的，所述根据所述存活提供端的提供端信息确定是否存在与线程池设置信息中的方法类型对应的存活提供端进一步包括：

根据所述存活提供端的提供端信息确定各存活提供端提供服务对应的方法类型；

将所述存活提供端的方法类型与所述线程池设置信息中的方法类型进行比对；

若比对一致，确定存在与线程池设置信息中的方法类型对应的存活提供端。

本发明还公开了一种分布式Dubbo系统的服务调用装置，包括：

信息获取模块，用于当服务提供端停止提供服务时，获取所有能够提供服务的存活提供端的提供端信息；

信息分析模块，用于根据所述存活提供端的提供端信息确定是否存在与线程池设置信息中的方法类型对应的存活提供端，所述线程池设置信息包括线程池信息及对应的方法类型，若是，保留所述线程池，若否，关闭所述线程池。

优选的，进一步包括信息预设模块，用于预先获取服务提供端的提供端信息；根据所述提供端信息确定所述提供端提供的服务对应的方法类型；建立用于所述提供端获取待处理任务的线程池，并将所述线程池的线程池信息与所述服务提供端的方法类型对应形成线程池设置信息。

本发明还公开了一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，

所述处理器执行所述程序时实现如上所述方法。

本发明还公开了一种计算机可读介质，其上存储有计算机程序，

该程序被处理器执行时实现如上所述方法。

在本发明的服务调用方法中，当提供服务的服务提供端停止提供服务时，获取其他可以提供服务的存活提供端。然后，分析存活提供端中是否存在提供的服务的方法类型与停止提供服务的服务提供端对应的方法类型相同的存活提供端。若不存在，将该线程池关闭。若存在，保留已建立的线程池以备更换调用其他提供端的服务时直接使用该保留的线程池。本发明解决了分布式Dubbo系统的服务调用中由于提供端下线停止提供服务时线程池随之关闭而导致的服务调用中线程池不断的关闭与新建的问题，提高分布式Dubbo系统的服务调用效率，节约了分布式Dubbo系统服务框架的系统资源。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出现有技术中分布式Dubbo系统的示意图；

图2示出本发明分布式Dubbo系统的服务调用方法一个具体实施例的流程图；

图3示出本发明分布式Dubbo系统的服务调用方法一个具体实施例S000的流程图；

图4示出本发明分布式Dubbo系统的服务调用方法一个具体实施例S030的流程图；

图5示出本发明分布式Dubbo系统的服务调用方法一个具体实施例S400的流程图；

图6示出本发明分布式Dubbo系统的服务调用装置一个具体实施例的结构图；

图7示出本发明分布式Dubbo系统的服务调用装置一个具体实施例包括信息预设模块的结构图；

图8示出适于用来实现本发明实施例的计算机设备的结构示意图。

具体实施方式

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

现有技术中，分布式Dubbo系统的消费端将接收的任务传输给服务提供端进行任务处理。具体的，消费端在调用提供端时即新建一个线程池，将任务传输至该线程池中进行排队，然后服务提供端可从线程池中获取各任务进行处理。对于一个默认配置的消费端，在消费端运行一段时间之后，即会形成一个具有n个线程的Fixed Thread Pool线程池。其中，n依赖于提供端的不同端口数量，可通过Set(provider.getPort()).size()命令实现提供端端口数量的采集。然而，对于不同的提供端，消费端会通过一个Map表共用线程池，表中存储了线程池信息。该线程池信息包括不同提供端的端口和线程池信息。而对于提供相同服务的服务提供端，其提供的服务的方法类型可能相同，从而多个服务提供端的端口可能全部相同。在多个端口完全相同的服务提供端共用一个线程池获取任务时，其中一个提供端下线即会调用AbstractClient.close()命令将线程池关闭。然后，消费端在继续调用其他端口完全相同的提供端时，则需要重新建立一个相同的线程池。

具体的，消费端初始化线程池的时候会设置线程池的名字和类型，默认名字为Dubbo Client Handler，类型为cache，得到Cached Thread Pool线程池。实际上，消费端初始化线程池的时机在处理连接或响应之前，在处理连接或响应的url中(调用wrap ChannelHandler程序)并没有cache参数，所以对于同一个端口，最开始会是一个名为Dubbo ClientHandler的Cached Thread Pool。但是因为一台提供端(provider)下线就会导致这个线程池被关闭。然后消费端继续调用提供端，这时候会调用wrap Channel Handler程序中的方法，因为原线程池被关闭，会直接创建一个线程池，但是因为url中没有设置过cache，重建的线程池会是一个名称为Dubbo的Fixed Thread Pool线程池。并且这个Fixed ThreadPool线程池会一直随着提供端下线和调用被关闭和重建。

由此，随着多个端口完全相同的提供端中的下线，消费端完全相同的线程池需要关闭再重建，可能会导致消费端内存溢出问题，严重的影响了服务调用的效率并浪费了系统资源。本发明通过对线程池的构建过程进行改进，避免了分布式Dubbo系统的服务调用中由于提供端下线停止提供服务时线程池随之关闭而导致的服务调用中线程池不断的关闭与新建的现象，提高分布式Dubbo系统的服务调用效率，节约了分布式Dubbo系统服务框架的系统资源。

图1示出了本发明分布式Dubbo系统的结构示意图。分布式Dubbo系统包括注册中心、消费端和提供端。

其中，提供端可向消费端提供任务处理的服务，提供端预先向注册中心发送提供端信息，以使注册中心确定该提供端为可以提供服务的服务提供端。当消费端接收到待处理的任务时，从注册中心获取可提供服务的服务提供端。建立线程池，将待处理的任务传输至线程池中以使对应的服务提供端可从线程池中获取任务进行处理。目前，消费端在建立线程池时，采用根据提供端的端口和线程池信息作为线程池设置信息。则当提供端下线停止服务时，线程池会随之关闭。当再调用提供同样服务的提供端进行任务处理时，又要新建同样的线程池，导致服务调用的效率低以及服务资源的浪费，进而可能导致消费端内存溢出。

下面以消费端作为执行主体为例，说明本发明实施例提供的分布式Dubbo系统的服务调用方法的实现过程。可理解的是，本发明实施例提供的分布式Dubbo系统的服务调用方法的执行主体包括但不限于消费端。

根据本发明的一个方面，本实施例公开了一种分布式Dubbo系统的服务调用方法。如图2所示，本实施例中，所述方法包括：

S100：当服务提供端停止提供服务时，获取所有能够提供服务的存活提供端的提供端信息。

S200：根据所述存活提供端的提供端信息确定是否存在与线程池设置信息中的方法类型对应的存活提供端，所述线程池设置信息包括线程池信息及对应的方法类型。

S300：若是，保留所述线程池，若否，关闭所述线程池。

在本发明的服务调用方法中，当提供服务的服务提供端停止提供服务时，获取其他可以提供服务的存活提供端。然后，分析存活提供端中是否存在提供的服务的方法类型与停止提供服务的服务提供端对应的方法类型相同的存活提供端。若不存在，将该线程池关闭。若存在，保留已建立的线程池以备更换调用其他提供端的服务时直接使用该保留的线程池。本发明解决了分布式Dubbo系统的服务调用中由于提供端下线停止提供服务时线程池随之关闭而导致的服务调用中线程池不断的关闭与新建的问题，提高分布式Dubbo系统的服务调用效率，节约了分布式Dubbo系统服务框架的系统资源。

在优选的实施方式中，如图3所示，所述方法进一步包括预先形成所述线程池设置信息的步骤S000：

S010：获取服务提供端的提供端信息。

S020：根据所述提供端信息确定所述提供端提供的服务对应的方法类型。

S030：建立用于所述提供端获取待处理任务的线程池，并将所述线程池的线程池信息与所述服务提供端的方法类型对应形成线程池设置信息。

具体的，消费端可从注册中心获取所有已注册的服务提供端的提供端信息，根据提供端信息确定各服务提供端可提供的服务的方法类型。该提供端信息还可包括服务提供端的访问地址、服务器名称以及端口等信息。通过服务调用命令访问服务提供端进行任务处理时，会初始化建立一个线程池。可将该线程池的线程池信息与服务提供端提供的服务的方法类型对应形成线程池设置信息。其中，线程池信息可包括新建的线程池的名称和类型等信息。

由此，在优选的实施方式中，所述S200根据所述存活提供端的提供端信息确定是否存在与线程池设置信息中的方法类型对应的存活提供端进一步包括：

S210：根据所述存活提供端的提供端信息确定各存活提供端提供服务对应的方法类型。

S220：将所述存活提供端的方法类型与所述线程池设置信息中的方法类型进行比对。

S230：若比对一致，确定存在与线程池设置信息中的方法类型对应的存活提供端。

具体的，在当前提供服务的服务提供端下线停止服务时，通过注册中心获取其他的存活提供端的提供端信息，确定其他已注册的存活提供端可提供的服务的方法类型是否与当前服务提供端提供的服务的方法类型相同。若相同，表示所有可用的存活提供端中存在可替代的提供端，保留已建立的线程池，然后根据替代的存活提供端的提供端信息调用该存活提供端进行任务处理。在调用存活提供端时，可直接将之前保留的线程池与存活提供端连接，而无需在调用过程中重新建立一个新的线程池，从而可极大提高服务调用的效率和服务提供端变更的灵活性。

在优选的实施方式中，如图4所示，所述S030建立用于所述提供端获取待处理任务的线程池具体包括：

S031：当调用服务提供端的服务时，调用wrap Channel Handler程序，建立名称为Dubbo Client Handler，类型为cache的线程池，所述线程池信息包括线程池的名称和类型。

S032：通过所述wrap Channel Handler程序将所述线程池信息发送至所述提供端。

具体的，消费端初始化线程池的时候会设置线程池的名称和类型，默认名字为Dubbo Client Handler，类型为cache，得到Cached Thread Pool线程池。实际上，消费端初始化线程池的时机在处理连接或响应之前，在处理连接或响应的url中(调用wrap ChannelHandler程序)并没有cache参数，所以对于同一个端口，最开始会是一个名为Dubbo ClientHandler的Cached Thread Pool。通过调用命令wrap Channel Handler程序可访问提供端并将线程池信息传输至提供端，以便于提供端根据线程池信息访问线程池，并从线程池中获取任务进行处理。

在优选的实施方式中，如图5所示，所述方法进一步包括S400：

S410：若存在与线程池设置信息中的方法类型对应的存活提供端，从所述存活提供端中重新确定服务提供端。

S420：将所述线程池与所述服务提供端连接以使所述服务提供端从所述线程池获取待处理的任务。

具体的，当一个服务提供端下线停止服务时，并不调用命令将服务提供端对应的线程池随之关闭，需要确定注册中心中可提供服务的存活提供端中是否存在替代的提供端。若存在，仅需更改调用的提供端，使替换后的存活提供端从保留的线程池中获取任务进行处理，避免了同一个线程池随着服务提供端下线和更改调用时的反复关闭和建立现象。

在优选的实施方式中，所述S420将所述线程池与所述服务提供端连接具体包括：

S411：通过wrap Channel Handler程序将保留的所述线程池的线程池信息发送至所述服务提供端。

具体的，现有技术中，消费端初始化线程池的时候会设置线程池的名字和类型，默认名字为Dubbo Client Handler，类型为cache，得到Cached Thread Pool线程池。实际上，消费端初始化线程池的时机在处理连接或响应之前，在处理连接或响应的url中(调用wrapChannel Handler程序)并没有cache参数，所以对于同一个端口，最开始会是一个名为Dubbo Client Handler的Cached Thread Pool。但是因为一台提供端(provider)下线就会导致这个线程池被关闭。然后消费端继续调用提供端，这时候会调用wrap ChannelHandler程序中的方法，因为原线程池被关闭，会直接创建一个线程池，但是因为url中没有设置过cache，重建的线程池会是一个名称为Dubbo的Fixed Thread Pool线程池。并且这个Fixed Thread Pool线程池会一直随着提供端下线和调用被关闭和重建。在该优选的实施方式中，在服务提供端下线时，Fixed Thread Pool线程池不会随着提供端的下线而关闭。当重新确定可用的存活提供端后，仅需通过wrap Channel Handler程序调用命令将该Fixed Thread Pool的线程池信息传输至重新确定的服务提供端即可，无需再重新初始化建立线程池。

在本发明的服务调用方法中，当提供服务的服务提供端停止提供服务时，获取其他可以提供服务的存活提供端。然后，分析存活提供端中是否存在提供的服务的方法类型与停止提供服务的服务提供端对应的方法类型相同的存活提供端。若不存在，将该线程池关闭。若存在，保留已建立的线程池以备更换调用其他提供端的服务时直接使用该保留的线程池。本发明解决了分布式Dubbo系统的服务调用中由于提供端下线停止提供服务时线程池随之关闭而导致的服务调用中线程池不断的关闭与新建的问题，解决了提供端频繁上线下线时会造成的资源消耗，提高分布式Dubbo系统的服务调用效率，节约了分布式Dubbo系统服务框架的系统资源。

基于相同原理，本实施例还公开了一种分布式Dubbo系统的服务调用装置。如图6所示，本实施例中，所述装置包括信息获取模块11和信息分析模块12。

其中，信息获取模块11用于当服务提供端停止提供服务时，获取所有能够提供服务的存活提供端的提供端信息。

信息分析模块12用于根据所述存活提供端的提供端信息确定是否存在与线程池设置信息中的方法类型对应的存活提供端，所述线程池设置信息包括线程池信息及对应的方法类型，若是，保留所述线程池，若否，关闭所述线程池。

在本发明的服务调用方法中，当提供服务的服务提供端停止提供服务时，获取其他可以提供服务的存活提供端。然后，分析存活提供端中是否存在提供的服务的方法类型与停止提供服务的服务提供端对应的方法类型相同的存活提供端。若不存在，将该线程池关闭。若存在，保留已建立的线程池以备更换调用其他提供端的服务时直接使用该保留的线程池。本发明解决了分布式Dubbo系统的服务调用中由于提供端下线停止提供服务时线程池随之关闭而导致的服务调用中线程池不断的关闭与新建的问题，提高分布式Dubbo系统的服务调用效率，节约了分布式Dubbo系统服务框架的系统资源。

在优选的实施方式中，如图7所示，所述装置进一步包括信息预设模块10。信息预设模块10用于预先获取服务提供端的提供端信息；根据所述提供端信息确定所述提供端提供的服务对应的方法类型；建立用于所述提供端获取待处理任务的线程池，并将所述线程池的线程池信息与所述服务提供端的方法类型对应形成线程池设置信息。

具体的，消费端可从注册中心获取所有已注册的服务提供端的提供端信息，根据提供端信息确定各服务提供端可提供的服务的方法类型。该提供端信息还可包括服务提供端的访问地址、服务器名称以及端口等信息。通过服务调用命令访问服务提供端进行任务处理时，会初始化建立一个线程池。可将该线程池的线程池信息与服务提供端提供的服务的方法类型对应形成线程池设置信息。其中，线程池信息可包括新建的线程池的名称和类型等信息。

由此，在当前提供服务的服务提供端下线停止服务时，通过注册中心获取其他的存活提供端的提供端信息，确定其他已注册的存活提供端可提供的服务的方法类型是否与当前服务提供端提供的服务的方法类型相同。若相同，表示所有可用的存活提供端中存在可替代的提供端，保留已建立的线程池，然后根据替代的存活提供端的提供端信息调用该存活提供端进行任务处理。在调用存活提供端时，可直接将之前保留的线程池与存活提供端连接，而无需在调用过程中重新建立一个新的线程池，从而可极大提高服务调用的效率和服务提供端变更的灵活性。

在优选的实施方式中，所述信息预设模块10具体用于当调用服务提供端的服务时，调用wrap Channel Handler程序，建立名称为Dubbo Client Handler，类型为cache的线程池，所述线程池信息包括线程池的名称和类型。通过所述wrap Channel Handler程序将所述线程池信息发送至所述提供端。

具体的，消费端初始化线程池的时候会设置线程池的名称和类型，默认名字为Dubbo Client Handler，类型为cache，得到Cached Thread Pool线程池。实际上，消费端初始化线程池的时机在处理连接或响应之前，在处理连接或响应的url中(调用wrap ChannelHandler程序)并没有cache参数，所以对于同一个端口，最开始会是一个名为Dubbo ClientHandler的Cached Thread Pool。通过调用命令wrap Channel Handler程序可访问提供端并将线程池信息传输至提供端，以便于提供端根据线程池信息访问线程池，并从线程池中获取任务进行处理。

在优选的实施方式中，所述信息分析模块12进一步用于若存在与线程池设置信息中的方法类型对应的存活提供端，从所述存活提供端中重新确定服务提供端。将所述线程池与所述服务提供端连接以使所述服务提供端从所述线程池获取待处理的任务。

具体的，当一个服务提供端下线停止服务时，并不调用命令将服务提供端对应的线程池随之关闭，需要确定注册中心中可提供服务的存活提供端中是否存在替代的提供端。若存在，仅需更改调用的提供端，使替换后的存活提供端从保留的线程池中获取任务进行处理，避免了同一个线程池随着服务提供端下线和更改调用时的反复关闭和建立现象。

在优选的实施方式中，所述信息分析模块12具体用于通过wrap Channel Handler程序将保留的所述线程池的线程池信息发送至所述服务提供端。

具体的，现有技术中，消费端初始化线程池的时候会设置线程池的名字和类型，默认名字为Dubbo Client Handler，类型为cache，得到Cached Thread Pool线程池。实际上，消费端初始化线程池的时机在处理连接或响应之前，在处理连接或响应的url中(调用wrapChannel Handler程序)并没有cache参数，所以对于同一个端口，最开始会是一个名为Dubbo Client Handler的Cached Thread Pool。但是因为一台提供端(provider)下线就会导致这个线程池被关闭。然后消费端继续调用提供端，这时候会调用wrap ChannelHandler程序中的方法，因为原线程池被关闭，会直接创建一个线程池，但是因为url中没有设置过cache，重建的线程池会是一个名称为Dubbo的Fixed Thread Pool线程池。并且这个Fixed Thread Pool线程池会一直随着提供端下线和调用被关闭和重建。在该优选的实施方式中，在服务提供端下线时，Fixed Thread Pool线程池不会随着提供端的下线而关闭。当重新确定可用的存活提供端后，仅需通过wrap Channel Handler程序调用命令将该Fixed Thread Pool的线程池信息传输至重新确定的服务提供端即可，无需再重新初始化建立线程池。

由于该装置解决问题的原理与以上方法类似，因此本装置的实施可以参见方法的实施，在此不再赘述。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机设备，具体的，计算机设备例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

在一个典型的实例中计算机设备具体包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上所述的由客户端执行的方法，或者，所述处理器执行所述程序时实现如上所述的由服务器执行的方法。

下面参考图8，其示出了适于用来实现本申请实施例的计算机设备600的结构示意图。

如图8所示，计算机设备600包括中央处理单元(CPU)601，其可以根据存储在只读存储器(ROM)602中的程序或者从存储部分608加载到随机访问存储器(RAM))603中的程序而执行各种适当的工作和处理。在RAM603中，还存储有系统600操作所需的各种程序和数据。CPU601、ROM602、以及RAM603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线604。

以下部件连接至I/O接口605：包括键盘、鼠标等的输入部分606；包括诸如阴极射线管(CRT)、液晶反馈器(LCD)等以及扬声器等的输出部分607；包括硬盘等的存储部分608；以及包括诸如LAN卡，调制解调器等的网络接口卡的通信部分609。通信部分609经由诸如因特网的网络执行通信处理。驱动器610也根据需要连接至I/O接口605。可拆卸介质611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器610上，以便于从其上读出的计算机程序根据需要被安装如存储部分608。

特别地，根据本发明的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明的实施例包括一种计算机程序产品，其包括有形地包含在机器可读介质上的计算机程序，所述计算机程序包括用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分609从网络上被下载和安装，和/或从可拆卸介质611被安装。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

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

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。