一种服务迁移的流量控制方法、服务器及系统与流程

本申请涉及金融领域，具体涉及一种服务迁移的流量控制方法、服务器及系统。

背景技术：

新一代的金融机构的it系统建设，是在对业务流程的梳理基础上提取出“服务”，不通层级的服务是it系统的基本要素，各个应用之间，以及应用内部通过服务调用来实现业务功能的建设和闭环。

对服务的提供者来说，尤其是基础服务，调用方非常多，要做到不侵入调用方系统的前提下对调用方的精确管理并不容易。例如客户信息管理应用，提供了一个客户基本信息查询的公共服务，整个应用系统的数百个应用的上千个场景都会调用该服务。

对服务调用方进行精确管理的难度在于：银行本身对“场景”缺乏明确的定义，也缺乏有效的机制对场景进行管理。目前的调用方管理依赖于项目涉及过程中要求调用对服务调用登记台账，比如a应用调用了b应用的b服务，实际有10个场景，但a应用只登记了1条调用关系(即只记录了一个场景)，这样调用关系就不准，无法了解实际有多少场景。

在当下银行系统进行大规模“下主机”(从主机迁移到开发平台系统)工程，原有的主机服务要切换到平台服务，这个过程要确保生产稳定，就必须准确的掌握调用方情况。

技术实现要素：

针对现有技术中的问题，本申请提供一种服务迁移的流量控制方法、服务器及系统，让服务的提供方能够精准识别场景，实现对服务调用的精确、智能控制。

为解决上述技术问题，本申请提供以下技术方案：

第一方面，本申请提供一种用于服务迁移的流量控制方法，由第一服务器执行，所述第一服务器搭载第一应用系统，所述第一应用系统上包括至少一个服务；一个或多个服务用于实现一设定场景；所述流量控制方法包括：

将所述至少一个服务对应的源码迁移至第二服务器；

执行第一当前场景调用群；其中所述第二服务器执行第二当前场景调用群；

所述第一当前场景调用群和所述第二当前场景调用群通过流量控制器对当前所有场景进行切分得到；场景名通过一调用链表示，所述调用链包括实现该场景的所有服务的调用字段，所述流量控制器根据所述调用链识别当前所有场景。

第二方面，本申请提供一种用于服务迁移的流量控制方法，由第二服务器执行，所述第二服务器搭载第二应用系统，所述第二应用系统上包括至少二个服务；一个或多个服务用于实现一设定场景；所述流量控制方法包括：

接收第一服务器迁移的至少一个服务对应的源码；

执行第二当前场景调用群；其中所述第一服务器执行第一当前场景调用群；

所述第一当前场景调用群和所述第二当前场景调用群通过流量控制器对当前所有场景进行切分得到；场景名通过一调用链表示，所述调用链包括实现该场景的所有服务的调用字段，所述流量控制器根据所述调用链识别当前所有场景。

第三方面，本申请提供一种用于服务迁移的流量控制方法，由流量控制器执行，所述第一服务器搭载第一应用系统，所述第一应用系统上包括至少一个服务；所述第二服务器搭载第二应用系统，所述第二应用系统上包括至少二个服务；一个或多个服务用于实现一设定场景；所述流量控制方法包括：

根据调用链识别当前所有场景，其中，场景名通过一调用链表示，所述调用链包括实现该场景的所有服务的调用字段；

对当前所有场景进行切分，得到第一当前场景调用群和第二当前场景调用群；

将所述第一当前场景调用群发送给第一服务器，所述第二当前场景调用群发送给第二服务器。

进一步地，所述对当前所有场景进行切分，得到第一当前场景调用群和第二当前场景调用群，包括：

调整所有场景中所述第一当前场景调用群和所述第二当前场景调用群的流量比例，进而使得所述第一当前场景调用群流量逐渐减少，所述第二当前场景调用群流量逐渐增加。

进一步地，所述对当前所有场景进行切分，得到第一当前场景调用群和第二当前场景调用群，包括：

等量减少所述第一当前场景调用群的流量，等量减少所述第二当前场景调用群的流量，进而使得所述第一当前场景调用群流量逐渐减少，所述第二当前场景调用群流量逐渐增加。

第四方面，本申请提供一种用于服务迁移的流量控制系统，所述第一服务器搭载第一应用系统，所述第一应用系统上包括至少一个服务；所述第二服务器搭载第二应用系统，所述第二应用系统上包括至少二个服务；一个或多个服务用于实现一设定场景；所述流量控制系统包括：

第一服务器，所述第一服务器将所述至少一个服务对应的源码迁移至第二服务器；执行第一当前场景调用群；其中所述第二服务器执行第二当前场景调用群；

第二服务器，所述第二服务器接收第一服务器迁移的至少一个服务对应的源码；执行第二当前场景调用群；其中所述第一服务器执行第一当前场景调用群；

流量控制器，所述流量控制器根据调用链识别当前所有场景；对当前所有场景进行切分，得到第一当前场景调用群和第二当前场景调用群；将所述第一当前场景调用群发送给第一服务器，所述第二当前场景调用群发送给第二服务器；

其中，场景名通过一调用链表示，所述调用链包括实现该场景的所有服务的调用字段。

进一步地，所述流量控制系统还包括：

分布式服务平台(dsf)，所述分布式服务平台用于登记所述服务以及所述场景的调用记录。

第五方面，本申请提供一种第一服务器，所述第一服务器搭载第一应用系统，所述第一应用系统上包括至少一个服务；一个或多个服务用于实现一设定场景；所述第一服务器包括：

服务迁移模块：将所述至少一个服务对应的源码迁移至第二服务器；

第一场景调用模块：执行第一当前场景调用群；其中所述第二服务器执行第二当前场景调用群；

所述第一当前场景调用群和所述第二当前场景调用群通过流量控制器对当前所有场景进行切分得到；场景名通过一调用链表示，所述调用链包括实现该场景的所有服务的调用字段，所述流量控制器根据所述调用链识别当前所有场景。

