微服务集群中更新通知方法及装置

技术领域

本发明涉及微服务集群技术领域，尤指一种微服务集群中更新通知方法及装置。

背景技术

目前的分布式微服务集群大多通过RPC框架通信，主流的RPC框架都基于注册中心做服务发现，以广泛使用的Dubbo框架为例，它最常使用的注册中心为Zookeeper。

当集群规模较大时，Consumer的数量可能高达数千甚至数万个，当Provider发生数据更新时，ZooKeeper借助Watch机制将数据变更通知给Consumer。Consumer集群几乎同时收到Zookeeper推送过来的数据变更通知，然后又同时向Provider发起建立TCP连接的请求，给Provider和集群网络带来很大压力，极易引发连接风暴，影响业务交易的成功率。

发明内容

针对现有技术中存在的问题，本发明实施例的主要目的在于提供一种微服务集群中更新通知方法及装置，实现简单且实施成本低的数据更新通知，能够有效减少微服务集群连接风暴。

为了实现上述目的，本发明实施例提供一种微服务集群中更新通知方法，所述方法包括：

根据从服务端接收到的数据更新信息，生成数据更新通知，并根据所述数据更新信息，确定与所述数据更新信息对应的订阅者集合；

根据预设的分批通知数量以及所述订阅者集合中的订阅者个数，确定每批通知订阅者数量；

根据预设的分批间隔时长以及所述每批通知订阅者数量，向所述订阅者集合中各订阅者发送所述数据更新通知。

可选的，在本发明一实施例中，所述根据从服务端接收到的数据更新信息，生成数据更新通知，并根据所述数据更新信息，确定与所述数据更新信息对应的订阅者集合包括：

根据所述服务端的ip地址、端口号及时间戳，从所述服务端接收数据更新信息；其中，所述数据更新信息包括服务名及版本号；

根据所述服务名及所述版本号，生成所述数据更新通知，并确定与所述服务名对应的订阅者集合。

可选的，在本发明一实施例中，所述根据预设的分批通知数量以及所述订阅者集合中的订阅者个数，确定每批通知订阅者数量包括：

计算所述订阅者集合中的订阅者个数与预设的分批通知数量的比值，将所述比值作为所述每批通知订阅者数量。

可选的，在本发明一实施例中，所述根据预设的分批间隔时长以及所述每批通知订阅者数量，向所述订阅者集合中各订阅者发送所述数据更新通知包括：

对所述订阅者集合中的订阅者进行随机排序，从随机排序后的订阅者中顺序选取N个第一批订阅者，并向所述第一批订阅者发送所述数据更新通知；其中，N等于所述每批通知订阅者数量；

在等待所述分批间隔时长后，从除去所述第一批订阅者后的订阅者集合中，顺序选取N个第二批订阅者进行数据更新通知发送，直至完成向所述订阅者集合中所有订阅者数据更新通知发送。

本发明实施例还提供一种微服务集群中更新通知装置，所述装置包括：

订阅者集合模块，用于根据从服务端接收到的数据更新信息，生成数据更新通知，并根据所述数据更新信息，确定与所述数据更新信息对应的订阅者集合；

通知数量模块，用于根据预设的分批通知数量以及所述订阅者集合中的订阅者个数，确定每批通知订阅者数量；

更新通知模块，用于根据预设的分批间隔时长以及所述每批通知订阅者数量，向所述订阅者集合中各订阅者发送所述数据更新通知。

可选的，在本发明一实施例中，所述订阅者集合模块包括：

更新信息单元，用于根据所述服务端的ip地址、端口号及时间戳，从所述服务端接收数据更新信息；其中，所述数据更新信息包括服务名及版本号；

订阅者集合单元，用于根据所述服务名及所述版本号，生成所述数据更新通知，并确定与所述服务名对应的订阅者集合。

可选的，在本发明一实施例中，所述通知数量模块还用于计算所述订阅者集合中的订阅者个数与预设的分批通知数量的比值，将所述比值作为所述每批通知订阅者数量。