第六方面，本申请提供一种第二服务器，所述第二服务器搭载第二应用系统，所述第二应用系统上包括至少二个服务；一个或多个服务用于实现一设定场景；所述第二服务器包括：

服务接收模块：接收第一服务器迁移的至少一个服务对应的源码；

第二场景调用模块：执行第二当前场景调用群；其中所述第一服务器执行第一当前场景调用群；

所述第一当前场景调用群和所述第二当前场景调用群通过流量控制器对当前所有场景进行切分得到；场景名通过一调用链表示，所述调用链包括实现该场景的所有服务的调用字段，所述流量控制器根据所述调用链识别当前所有场景。

第七方面，本申请提供一种流量控制器，所述第一服务器搭载第一应用系统，所述第一应用系统上包括至少一个服务；所述第二服务器搭载第二应用系统，所述第二应用系统上包括至少二个服务；一个或多个服务用于实现一设定场景；所述流量控制器包括：

场景识别模块：根据调用链识别当前所有场景，其中，场景名通过一调用链表示，所述调用链包括实现该场景的所有服务的调用字段；

场景切分模块：对当前所有场景进行切分，得到第一当前场景调用群和第二当前场景调用群；

场景发送模块：将所述第一当前场景调用群发送给第一服务器，所述第二当前场景调用群发送给第二服务器。

第八方面，本申请提供一种用于服务迁移的流量控制系统，所述第一服务器搭载第一应用系统，所述第一应用系统上包括至少一个服务；所述第二服务器搭载第二应用系统，所述第二应用系统上包括至少二个服务；一个或多个服务用于实现一设定场景；所述流量控制系统包括：

第一服务器，第一服务器将所述至少一个服务对应的源码迁移至第二服务器；执行第一当前场景调用群；其中所述第二服务器执行第二当前场景调用群；

第二服务器，第二服务器接收第一服务器迁移的至少一个服务对应的源码；执行第二当前场景调用群；其中所述第一服务器执行第一当前场景调用群；

流量控制器，流量控制器根据调用链识别当前所有场景；对当前所有场景进行切分，得到第一当前场景调用群和第二当前场景调用群；将所述第一当前场景调用群发送给第一服务器，所述第二当前场景调用群发送给第二服务器；

其中，场景名通过一调用链表示，所述调用链包括实现该场景的所有服务的调用字段。

进一步地，所述流量控制系统还包括：

调用记录模块：所述调用记录模块包括分布式服务平台(dsf)，用于登记所述服务以及所述场景的调用记录。

第九方面，本申请提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现所述的前流量控制方法。

第十方面，本申请提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现所述的流量控制方法。

由上述技术方案可知，本申请提供的一种服务迁移的流量控制方法、服务器及系统，方法包括：第一服务器将至少一个服务对应的源码迁移至第二服务器，一个或多个服务用于实现一设定场景，每个服务的数据包内存储有调用字段，每一次调用场景，把实现该场景的所有服务的调用字段串起来，形成一个调用链，流量控制器根据调用链识别当前所有场景，并对当前所有场景进行切分，得到第一当前场景调用群和第二当前场景调用群，第一服务器执行第一当前场景调用群，第二服务器执行第二当前场景调用群；通过在每个服务的数据包内存储调用字段，调用字段构成了设定场景的调用链，不同的调用链对应不同的场景，在迁移过程中，不需要对调用方系统进行改造，能够直接定位到具体的场景，通过调用链识别场景，同时配合流量控制器，对场景进行流量控制，可实现服务调用的精确控制，以及智能流量控制。

附图说明

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

图1是本申请实施例中服务迁移的流量控制方法中服务迁移流程示意图。

图2是本申请实施例中服务迁移的流量控制方法中服务接收流程示意图。

图3是本申请实施例中服务迁移的流量控制方法中流量切分流程示意图。

图4是本申请实施例中服务迁移的流量控制系统的流程示意图。

图5是本申请实施例中服务迁移的流量控制方法中场景调用链示意图。

图6是本申请实施例中一种第一服务器的结构示意图。

图7是本申请实施例中一种第二服务器的结构示意图。

图8是本申请实施例中一种流量控制器的结构示意图。

图9是本申请实施例中服务迁移的流量控制系统的结构示意图。

图10是本申请实施例中的电子设备的结构示意图。

具体实施方式

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

需要说明的是，本申请公开的一种服务迁移的流量控制方法、服务器及系统可用于金融领域，也可用于除金融领域之外的任意领域，本申请公开的一种服务迁移的流量控制方法、服务器及系统的应用领域不做限定。

在现有技术中，对服务调用方进行精确管理的难度在于：银行本身对“场景”缺乏明确的定义，也缺乏有效的机制对场景进行管理。目前的调用方管理依赖于项目涉及过程中要求调用对服务调用登记台账，比如a应用调用了b应用的b服务，实际有10个场景，但a应用只登记了1条调用关系(即只记录了一个场景)，这样调用关系就不准，无法了解实际有多少场景。在当下银行系统进行大规模“下主机”(从主机迁移到开发平台系统)工程，原有的主机服务要切换到平台服务，这个过程要确保生产稳定，就必须准确的掌握调用方情况，本申请提供一种服务迁移的流量控制方法、系统、装置、电子设备和计算机可读存储介质，通过调用链来精确定位并识别所有场景，不同的调用链对应不同的场景，做到场景的区分，然后基于场景实现对场景的精细化管理。

基于上述内容，本申请还提供一种用于实现本申请一个或多个实施例中提供的流量控制方法的流量控制系统，该流量控制系统可以与客户端设备之间通信连接，所述客户终端设备可以设有多个，流量控制系统具体可以通过应用服务器访问所述客户终端设备。

其中，所述流量控制系统可以将第一服务器以及第二服务器的流量数据传输给客户终端设备，所述客户终端为一搭载流量控制、分析程序的设备，所述客户终端根据流量控制系统提供的流量数据，对场景流量进行分析，判断服务迁移过程中所有调用服务的流量总和是否稳定。

可以理解的是，所述客户端设备可以包括智能手机、平板电子设备、便携式计算机、台式电脑、个人数字助理(pda)。

上述的客户端设备可以具有通信模块(即通信单元)，可以与远程的流量控制系统进行通信连接，实现与所述服务器的数据传输。例如，通信单元可以将客户终端设备对所有调用服务的流量分析结果，传输给流量控制系统，以便流量控制系统根据流量分析结果进行场景流量调整。

上述流量控制系统与所述客户端设备之间可以使用任何合适的网络协议进行通信，包括在本申请提交日尚未开发出的网络协议。所述网络协议例如可以包括tcp/ip协议、udp/ip协议、http协议、https协议等。当然，所述网络协议例如还可以包括在上述协议之上使用的rpc协议(remoteprocedurecallprotocol，远程过程调用协议)、rest协议(representationalstatetransfer，表述性状态转移协议)等。

本申请提供的一种服务迁移的流量控制方法、系统、装置、电子设备和计算机可读存储介质，通过在每个服务的数据包内存储调用字段，调用字段构成了设定场景的调用链，不同的调用链对应不同的场景，不需要对调用方系统进行改造，能够直接定位到具体的场景，在迁移过程中，通过调用链识别场景，同时配合流量控制器，对场景进行流量控制，可实现服务调用的精确控制，以及智能流量控制。

具体通过下述多个实施例及应用实例分别进行说明。

在当下银行系统进行大规模“下主机”(从主机迁移到开发平台系统)工程，原有的主机服务要切换到平台服务，这个过程要确保生产稳定，就必须准确的掌握调用方情况。为了解决这一问题，第一方面，本申请提供一种服务迁移的流量控制方法，参见图1，由第一服务器执行，所述第一服务器搭载第一应用系统，所述第一应用系统上包括至少一个服务；一个或多个服务用于实现一设定场景，所述流量控制方法具体包含有如下内容：

步骤100：将所述至少一个服务对应的源码迁移至第二服务器。

可以理解的是，将所述至少一个服务对应的源码迁移至第二服务器，可以是将第一服务器搭载的第一应用系统中的至少一个服务直接迁移至第二服务器，也可以将多个服务进行整合，在第二服务器中整合为一个新服务；例如原主机系统上的“原服务1”、“原服务2”、“原服务3”都是功能相似的服务(客户基础信息查询)，迁移到开发平台后，整合成一个“新服务1”。

步骤101：执行第一当前场景调用群；其中所述第二服务器执行第二当前场景调用群。

可以理解的是，在迁移过程中，这三个服务在一段时间内是同时存在的，灰度切流是逐步切换的过程，即，第一服务器中的至少一个服务的流量逐步减少，第二服务器中的至少一个服务的流量逐步增加，因此，第一服务器与第二服务器上的分别执行两个不同的场景调用群。

所述第一当前场景调用群和所述第二当前场景调用群通过流量控制器对当前所有场景进行切分得到；场景名通过一调用链表示，所述调用链包括实现该场景的所有服务的调用字段，所述流量控制器根据所述调用链识别当前所有场景。

可以理解的是，用调用链来区分和定义场景。调用链是“(应用名1+程序类名1)>(应用名2+程序类名2)>(应用名3+程序类名3)...>(应用名n+程序类名n)”这种格式。服务调用的数据包分为有数据包头和数据包体。数据包头包含了支持服务调用的技术字段，数据包体则是服务本身业务逻辑相关的字段。数据包头有预留空间，支持自定义字段，我们增加一个调用链路字段，用来存储调用链路，如下表1所示。

表1

下面举一个例子，参见图5，客户信息应用提供了客户基本信息查询服务，该服务被个人金融业务应用的“现金支取服务”和“个人转账服务”调用，这两个服务有分别新终端的“现金支取交易”和“个人转账交易”、手机银行的“注册账户转账”和“转账汇款”调用。在这个例子中，可以定义出四个场景，分别是：

(f-soct+cashdraw)>(f-pras+cashdrawsv)>(f-ecis+qrypersoncominfo)、

(f-soct+persontransf)>(f-pras+persontransfsv)>

(f-ecis+qrypersoncominfo)、

(f-wabp+lcltransf)>(f-pras+persontransfsv)>

(f-ecis+qrypersoncominfo)、

(f-wabp+comtransf)>(f-pras+persontransfsv)>

(f-ecis+qrypersoncominfo)。

从上述描述可知，本申请实施例提供的一种服务迁移的流量控制方法，通过在每个服务的数据包内存储调用字段，调用字段构成了设定场景的调用链，不同的调用链对应不同的场景，不需要对调用方系统进行改造，能够直接定位到具体的场景，在迁移过程中，通过调用链识别场景，同时配合流量控制器，对场景进行流量控制，可实现服务调用的精确控制，以及智能流量控制。

第二方面，本申请提供一种服务迁移的流量控制方法，参见图2，由第二服务器执行，所述第二服务器搭载第二应用系统，所述第二应用系统上包括至少二个服务；一个或多个服务用于实现一设定场景；所述流量控制方法具体包含有如下内容：

步骤200：接收第一服务器迁移的至少一个服务对应的源码；

可以理解的是，接收第一服务器迁移的至少一个服务对应的源码，可以是将第二服务器直接接收第一服务器中的至少一个服务，也可以是将接收第一服务器中的至少一个服务整合为一个新服务；例如原主机系统上的“原服务1”、“原服务2”、“原服务3”都是功能相似的服务(客户基础信息查询)，迁移到开发平台后，整合成一个“新服务1”。

步骤201：执行第二当前场景调用群；其中所述第一服务器执行第一当前场景调用群；