可选的，在本发明一实施例中，所述更新通知模块包括：

随机排序单元，用于对所述订阅者集合中的订阅者进行随机排序，从随机排序后的订阅者中顺序选取N个第一批订阅者，并向所述第一批订阅者发送所述数据更新通知；其中，N等于所述每批通知订阅者数量；

通知发送单元，用于在等待所述分批间隔时长后，从除去所述第一批订阅者后的订阅者集合中，顺序选取N个第二批订阅者进行数据更新通知发送，直至完成向所述订阅者集合中所有订阅者数据更新通知发送。

本发明还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法。

本发明还提供一种计算机可读存储介质，所述计算机可读存储介质存储有执行上述方法的计算机程序。

本发明通过确定订阅者集合进行分批通知的方式，可以有效避免服务端在数据更新后，立即处理大量来自消费方的建连请求，有效降低服务端的TCP队列溢出次数和CPU的使用率，保证业务交易的平稳。

附图说明

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

图1为本发明实施例一种微服务集群中更新通知方法的流程图；

图2为本发明实施例中确定订阅者集合的流程图；

图3为本发明实施例中方送数据更新通知的流程图；

图4为本发明实施例中Dubbo集群架构示意图；

图5为本发明实施例中更新通知的流程图；

图6为本发明实施例中分批通知的流程图；

图7为本发明一具体实施例中微服务集群架构示意图；

图8为本发明实施例一种微服务集群中更新通知装置的结构示意图；

图9为本发明实施例中订阅者集合模块的结构示意图；

图10为本发明实施例中更新通知模块的结构示意图；

图11为本发明一实施例所提供的电子设备的结构示意图。

具体实施方式

本发明实施例提供一种微服务集群中更新通知方法及装置，可用于金融领域或其他领域，需要说明的是，本发明的微服务集群中更新通知方法及装置可用于金融领域，也可用于除金融领域之外的任意领域，本发明的微服务集群中更新通知方法及装置应用领域不做限定。

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

如图1所示为本发明实施例一种微服务集群中更新通知方法的流程图，本发明实施例提供的微服务集群中更新通知方法的执行主体包括但不限于Dubbo中的注册中心。图中所示方法包括：

步骤S1，根据从服务端接收到的数据更新信息，生成数据更新通知，并根据所述数据更新信息，确定与所述数据更新信息对应的订阅者集合。

其中，本发明采用Dubbo集群架构，Dubbo为广泛使用的分布式远程调用框架。具体的，注册中心(Registry)由zooKeeper实现，业界广泛使用的分布式的、开源的分布式应用协调服务，它可以在分布式系统中充当配置中心、分布式锁、服务发现中心等角色。Dubbo框架默认就是以zookeeper做服务发现的。服务端为暴露服务的服务提供方(Provider)，接收注册中心发送的数据更新通知的为调用远程服务的服务消费方(Consumer)。

进一步的，在服务端启动时，会出现数据更新。此时，注册中心会通过服务端的ip地址、端口号、时间戳等信息，接收数据更新信息。具体的，数据更新信息包括服务名及版本号。

进一步的，根据服务名和版本号，生成数据更新通知，数据更新通知用于告知消费方具体哪个服务中的哪些数据发生了更新。利用服务名，还可以获知订阅了该服务的消费方都有哪些，由此得到订阅者集合。

步骤S2，根据预设的分批通知数量以及所述订阅者集合中的订阅者个数，确定每批通知订阅者数量。

其中，预设的分批通知数量表示需要分多少批次进行更新通知。计算订阅者集合中的订阅者个数与分批通知数量的比值，该比值就是每批通知订阅者数量。

步骤S3，根据预设的分批间隔时长以及所述每批通知订阅者数量，向所述订阅者集合中各订阅者发送所述数据更新通知。

其中，预设的分批间隔时长表示每批数据更新通知之间间隔的时长。具体的，对订阅者集合中的订阅者进行随机排序，顺序从头开始选取N个订阅者作为第一批订阅者，向第一批订阅者发送数据更新通知，N为每批通知订阅者数量。再次从除第一批订阅者之外的订阅者集合中进行顺序选取，选取N个订阅者作为第二批订阅者进行数据更新通知，直至订阅者集合中所有订阅者均通知完成。

进一步的，未避免最后一批待通知的订阅者数量小于N，在选取订阅者时，只要未被通知的订阅者数量小于N且大于0即可进行通知。订阅了该服务的消费方接受到数据更新通知后，可以利用数据更新通知对该服务中更新的数据进行读取。

作为本发明的一个实施例，如图2所示，根据从服务端接收到的数据更新信息，生成数据更新通知，并根据所述数据更新信息，确定与所述数据更新信息对应的订阅者集合包括：

步骤S11，根据所述服务端的ip地址、端口号及时间戳，从所述服务端接收数据更新信息；其中，所述数据更新信息包括服务名及版本号；

步骤S12，根据所述服务名及所述版本号，生成所述数据更新通知，并确定与所述服务名对应的订阅者集合。

其中，注册中心会通过服务端的ip地址、端口号、时间戳等信息，接收数据更新信息。具体的，数据更新信息包括服务名及版本号。

进一步的，根据服务名和版本号，生成数据更新通知，数据更新通知用于告知消费方具体哪个服务中的哪些数据发生了更新。利用服务名，还可以获知订阅了该服务的消费方都有哪些，由此得到订阅者集合。

作为本发明的一个实施例，根据预设的分批通知数量以及所述订阅者集合中的订阅者个数，确定每批通知订阅者数量包括：计算所述订阅者集合中的订阅者个数与预设的分批通知数量的比值，将所述比值作为所述每批通知订阅者数量。

其中，预设的分批通知数量表示需要分多少批次进行更新通知。计算订阅者集合中的订阅者个数与分批通知数量的比值，该比值就是每批通知订阅者数量。

作为本发明的一个实施例，如图3所示，根据预设的分批间隔时长以及所述每批通知订阅者数量，向所述订阅者集合中各订阅者发送所述数据更新通知包括：

步骤S31，对所述订阅者集合中的订阅者进行随机排序，从随机排序后的订阅者中顺序选取N个第一批订阅者，并向所述第一批订阅者发送所述数据更新通知；其中，N等于所述每批通知订阅者数量；

步骤S32，在等待所述分批间隔时长后，从除去所述第一批订阅者后的订阅者集合中，顺序选取N个第二批订阅者进行数据更新通知发送，直至完成向所述订阅者集合中所有订阅者数据更新通知发送。

其中，预设的分批间隔时长表示每批数据更新通知之间间隔的时长。具体的，对订阅者集合中的订阅者进行随机排序，顺序从头开始选取N个订阅者作为第一批订阅者，向第一批订阅者发送数据更新通知，N为每批通知订阅者数量。再次从除第一批订阅者之外的订阅者集合中进行顺序选取，选取N个订阅者作为第二批订阅者进行数据更新通知，直至订阅者集合中所有订阅者均通知完成。

进一步的，未避免最后一批待通知的订阅者数量小于N，在选取订阅者时，只要未被通知的订阅者数量小于N且大于0即可进行通知。订阅了该服务的消费方接受到数据更新通知后，可以利用数据更新通知对该服务中更新的数据进行读取。

在本发明一具体实施例中，如图4所示为本发明采用的Dubbo集群架构示意图，图中集群为基于Dubbo+zookeeper的微服务集群。架构的工作流程包括：

0：Provider启动；

1：Provider主动将服务信息(如接口、方法、自己的IP:PORT等)注册到Zookeeper；

2：Consumer向Zookeeper注册自己感兴趣的服务；

3：zookeeper将服务信息推送给所有订阅了该服务的Consumer；

4：Consumer向Provider建立TCP长链接，成功后发起业务调用。

其中，图4中的Container的中文含义是容器，这里具体是指Spring容器。Spring框架是Java平台的开源的全栈应用程序框架，Spring容器是Spring框架中的一个概念，在程序运行过程中，spring容器存储对象的实例，管理其创建、引用和销毁等各阶段。