可以理解的是，在迁移过程中，这三个服务在一段时间内是同时存在的，灰度切流是逐步切换的过程，即，第一服务器中的至少一个服务的流量逐步减少，第二服务器中的至少一个服务的流量逐步增加，因此，第一服务器与第二服务器上的分别执行两个不同的场景调用群。

所述第一当前场景调用群和所述第二当前场景调用群通过流量控制器对当前所有场景进行切分得到；场景名通过一调用链表示，所述调用链包括实现该场景的所有服务的调用字段，所述流量控制器根据所述调用链识别当前所有场景。

可以理解的是，用调用链来区分和定义场景。调用链是“(应用名1+程序类名1)>(应用名2+程序类名2)>(应用名3+程序类名3)...>(应用名n+程序类名n)”这种格式。服务调用的数据包分为有数据包头和数据包体。数据包头包含了支持服务调用的技术字段，数据包体则是服务本身业务逻辑相关的字段。数据包头有预留空间，支持自定义字段，我们增加一个调用链路字段，用来存储调用链路，如表1所示。

下面举一个例子，参见图5，客户信息应用提供了客户基本信息查询服务，该服务被个人金融业务应用的“现金支取服务”和“个人转账服务”调用，这两个服务有分别新终端的“现金支取交易”和“个人转账交易”、手机银行的“注册账户转账”和“转账汇款”调用。以手机银行的“注册账户转账”为例，该功能调用“个人转账服务”时，调用链路字段为“(f-wabp+lcltransf)>(f-pras+persontransfsv)”，“个人转账服务”进一步调用“客户基本信息查询服务”时，调用链路字段为“(f-wabp+lcltransf)>(f-pras+persontransfsv)>(f-ecis+qrypersoncominfo)”。

从上述描述可知，本申请实施例提供的一种服务迁移的流量控制方法，通过在每个服务的数据包内存储调用字段，调用字段构成了设定场景的调用链，不同的调用链对应不同的场景，不需要对调用方系统进行改造，能够直接定位到具体的场景，在迁移过程中，通过调用链识别场景，同时配合流量控制器，对场景进行流量控制，可实现服务调用的精确控制，以及智能流量控制。

第三方面，本申请提供一种用于服务迁移的流量控制方法，参见图3，由流量控制器执行，所述第一服务器搭载第一应用系统，所述第一应用系统上包括至少一个服务；所述第二服务器搭载第二应用系统，所述第二应用系统上包括至少二个服务；一个或多个服务用于实现一设定场景；所述流量控制方法包括：

步骤300：根据调用链识别当前所有场景，其中，场景名通过一调用链表示，所述调用链包括实现该场景的所有服务的调用字段；

可以理解的是，用调用链来区分和定义场景。调用链是“(应用名1+程序类名1)>(应用名2+程序类名2)>(应用名3+程序类名3)...>(应用名n+程序类名n)”这种格式。服务调用的数据包分为有数据包头和数据包体。数据包头包含了支持服务调用的技术字段，数据包体则是服务本身业务逻辑相关的字段。数据包头有预留空间，支持自定义字段，我们增加一个调用链路字段，用来存储调用链路，不同的调用链对应不同的场景，流量控制器通过调用链识别当前所有场景。

步骤301：对当前所有场景进行切分，得到第一当前场景调用群和第二当前场景调用群；

可以理解的是，在迁移过程中，第一服务器上的至少一个服务与迁移到第二服务器上的至少一个服务在一段时间内是同时存在的，灰度切流是逐步切换的过程。即第一服务器上的至少一个服务的流量逐步减少，迁移到第二服务器上的至少一个服务的流量逐步增加，但这两个服务器上的流量总量应该保持稳定的。那么在做流量监控时，要达到如下要求：

1)分别监控第一服务器上的至少一个服务以及迁移到第二服务器上的至少一个服务的流量，其流量的变化必须和切流计划一致。

2)监控第一服务器上的至少一个服务以及迁移到第二服务器上的至少一个服务的流量总和，这个应该是保持稳定的。

3)当监控到第一服务器上的至少一个服务以及迁移到第二服务器上的至少一个服务中任何一个出行大幅变化的时候，要立即判断这两个服务器的流量总和是否稳定。

因此，流量控制器将所有场景切分，得到第一当前场景调用群和第二当前场景调用群，第一当前场景调用群和第二当前场景调用群的流量是逐渐变化的。

步骤302：将所述第一当前场景调用群发送给第一服务器，所述第二当前场景调用群发送给第二服务器。

可以理解的是，流量控制器将切分后的第一当前场景调用群和第二当前场景调用群发送给第一服务器和第二服务器执行，直至第一服务器上的流量逐渐变为零，第一服务器上的流量逐渐达到流量总和。

从上述描述可知，本申请实施例提供的一种服务迁移的流量控制方法，在迁移过程中，流量控制器通过调用链识别场景，不同的调用链对应不同的场景，不需要对调用方系统进行改造，能够直接定位到具体的场景，对场景进行精确管理、精细切流，在保持客户体验不变的同时，确保系统运行稳定。

本申请提供一种用于服务迁移的流量控制方法，所述对当前所有场景进行切分，得到第一当前场景调用群和第二当前场景调用群，包括：

调整所有场景中所述第一当前场景调用群和所述第二当前场景调用群的流量比例，进而使得所述第一当前场景调用群流量逐渐减少，所述第二当前场景调用群流量逐渐增加。

可以理解的是，将第一当前场景调用群和第二当前场景调用群的流量按照比例进行切分，直至第一当前场景调用群的流量逐渐变为零，第二当前场景调用群的流量逐渐达到流量总和；例如，假设调用前所有场景的流量总和为100，流量控制器将第一当前场景调用群和第二当前场景调用群的流量比调整为9：1，再逐渐将第一当前场景调用群和第二当前场景调用群的流量比调整至1：9，最后将第一当前场景调用群的流量逐渐调整至0，第二当前场景调用群的流量逐渐调整至100，场景流量控制参数，如下表2所示。