在本实施例中，zooKeeper收到Provider启动的消息后，不是一次性通知所有的Consumer，而是分批通知Consumer，对流量进行削峰。

其中，zooKeeper的Server端借助Watch机制将数据变更通知给zooKeeper的Client端。zooKeeper服务在实际运行时由两部分组成，一部分是客户端(Client)，另一部分是服务端(Server)。Server端负责存储zookeeper内部的数据，并且接收Client端的订阅、查询、写入等请求。Server端是独立部署运行的集群。Client端负责从Server端读写数据，在Dubbo框架中，zookeeper的Client端以jar包的形式集成在dubbo的消费方代码中，消费方启动后，zookeeper Client会向zookeeper Server订阅感兴趣的数据。

进一步的，Watch机制是zookeeper服务端向客户端同步数据的方式，它可以简单的描述为四个步骤：

①客户端向服务端订阅数据；

②服务端发生数据变化；

③服务端通知对应的客户端哪些数据有更新；

④客户端根据通知内容主动读取新数据。

其中，第③步中的“对应”客户端，指的是订阅了“被更新的那部分数据”的客服端，即消费方。zookeeper服务端可能维护了很多数据，不同的客户端可能只订阅了其中的一部分数据，所以当数据有更新时，要通知特定的客户端，而不是每次都通知全部客户端。

具体的，第③步中的“通知”操作的实现过程是利用zookeeper的服务端内部的一个名为WatchManger的类，该类有个名为triggerWatch的方法，通知客户端的操作都是这个方法来完成的。triggerWatch的具体流程如图5所示，包括获取订阅者集合，再获取预设分批通知数量P及分批间隔时长T，计算每批通知订阅者数量N后，进行数据更新通知。

其中，“每次通知N个订阅者，直到通知完毕”这个步骤的细节如图6所示。具体包括对订阅者集合中的订阅者进行随机排序，进行计数，每批次通知N个订阅者，各批次通知间隔为T，直至通知完毕。

在本发明一具体实施例中，如图7所示的微服务集群架构包括1个provider，4个consumer，同时zookeeper作为注册中心负责提供服务发现的能力。在上图中，紫色的zookeeper客户端放在consumer和provider的底部，表示它不会单独部署，而是作为其他应用的一部分存在。zookeeper服务端集群是一个独立部署的集群。

初始状态0：zookeeper集群、4个consumer、provider都未运行。

初始状态1：zookeeper集群启动并运行，4个consumer、provider都未运行。

初始状态2：zookeeper集群正常运行，4个consumer启动并运行，provider未运行。在这个过程中，consumer会向zookeeper订阅自己感兴趣的两个服务com.xxx.serviceA和com.xxx.serviceB。此时，会在zookeeper服务端生成如下一个映射表(即map)，如表1所示。

表1

其中，“键”就是订阅的数据的path，其格式为“/dubbo/服务名_版本号”，其中版本号可能不存在，这个格式是Dubbo框架规定的。“值”就是订阅者的集合，在本例中就是四个consumer。

具体的，在某个时刻，provider启动，provider会把自己的ip地址、端口号、时间戳等信息写到zookeeper服务端。zookeeper服务端按照Linux文件目录的格式来存储数据，在本实施例中，provider注册了两个服务，分别是serviceA和serviceB，因此写入到zookeeper服务端的两条数据大致格式如下：

/dubbo/com.xxx.serviceA/dubbo/192.168.1.3:28080/com.xxx.serviceA？methods＝met hod1,method2×tamp＝1619335640485；

/dubbo/com.xxx.serviceB/dubbo/192.168.1.3:28080/com.xxx.serviceA？methods＝met hod3,method4×tamp＝1619335640497。

此时，zookeeper服务端就能获知/dubbo/com.xxx.serviceA和/dubbo/com.xxx.serviceB这两个path下的数据发生了变化，然后针对每个path执行上面的流程，下面对该流程中进一步说明。