表2

从上述描述可知，本申请实施例提供的一种服务迁移的流量控制方法，流量控制器通过改变调用场景的流量比例，对场景进行精确管理、精细切流，在保持客户体验不变的同时，确保系统运行稳定。

本申请提供一种用于服务迁移的流量控制方法，所述对当前所有场景进行切分，得到第一当前场景调用群和第二当前场景调用群，包括：

等量减少所述第一当前场景调用群的流量，等量减少所述第二当前场景调用群的流量，进而使得所述第一当前场景调用群流量逐渐减少，所述第二当前场景调用群流量逐渐增加。

可以理解的是，将第一当前场景调用群和第二当前场景调用群的流量按照一定量的流量进行增减，直至第一当前场景调用群的流量逐渐变为零，第二当前场景调用群的流量逐渐达到流量总和；例如，假设调用前所有场景的流量总和为100，流量控制器将第一当前场景调用群的流量调整至10，第二当前场景调用群的流量调整至90，再以10个流量为单位，逐渐将第一当前场景调用群的流量调整至0，第二当前场景调用群的流量调整至100，场景流量控制参数，如表2所示。

从上述描述可知，本申请实施例提供的一种服务迁移的流量控制方法，在迁移过程中，流量控制器通过改变调用场景的流量比例，对场景进行精确管理、精细切流，在保持客户体验不变的同时，确保系统运行稳定。

第四方面，本申请实施例提供一种用于服务迁移的流量控制系统，参见图4，所述第一服务器搭载第一应用系统，所述第一应用系统上包括至少一个服务；所述第二服务器搭载第二应用系统，所述第二应用系统上包括至少二个服务；一个或多个服务用于实现一设定场景；所述流量控制系统包括：

第一服务器，所述第一服务器将所述至少一个服务对应的源码迁移至第二服务器；执行第一当前场景调用群；其中所述第二服务器执行第二当前场景调用群；

第二服务器，所述第二服务器接收第一服务器迁移的至少一个服务对应的源码；执行第二当前场景调用群；其中所述第一服务器执行第一当前场景调用群；

流量控制器，所述流量控制器根据调用链识别当前所有场景；对当前所有场景进行切分，得到第一当前场景调用群和第二当前场景调用群；将所述第一当前场景调用群发送给第一服务器，所述第二当前场景调用群发送给第二服务器；

其中，场景名通过一调用链表示，所述调用链包括实现该场景的所有服务的调用字段。

可以理解的是，将所述至少一个服务对应的源码迁移至第二服务器，一个或多个服务用于实现一设定场景，不同的调用链对应不同的场景，流量控制器根据调用链来识别场景，进而将识别的所有场景进行切分，得到第一当前场景调用群和第二当前场景调用群，并发送给第一服务器和第二服务器执行，同时，根据场景流量控制表以及关联场景定义表，对第一当前场景调用群和第二当前场景调用群的流量进行调整，直至第一服务器上的流量逐渐变为零，第一服务器上的流量逐渐达到流量总和，关联场景定义表如下表3所示。

表3

从上述描述可知，本申请实施例提供的一种服务迁移的流量控制系统，通过在每个服务的数据包内存储调用字段，调用字段构成了设定场景的调用链，不同的调用链对应不同的场景，不需要对调用方系统进行改造，能够直接定位到具体的场景，在迁移过程中，通过调用链识别场景，同时配合流量控制器，对场景进行流量控制，可实现服务调用的精确控制，以及智能流量控制。

本申请实施例提供一种用于服务迁移的流量控制系统，还包括：

分布式服务平台(dsf)，所述分布式服务平台用于登记所述服务以及所述场景的调用记录。

可以理解的是，分布式服务平台(dsf)的原理是服务端发布服务去zookeeper注册，客户端去zookeeper注册中心调用服务端发布的服务，分布式服务平台(dsf)是管理服务之间调用的基础平台，负责服务的注册、服务调用关系的登记等。

下面结合具体实例，对本申请一种用于服务迁移的流量控制系统进行具体说明。

步骤501：渠道端需要调用产品功能，调用dsf平台的注册中心，获取产品的地址信息。

步骤502：渠道端功能调用产品服务。

步骤503：产品服务，调用dsf平台的注册中心，获取基础服务的地址信息。

步骤504：产品服务，调用基础服务。

步骤505：基础应用的所有服务通过接入层对外连接，接入层从数据包头的调用链路字段，获取场景信息，调用自身的流量控制器，来进行场景流程控制。

步骤506：流量控制器，访问场景流量控制表，判断该场景(在某地区)下有没有打开开关，以及是否在支持的流量范围内。

步骤507：流量控制器判断通过后，接入层调用相关服务。

第五方面，为了能够使得上述实施例进行，本申请提供一种第一服务器，参见图6，所述第一服务器搭载第一应用系统，所述第一应用系统上包括至少一个服务；一个或多个服务用于实现一设定场景；所述第一服务器包括：

服务迁移模块10：将所述至少一个服务对应的源码迁移至第二服务器；

可以理解的是，服务迁移模块中的将第一服务器中的至少一个服务对应的源码迁移至第二服务器，可以是将第一服务器搭载的第一应用系统中的至少一个服务直接迁移至第二服务器，也可以将多个服务进行整合，在第二服务器中整合为一个新服务；例如原主机系统上的“原服务1”、“原服务2”、“原服务3”都是功能相似的服务(客户基础信息查询)，迁移到开发平台后，整合成一个“新服务1”。

第一场景调用模块11：执行第一当前场景调用群；其中所述第二服务器执行第二当前场景调用群；