具体的，假设现在处理的是path＝/dubbo/com.xxx.serviceA，具体步骤如表2所示。

表2

进一步的，分批通知过程解释如表3所示。

表3

考虑到zooKeeper集群中，每个zooKeeper的Server实例管理各自连接的Client实例，而不同Server管理的Client数量可能有较大差异。因此，采用了事先指定分批数量和分批间隔的方式，这样可以保证整个集群维度的分批效果符合预期，避免冷热不均的问题。

本发明通过确定订阅者集合进行分批通知的方式，可以有效避免服务端在数据更新后，立即处理大量来自消费方的建连请求，有效降低服务端的TCP队列溢出次数和CPU的使用率，保证业务交易的平稳。

如图8所示为本发明实施例一种微服务集群中更新通知装置的结构示意图，图中所示装置包括：

订阅者集合模块10，用于根据从服务端接收到的数据更新信息，生成数据更新通知，并根据所述数据更新信息，确定与所述数据更新信息对应的订阅者集合。

其中，本发明采用Dubbo集群架构，Dubbo为广泛使用的分布式远程调用框架。具体的，注册中心(Registry)由zooKeeper实现，业界广泛使用的分布式的、开源的分布式应用协调服务，它可以在分布式系统中充当配置中心、分布式锁、服务发现中心等角色。Dubbo框架默认就是以zookeeper做服务发现的。服务端为暴露服务的服务提供方(Provider)，接收注册中心发送的数据更新通知的为调用远程服务的服务消费方(Consumer)。

进一步的，在服务端启动时，会出现数据更新。此时，注册中心会通过服务端的ip地址、端口号、时间戳等信息，接收数据更新信息。具体的，数据更新信息包括服务名及版本号。

进一步的，根据服务名和版本号，生成数据更新通知，数据更新通知用于告知消费方具体哪个服务中的哪些数据发生了更新。利用服务名，还可以获知订阅了该服务的消费方都有哪些，由此得到订阅者集合。

通知数量模块20，用于根据预设的分批通知数量以及所述订阅者集合中的订阅者个数，确定每批通知订阅者数量。

其中，预设的分批通知数量表示需要分多少批次进行更新通知。计算订阅者集合中的订阅者个数与分批通知数量的比值，该比值就是每批通知订阅者数量。

更新通知模块30，用于根据预设的分批间隔时长以及所述每批通知订阅者数量，向所述订阅者集合中各订阅者发送所述数据更新通知。

其中，预设的分批间隔时长表示每批数据更新通知之间间隔的时长。具体的，对订阅者集合中的订阅者进行随机排序，顺序从头开始选取N个订阅者作为第一批订阅者，向第一批订阅者发送数据更新通知，N为每批通知订阅者数量。再次从除第一批订阅者之外的订阅者集合中进行顺序选取，选取N个订阅者作为第二批订阅者进行数据更新通知，直至订阅者集合中所有订阅者均通知完成。

进一步的，未避免最后一批待通知的订阅者数量小于N，在选取订阅者时，只要未被通知的订阅者数量小于N且大于0即可进行通知。订阅了该服务的消费方接受到数据更新通知后，可以利用数据更新通知对该服务中更新的数据进行读取。

作为本发明的一个实施例，如图9所示，所述订阅者集合模块10包括：

更新信息单元11，用于根据所述服务端的ip地址、端口号及时间戳，从所述服务端接收数据更新信息；其中，所述数据更新信息包括服务名及版本号；

订阅者集合单元12，用于根据所述服务名及所述版本号，生成所述数据更新通知，并确定与所述服务名对应的订阅者集合。

作为本发明的一个实施例，所述通知数量模块20还用于计算所述订阅者集合中的订阅者个数与预设的分批通知数量的比值，将所述比值作为所述每批通知订阅者数量。

作为本发明的一个实施例，如图10所示，所述更新通知模块30包括：