可以理解的是，在迁移过程中，这三个服务在一段时间内是同时存在的，灰度切流是逐步切换的过程，即，第一服务器中的至少一个服务的流量逐步减少，第二服务器中的至少一个服务的流量逐步增加，因此，第一服务器与第二服务器上的分别执行两个不同的场景调用群。

所述第一当前场景调用群和所述第二当前场景调用群通过流量控制器对当前所有场景进行切分得到；场景名通过一调用链表示，所述调用链包括实现该场景的所有服务的调用字段，所述流量控制器根据所述调用链识别当前所有场景。

可以理解的是，用调用链来区分和定义场景。调用链是“(应用名1+程序类名1)>(应用名2+程序类名2)>(应用名3+程序类名3)...>(应用名n+程序类名n)”这种格式。服务调用的数据包分为有数据包头和数据包体。数据包头包含了支持服务调用的技术字段，数据包体则是服务本身业务逻辑相关的字段。数据包头有预留空间，支持自定义字段，我们增加一个调用链路字段，用来存储调用链路，如表1所示。

下面举一个例子，参见图5，客户信息应用提供了客户基本信息查询服务，该服务被个人金融业务应用的“现金支取服务”和“个人转账服务”调用，这两个服务有分别新终端的“现金支取交易”和“个人转账交易”、手机银行的“注册账户转账”和“转账汇款”调用。在这个例子中，可以定义出四个场景，分别是：

(f-soct+cashdraw)>(f-pras+cashdrawsv)>(f-ecis+qrypersoncominfo)、

(f-soct+persontransf)>(f-pras+persontransfsv)>

(f-ecis+qrypersoncominfo)、

(f-wabp+lcltransf)>(f-pras+persontransfsv)>

(f-ecis+qrypersoncominfo)、

(f-wabp+comtransf)>(f-pras+persontransfsv)>

(f-ecis+qrypersoncominfo)。

从上述描述可知，本申请实施例提供的一种第一服务器，通过在每个服务的数据包内存储调用字段，调用字段构成了设定场景的调用链，不同的调用链对应不同的场景，通过数据包头传递场景信息，不需要对调用方系统进行改造，能够直接定位到具体的场景，可实现服务以及场景调用的精确控制。

第六方面，为了能够使得上述实施例进行，本申请提供一种第二服务器，参见图7，所述第二服务器搭载第二应用系统，所述第二应用系统上包括至少二个服务；一个或多个服务用于实现一设定场景；所述第二服务器包括：

服务接收模块20：接收第一服务器迁移的至少一个服务对应的源码；

可以理解的是，服务接收模块接收第一服务器迁移的至少一个服务对应的源码，可以是将第二服务器直接接收第一服务器中的至少一个服务，也可以是将接收第一服务器中的至少一个服务整合为一个新服务；例如原主机系统上的“原服务1”、“原服务2”、“原服务3”都是功能相似的服务(客户基础信息查询)，迁移到开发平台后，整合成一个“新服务1”。

第二场景调用模块21：执行第二当前场景调用群；其中所述第一服务器执行第一当前场景调用群；

可以理解的是，在迁移过程中，这三个服务在一段时间内是同时存在的，灰度切流是逐步切换的过程，即，第一服务器中的至少一个服务的流量逐步减少，第二服务器中的至少一个服务的流量逐步增加，因此，第一服务器与第二服务器上的分别执行两个不同的场景调用群。

所述第一当前场景调用群和所述第二当前场景调用群通过流量控制器对当前所有场景进行切分得到；场景名通过一调用链表示，所述调用链包括实现该场景的所有服务的调用字段，所述流量控制器根据所述调用链识别当前所有场景。

可以理解的是，用调用链来区分和定义场景。调用链是“(应用名1+程序类名1)>(应用名2+程序类名2)>(应用名3+程序类名3)...>(应用名n+程序类名n)”这种格式。服务调用的数据包分为有数据包头和数据包体。数据包头包含了支持服务调用的技术字段，数据包体则是服务本身业务逻辑相关的字段。数据包头有预留空间，支持自定义字段，我们增加一个调用链路字段，用来存储调用链路，如表1所示。

下面举一个例子，参见图5，客户信息应用提供了客户基本信息查询服务，该服务被个人金融业务应用的“现金支取服务”和“个人转账服务”调用，这两个服务有分别新终端的“现金支取交易”和“个人转账交易”、手机银行的“注册账户转账”和“转账汇款”调用。以手机银行的“注册账户转账”为例，该功能调用“个人转账服务”时，调用链路字段为“(f-wabp+lcltransf)>(f-pras+persontransfsv)”，“个人转账服务”进一步调用“客户基本信息查询服务”时，调用链路字段为“(f-wabp+lcltransf)>(f-pras+persontransfsv)>(f-ecis+qrypersoncominfo)”。

从上述描述可知，本申请实施例提供的一种第二服务器，通过在每个服务的数据包内存储调用字段，调用字段构成了设定场景的调用链，不同的调用链对应不同的场景，通过数据包头传递场景信息，不需要对调用方系统进行改造，能够直接定位到具体的场景，可实现服务以及场景调用的精确控制。

第七方面，为了能够使得上述实施例进行，本申请提供一种流量控制器，参见图8，所述第一服务器搭载第一应用系统，所述第一应用系统上包括至少一个服务；所述第二服务器搭载第二应用系统，所述第二应用系统上包括至少二个服务；一个或多个服务用于实现一设定场景；所述流量控制器包括：

场景识别模块30：根据调用链识别当前所有场景，其中，场景名通过一调用链表示，所述调用链包括实现该场景的所有服务的调用字段；

可以理解的是，用调用链来区分和定义场景。调用链是“(应用名1+程序类名1)>(应用名2+程序类名2)>(应用名3+程序类名3)...>(应用名n+程序类名n)”这种格式。服务调用的数据包分为有数据包头和数据包体。数据包头包含了支持服务调用的技术字段，数据包体则是服务本身业务逻辑相关的字段。数据包头有预留空间，支持自定义字段，我们增加一个调用链路字段，用来存储调用链路，不同的调用链对应不同的场景，流量控制器通过调用链识别当前所有场景。

场景切分模块31：对当前所有场景进行切分，得到第一当前场景调用群和第二当前场景调用群；

可以理解的是，在迁移过程中，第一服务器上的至少一个服务与迁移到第二服务器上的至少一个服务在一段时间内是同时存在的，灰度切流是逐步切换的过程。即第一服务器上的至少一个服务的流量逐步减少，迁移到第二服务器上的至少一个服务的流量逐步增加，但这两个服务器上的流量总量应该保持稳定的。那么在做流量监控时，要达到如下要求：

4)分别监控第一服务器上的至少一个服务以及迁移到第二服务器上的至少一个服务的流量，其流量的变化必须和切流计划一致。

5)监控第一服务器上的至少一个服务以及迁移到第二服务器上的至少一个服务的流量总和，这个应该是保持稳定的。

6)当监控到第一服务器上的至少一个服务以及迁移到第二服务器上的至少一个服务中任何一个出行大幅变化的时候，要立即判断这两个服务器的流量总和是否稳定。

因此，流量控制器将所有场景切分，得到第一当前场景调用群和第二当前场景调用群，第一当前场景调用群和第二当前场景调用群的流量是逐渐变化的。

场景发送模块32：将所述第一当前场景调用群发送给第一服务器，所述第二当前场景调用群发送给第二服务器。

可以理解的是，流量控制器将切分后的第一当前场景调用群和第二当前场景调用群发送给第一服务器和第二服务器执行，直至第一服务器上的流量逐渐变为零，第一服务器上的流量逐渐达到流量总和。

从上述描述可知，本申请实施例提供的一种流量控制器，在迁移过程中，流量控制器通过调用链识别场景，不同的调用链对应不同的场景，不需要对调用方系统进行改造，能够直接定位到具体的场景，对场景进行精确管理、精细切流，在保持客户体验不变的同时，确保系统运行稳定。

第八方面，在本申请提供一种用于服务迁移的流量控制系统，如图9所示，所述第一服务器搭载第一应用系统，所述第一应用系统上包括至少一个服务；所述第二服务器搭载第二应用系统，所述第二应用系统上包括至少二个服务；一个或多个服务用于实现一设定场景；所述流量控制系统包括：

第一服务器40，第一服务器将所述至少一个服务对应的源码迁移至第二服务器；执行第一当前场景调用群；其中所述第二服务器执行第二当前场景调用群；

第二服务器41，第二服务器接收第一服务器迁移的至少一个服务对应的源码；执行第二当前场景调用群；其中所述第一服务器执行第一当前场景调用群；

流量控制器42，流量控制器根据调用链识别当前所有场景；对当前所有场景进行切分，得到第一当前场景调用群和第二当前场景调用群；将所述第一当前场景调用群发送给第一服务器，所述第二当前场景调用群发送给第二服务器；

其中，场景名通过一调用链表示，所述调用链包括实现该场景的所有服务的调用字段。

可以理解的是，将所述至少一个服务对应的源码迁移至第二服务器，一个或多个服务用于实现一设定场景，不同的调用链对应不同的场景，流量控制器根据调用链来识别场景，进而将识别的所有场景进行切分，得到第一当前场景调用群和第二当前场景调用群，并发送给第一服务器和第二服务器执行，同时，根据场景流量控制表以及关联场景定义表，对第一当前场景调用群和第二当前场景调用群的流量进行调整，直至第一服务器上的流量逐渐变为零，第一服务器上的流量逐渐达到流量总和，关联场景定义表如表3所示。

从上述描述可知，本申请实施例提供的一种服务迁移的流量控制系统，通过在每个服务的数据包内存储调用字段，调用字段构成了设定场景的调用链，不同的调用链对应不同的场景，不需要对调用方系统进行改造，能够直接定位到具体的场景，在迁移过程中，通过调用链识别场景，同时配合流量控制器，对场景进行流量控制，可实现服务调用的精确控制，以及智能流量控制。

本申请实施例提供一种用于服务迁移的流量控制系统，参见图8，还包括：

调用记录模块43：所述调用记录模块包括分布式服务平台(dsf)，用于登记所述服务以及所述场景的调用记录。

可以理解的是，分布式服务平台(dsf)的原理是服务端发布服务去zookeeper注册，客户端去zookeeper注册中心调用服务端发布的服务，分布式服务平台(dsf)是管理服务之间调用的基础平台，负责服务的注册、服务调用关系的登记等。

下面结合具体实例，参见图5，对本申请一种用于服务迁移的流量控制系统进行具体说明。

步骤501：渠道端需要调用产品功能，调用dsf平台的注册中心，获取产品的地址信息。

步骤502：渠道端功能调用产品服务。

步骤503：产品服务，调用dsf平台的注册中心，获取基础服务的地址信息。

步骤504：产品服务，调用基础服务。

步骤505：基础应用的所有服务通过接入层对外连接，接入层从数据包头的调用链路字段，获取场景信息，调用自身的流量控制器，来进行场景流程控制。

步骤506：流量控制器，访问场景流量控制表，判断该场景(在某地区)下有没有打开开关，以及是否在支持的流量范围内。

步骤507：流量控制器判断通过后，接入层调用相关服务。

从硬件层面来说，为了解决目前的调用方管理依赖于项目涉及过程中要求调用对服务调用登记台账，比如a应用调用了b应用的b服务，实际有10个场景，但a应用只登记了1条调用关系(即只记录了一个场景)，这样调用关系就不准，无法了解实际有多少场景的问题，本申请提供一种用于实现所述服务迁移的流量控制方法中的全部或部分内容的电子设备的实施例，所述电子设备具体包含有如下内容：