随机排序单元31，用于对所述订阅者集合中的订阅者进行随机排序，从随机排序后的订阅者中顺序选取N个第一批订阅者，并向所述第一批订阅者发送所述数据更新通知；其中，N等于所述每批通知订阅者数量；

通知发送单元32，用于在等待所述分批间隔时长后，从除去所述第一批订阅者后的订阅者集合中，顺序选取N个第二批订阅者进行数据更新通知发送，直至完成向所述订阅者集合中所有订阅者数据更新通知发送。

基于与上述一种微服务集群中更新通知方法相同的申请构思，本发明还提供了上述一种微服务集群中更新通知装置。由于该一种微服务集群中更新通知装置解决问题的原理与一种微服务集群中更新通知方法相似，因此该一种微服务集群中更新通知装置的实施可以参见一种微服务集群中更新通知方法的实施，重复之处不再赘述。

本发明通过确定订阅者集合进行分批通知的方式，可以有效避免服务端在数据更新后，立即处理大量来自消费方的建连请求，有效降低服务端的TCP队列溢出次数和CPU的使用率，保证业务交易的平稳。

本发明还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法。

本发明还提供一种计算机可读存储介质，所述计算机可读存储介质存储有执行上述方法的计算机程序。

如图11所示，该电子设备600还可以包括：通信模块110、输入单元120、音频处理单元130、显示器160、电源170。值得注意的是，电子设备600也并不是必须要包括图11中所示的所有部件；此外，电子设备600还可以包括图11中没有示出的部件，可以参考现有技术。

如图11所示，中央处理器100有时也称为控制器或操作控件，可以包括微处理器或其他处理器装置和/或逻辑装置，该中央处理器100接收输入并控制电子设备600的各个部件的操作。

其中，存储器140，例如可以是缓存器、闪存、硬驱、可移动介质、易失性存储器、非易失性存储器或其它合适装置中的一种或更多种。可储存上述与失败有关的信息，此外还可存储执行有关信息的程序。并且中央处理器100可执行该存储器140存储的该程序，以实现信息存储或处理等。

输入单元120向中央处理器100提供输入。该输入单元120例如为按键或触摸输入装置。电源170用于向电子设备600提供电力。显示器160用于进行图像和文字等显示对象的显示。该显示器例如可为LCD显示器，但并不限于此。

该存储器140可以是固态存储器，例如，只读存储器(ROM)、随机存取存储器(RAM)、SIM卡等。还可以是这样的存储器，其即使在断电时也保存信息，可被选择性地擦除且设有更多数据，该存储器的示例有时被称为EPROM等。存储器140还可以是某种其它类型的装置。存储器140包括缓冲存储器141(有时被称为缓冲器)。存储器140可以包括应用/功能存储部142，该应用/功能存储部142用于存储应用程序和功能程序或用于通过中央处理器100执行电子设备600的操作的流程。

存储器140还可以包括数据存储部143，该数据存储部143用于存储数据，例如联系人、数字数据、图片、声音和/或任何其他由电子设备使用的数据。存储器140的驱动程序存储部144可以包括电子设备的用于通信功能和/或用于执行电子设备的其他功能(如消息传送应用、通讯录应用等)的各种驱动程序。

通信模块110即为经由天线111发送和接收信号的发送机/接收机110。通信模块(发送机/接收机)110耦合到中央处理器100，以提供输入信号和接收输出信号，这可以和常规移动通信终端的情况相同。

基于不同的通信技术，在同一电子设备中，可以设置有多个通信模块110，如蜂窝网络模块、蓝牙模块和/或无线局域网模块等。通信模块(发送机/接收机)110还经由音频处理器130耦合到扬声器131和麦克风132，以经由扬声器131提供音频输出，并接收来自麦克风132的音频输入，从而实现通常的电信功能。音频处理器130可以包括任何合适的缓冲器、解码器、放大器等。另外，音频处理器130还耦合到中央处理器100，从而使得可以通过麦克风132能够在本机上录音，且使得可以通过扬声器131来播放本机上存储的声音。

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

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

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

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

本发明中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。