图10为本申请实施例的电子设备9600的系统构成的示意框图。如图10所示，该电子设备9600可以包括中央处理器9100和存储器9140；存储器9140耦合到中央处理器9100。值得注意的是，该图10是示例性的；还可以使用其他类型的结构，来补充或代替该结构，以实现电信功能或其他功能。

在一实施例中，流量控制功能可以被集成到中央处理器中。其中，中央处理器可以被配置为进行如下控制：

步骤300：根据调用链识别当前所有场景，其中，场景名通过一调用链表示，所述调用链包括实现该场景的所有服务的调用字段；

可以理解的是，用调用链来区分和定义场景。调用链是“(应用名1+程序类名1)>(应用名2+程序类名2)>(应用名3+程序类名3)...>(应用名n+程序类名n)”这种格式。服务调用的数据包分为有数据包头和数据包体。数据包头包含了支持服务调用的技术字段，数据包体则是服务本身业务逻辑相关的字段。数据包头有预留空间，支持自定义字段，我们增加一个调用链路字段，用来存储调用链路，不同的调用链对应不同的场景，流量控制器通过调用链识别当前所有场景。

步骤301：对当前所有场景进行切分，得到第一当前场景调用群和第二当前场景调用群；

可以理解的是，在迁移过程中，第一服务器上的至少一个服务与迁移到第二服务器上的至少一个服务在一段时间内是同时存在的，灰度切流是逐步切换的过程。即第一服务器上的至少一个服务的流量逐步减少，迁移到第二服务器上的至少一个服务的流量逐步增加，但这两个服务器上的流量总量应该保持稳定的。那么在做流量监控时，要达到如下要求：

7)分别监控第一服务器上的至少一个服务以及迁移到第二服务器上的至少一个服务的流量，其流量的变化必须和切流计划一致。

8)监控第一服务器上的至少一个服务以及迁移到第二服务器上的至少一个服务的流量总和，这个应该是保持稳定的。

9)当监控到第一服务器上的至少一个服务以及迁移到第二服务器上的至少一个服务中任何一个出行大幅变化的时候，要立即判断这两个服务器的流量总和是否稳定。

因此，流量控制器将所有场景切分，得到第一当前场景调用群和第二当前场景调用群，第一当前场景调用群和第二当前场景调用群的流量是逐渐变化的。

步骤302：将所述第一当前场景调用群发送给第一服务器，所述第二当前场景调用群发送给第二服务器。

可以理解的是，流量控制器将切分后的第一当前场景调用群和第二当前场景调用群发送给第一服务器和第二服务器执行，直至第一服务器上的流量逐渐变为零，第一服务器上的流量逐渐达到流量总和。

从上述描述可知，本申请实施例提供的一种服务迁移的流量控制方法，在迁移过程中，流量控制器通过调用链识别场景，不同的调用链对应不同的场景，不需要对调用方系统进行改造，能够直接定位到具体的场景，对场景进行精确管理、精细切流，在保持客户体验不变的同时，确保系统运行稳定。

在另一个实施方式中，用于服务迁移的流量控制系统可以与中央处理器9100分开配置，例如可以将流量控制系统配置为与中央处理器9100连接的芯片，通过中央处理器的控制来实现服务迁移的流量控制。

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

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

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

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

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

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

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

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

本申请的实施例还提供能够实现上述实施例中的服务迁移的流量控制方法中全部步骤的一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的执行主体为服务器的流量控制方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：

步骤300：根据调用链识别当前所有场景，其中，场景名通过一调用链表示，所述调用链包括实现该场景的所有服务的调用字段；

可以理解的是，用调用链来区分和定义场景。调用链是“(应用名1+程序类名1)>(应用名2+程序类名2)>(应用名3+程序类名3)...>(应用名n+程序类名n)”这种格式。服务调用的数据包分为有数据包头和数据包体。数据包头包含了支持服务调用的技术字段，数据包体则是服务本身业务逻辑相关的字段。数据包头有预留空间，支持自定义字段，我们增加一个调用链路字段，用来存储调用链路，不同的调用链对应不同的场景，流量控制器通过调用链识别当前所有场景。

步骤301：对当前所有场景进行切分，得到第一当前场景调用群和第二当前场景调用群；

可以理解的是，在迁移过程中，第一服务器上的至少一个服务与迁移到第二服务器上的至少一个服务在一段时间内是同时存在的，灰度切流是逐步切换的过程。即第一服务器上的至少一个服务的流量逐步减少，迁移到第二服务器上的至少一个服务的流量逐步增加，但这两个服务器上的流量总量应该保持稳定的。那么在做流量监控时，要达到如下要求：

10)分别监控第一服务器上的至少一个服务以及迁移到第二服务器上的至少一个服务的流量，其流量的变化必须和切流计划一致。

11)监控第一服务器上的至少一个服务以及迁移到第二服务器上的至少一个服务的流量总和，这个应该是保持稳定的。

12)当监控到第一服务器上的至少一个服务以及迁移到第二服务器上的至少一个服务中任何一个出行大幅变化的时候，要立即判断这两个服务器的流量总和是否稳定。

因此，流量控制器将所有场景切分，得到第一当前场景调用群和第二当前场景调用群，第一当前场景调用群和第二当前场景调用群的流量是逐渐变化的。

步骤302：将所述第一当前场景调用群发送给第一服务器，所述第二当前场景调用群发送给第二服务器。

可以理解的是，流量控制器将切分后的第一当前场景调用群和第二当前场景调用群发送给第一服务器和第二服务器执行，直至第一服务器上的流量逐渐变为零，第一服务器上的流量逐渐达到流量总和。

从上述描述可知，本申请实施例提供的一种服务迁移的流量控制方法，在迁移过程中，流量控制器通过调用链识别场景，不同的调用链对应不同的场景，不需要对调用方系统进行改造，能够直接定位到具体的场景，对场景进行精确管理、精细切流，在保持客户体验不变的同时，确保系统运行稳定。

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

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

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

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

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