CN106899666B - 一种针对业务标识的数据处理方法及装置 - Google Patents

Abstract

本申请实施例公开了一种针对业务标识的数据处理方法及装置，包括：接收业务请求，确定业务请求携带的标识信息，作为第一标识信息；其中，标识信息，由标识管理设备针对各业务服务器所提供的不同业务集，按照预设的标识规则生成，确定所述第一标识信息所对应的业务集和业务事件，并确定所述业务请求自身所对应的业务集和业务事件，当确定出的业务事件以及业务集一致时，则在对业务请求进行处理后，向业务流程中的后一业务服务器发送携带有第一标识信息的中间业务请求。通过本方法，业务集标识和事件标识不受各业务服务器各自的规则影响，有效减少在业务流程中各业务服务器所生成的标识类数据的累积。

Description

一种针对业务标识的数据处理方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种针对业务标识的数据处理方法及装置。

背景技术

目前，业务提供方(如：网站)可向用户提供丰富的业务服务。

现有技术中，对于业务提供方而言，其后台通常设置有大量的业务服务器，这些服务器能够提供相应的业务功能。在实际应用中，为了增加业务多样性以及能够向用户提供更加完善的业务服务，业务提供方会向用户提供组合式的业务服务，组合式的业务服务通常由多个子业务构成(以下为便于描述，称为：业务集)，不同的业务服务器负责处理相应的子业务，在此基础上，当用户使用该业务集后，该业务集的各业务服务器将协作完成业务服务。

具体而言，如图1所示，针对某一业务集，当用户发出业务请求后，各业务服务器将按照业务流程的顺序进行业务处理，前一业务服务器的处理结果作为中间结果，传递给后一业务服务器，以此类推，直到完成对业务的处理。在进行业务处理的过程中，不同的业务服务器自身具有独立的处理规则和数据标准，从而，每一业务服务器在执行业务处理后，会生成相应的业务数据，以及能够反映业务属性的标识类数据。

然而，正是由于每一业务服务器均有自身独立的业务规则和数据标准，换言之，每一业务服务器在进行业务处理后，所生成的标识类数据在数据结构、数据内容、数据格式等方面往往并不相同，这些标识类数据将结合业务数据，一并发送给业务流程中的后续业务服务器，以便进行后续的业务处理过程。显然，每一业务服务器所生成的标识类数据都会逐渐累积，并传递至后一业务服务器中，这将会造成增加后续业务服务器的数据量，并不利于业务服务器的运行和维护。

发明内容

本申请实施例提供一种针对业务标识的数据处理方法及装置，用以解决现有技术中标识类数据不利于业务服务器的运行和维护的问题。

本申请实施例提供的一种针对业务标识的数据处理方法，包括：

接收业务请求；

确定所述业务请求携带的标识信息，作为第一标识信息；其中，所述标识信息，由标识管理设备针对各业务服务器所提供的不同业务集以及用以触发所述业务集的不同业务事件，按照预设的标识规则所生成；

确定所述第一标识信息所对应的业务集和业务事件，并确定所述业务请求自身所对应的业务集和业务事件；

当确定出的业务事件以及业务集一致时，则在对所述业务请求进行处理后，向业务流程中的后一业务服务器发送携带有所述第一标识信息的中间业务请求。

本申请实施例提供的另一种针对业务标识的数据处理方法，包括：

针对各业务服务器所提供的不同业务集以及用以触发所述业务集的不同业务事件，按照预设的标识规则，生成标识信息；

将生成的所述标识信息分发给各业务服务器，以使得每一业务服务器在接收到业务请求后，确定所述业务请求携带的标识信息作为第一标识信息，确定所述第一标识信息所对应的业务集和业务事件是否与所述业务请求所对应的业务集和业务事件相一致，确定一致时，则在对所述业务请求进行处理后，向业务流程中的后一业务服务器发送携带有所述第一标识信息的中间业务请求。

本申请实施例提供的一种业务处理装置，包括：

接收模块，接收业务请求；

标识确定模块，确定所述业务请求的标识信息，作为第一标识信息；其中，所述标识信息，针对各业务服务器所提供的不同业务集以及用以触发所述业务集的不同业务事件所生成；

确定模块，确定所述第一标识信息所对应的业务集和业务事件，并确定所述业务请求自身所对应的业务集和业务事件；

处理模块，当确定出的业务集一致时，则在对所述业务请求进行处理后，向第二业务服务器发送携带有所述第一标识信息的中间业务请求。

本申请实施例提供的另一种业务处理装置，包括：

生成模块，针对各业务服务器所提供的不同业务集以及用以触发所述业务集的不同业务事件，生成标识信息；

分发模块，将生成的所述标识信息分发给各业务服务器，以使得第一业务服务器在接收到业务请求后，确定所述业务请求携带的标识信息作为第一标识信息，确定所述第一标识信息所对应的业务集和业务事件是否与所述业务请求所对应的业务集和业务事件相一致，确定一致时，则在对所述业务请求进行处理后，向第二业务服务器发送携带有所述第一标识信息的中间业务请求。

本申请实施例提供一种针对业务标识的数据处理方法及装置，通过本方法：

针对业务提供方后台各业务服务器所提供的各业务集及能够触发相应业务集的各种业务事件，均生成对应的标识，即，标识信息，这里的标识信息具有全局性且与各业务服务器各自的标识标准无关，从而，各业务服务器在基于业务请求进行业务处理的过程中，会针对业务请求分配全局性的标识信息，换言之，当某一业务服务器针对携带有标识信息的业务请求进行处理后，按照业务流程向下一业务服务器发出的业务请求中，同样会携带该标识信息，全局性的标识信息将在整个业务流程中传递，显然，在不受各业务服务器标准的影响下，业务流程中，针对业务请求和业务数据的标识类数据有效减少。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为现有技术中业务集对应的各业务服务器的处理过程示意图；

图2a为本申请实施例提供的针对业务标识的数据处理方法所基于的架构示意图；

图2b为本申请实施例提供的针对业务标识的数据处理过程；

图3a为本申请实施例提供的业务服务器侧的针对业务标识的数据处理过程所基于的架构；

图3b为本申请实施例提供的业务服务器侧的针对业务标识的数据处理过程；

图4a为本申请实施例中在实际应用场景下的包含单一业务集的业务流程；

图4b为本申请实施例中在实际应用场景下的包含多个业务集的业务流程；

图5为本申请实施例提供的针对业务标识的数据处理装置结构示意图；

图6为本申请实施例提供的针对业务标识的数据处理装置结构示意图。

具体实施方式

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

作为本申请实施例所对应的实际场景，业务提供方会向用户提供不同的产品(其中，产品是指能够实现某种业务功能的业务组合，在本申请的下述实施例中，以“业务集”代指产品，这里不应理解为对本申请的限定)，产品常以相应的业务应用中的软件功能的方式提供给用户，从而用户通过应用便可以使用相应的产品。在用户使用产品的过程中，由于产品能够提供多种业务功能，那么，在业务提供方后台，针对产品中的功能，可能具有多个业务系统协同实现该产品的相应业务功能。

在此场景下，当用户使用该产品中的某项业务功能时，便可看作是触发了相应的业务事件，后台相应的业务系统将基于触发的业务事件进行业务处理，生成业务数据(可理解为中间业务结果)，并按照业务流程将生成的业务数据向后续的业务系统传递。但是，每一业务系统各自的业务处理规则通常不同，从而生成的业务数据在数据格式、数据结构、数据内容上也存在差异，在业务数据向后传递的过程中，后一业务系统在接收到前一业务系统传递的业务数据的基础上，才能够继续进行业务的处理，显然，随着传递次数的增加，业务数据的数量也在增加，使得在业务完成后，所生成的业务数据较为复杂，其中部分业务数据对于后续的业务系统而言，属于无用数据，也增加了数据维护的成本。

故在本申请实施例中，提供一种针对业务标识的数据处理方法，在用户触发业务事件后，对用户发出的业务请求分配全局性的业务集标识以及触发该业务集的业务事件的事件标识，上述标识可以在各业务系统间传递，也即，在上述标识的作用下，不同的业务系统无需针对业务数据再生成额外的标识性数据，从而减少数据维护的成本以及提升业务处理的便捷性。

需要说明的是，本申请实施例中所述的业务提供方，包括但不限于：能够提供组合式业务的网站、电信运营商、银行、数据中心等。其中，如图2a所示，为本申请实施例中标记数据生成过程所基于的架构，从图2a中可见，业务提供方后台的各业务服务器(也即，业务系统)，均可以采用服务器集群的架构，以便适应于实际应用中大量的业务请求，同时，该架构中还包括标识管理设备，其用于维护并管理标识信息。这里需要说明的是，在实际应用中，用于管理标识信息的标识管理设备可以是服务器、服务器集群、管理中心或具有标识信息管理、维护功能的功能单元、应用软件等，这里并不构成对本申请的限定。

基于图2a所示的架构，本申请实施例提供的业务处理过程如图2b所示，该过程具体包括以下步骤：

S201：针对各业务服务器所提供的不同业务集以及用以触发所述业务集的不同业务事件，生成标识信息。

如图2a所示，在本申请实施例中，标识信息可以由标识信息管理设备所生成。所述的标识信息管理设备(以下为便于描述，简称为：管理设备)，用于统一管理各标识信息。该管理设备独立运行，也即，管理设备并不参与业务的处理过程。

其中，所述标识信息包括：业务集标识，以及触发该业务集的业务事件所对应的事件标识。当然，所述的业务标识，具体可以是具有全局性的业务编码，如：产品码，这里的全局性是指针对同一产品而言，无论该产品由多少业务系统协同完成，其业务标识均固定，并不与各业务系统自身的编号标准相关。

类似地，所述的事件标识，也是具有全局性的事件编码，如：事件码，与上述业务标识相似，事件标识同样与各业务系统自身的标号标准无关。

S202：将生成的所述标识信息分发给各业务服务器，以使得第一业务服务器在接收到业务请求后，确定所述业务请求携带的标识信息作为第一标识信息，确定所述第一标识信息所对应的业务集和业务事件是否与所述业务请求所对应的业务集和业务事件相一致，确定一致时，则在对所述业务请求进行处理后，向第二业务服务器发送携带有所述第一标识信息的中间业务请求。

在管理设备生成了标识信息后，会将生成的标识信息分配给各个业务服务器，当然，在本申请实施例中，管理设备可采用配置信息的方式，将标识信息携带在该配置信息中，分配给各业务服务器。这里仅是一种分配的方式，并不应构成对本申请的限定。

对于每一业务服务器而言，在接收到了标识服务器分配的配置信息后，也就可以在实际的业务处理过程中，对业务请求和相应的业务数据进行标记。

通过上述步骤，针对业务提供方后台各业务服务器所提供的各业务集及能够触发相应业务集的各种业务事件，均生成对应的标识，即，标识信息，这里的标识信息具有全局性且与各业务服务器各自的标识标准无关，从而，各业务服务器在基于业务请求进行业务处理的过程中，会针对业务请求分配全局性的标识信息，换言之，当某一业务服务器针对携带有标识信息的业务请求进行处理后，按照业务流程向下一业务服务器发出的业务请求中，同样会携带该标识信息，全局性的标识信息将在整个业务流程中传递，显然，在不受各业务服务器标准的影响下，业务流程中，针对业务请求和业务数据的标识类数据有效减少。

对于上述内容而言，由于标识信息包括：业务集标识，以及触发该业务集的业务事件所对应的事件标识，那么，前述步骤中，生成标识信息，包括：针对每一业务集，确定能够触发该业务集的所有业务事件，根据预设的标识规则，生成该业务集所对应的业务集标识，以及该业务集对应的各业务事件的事件标识。

具体而言，标识服务器在生成业务集标识时，往往基于相应的业务集标识规则，下面以业务集标识为产品码的场景进行说明：

该场景下，所述预设的标识规则包括：基于发出业务请求的用户类别、业务场景、业务类别的业务集编码生成规则。进一步，按照预设的标识规则，生成该业务集所对应的业务集标识，包括：根据所述业务集编码生成规则，生成该业务集对应的业务集编码。

可见，在本申请实施例中，一个产品码中至少能够反映出使用该产品的用户(即，业务请求人)的身份、所使用的产品所对应的业务场景、所使用产品所属业务类别等信息。

如下表1所示，为实际应用中一种产品码的构成：

1～2位	3～4位	5～8位	9～20位
				用户类别	业务场景	细分场景	顺序号

表1

其中，用户类别反映了使用业务服务的用户的分类，不同的用户类别可以使用相应的字符进行表示，如：用户(使用UR表示)、商户(使用MC表示)、机构(使用PN表示)等。

业务场景反映了产品所属的业务类别，如：支付业务(使用51表示)、社交业务(使用20表示)、信用业务(使用24表示)、会员业务(使用62表示)等。

细分场景可理解为业务场景的进一步分类，如：对于支付业务而言，用户自己支付的场景使用030表示、他人代付的场景使用040表示、合并支付的场景使用050表示等。

顺序号可认为所起到的作用与流水号相似，可用于表示同一产品的不同版本，这里并不具体限定。

基于以上内容，在实际操作时，某一产品的产品码可以例如：“MC5103010000000000001”，显然，该产品码表示商户自己主动支付的支付产品。

与上述的产品码相类似，下面以事件标识为事件码的场景进行说明：

所述预设的标识规则包括：基于业务场景、事件类别的事件编码生成规则。进而，按照预设的标识规则，生成该业务集对应的各业务事件的事件标识，包括：针对每一业务事件，根据所述事件编码生成规则，生成该业务事件的事件编码。

如下表2所示，为实际应用中一种产品码的构成：

表2

与前述产品码相类似，其中，业务场景反映了产品所属的业务类别，而细分场景进一步在其所属类别的基础上的分类，这里的顺序号可以表示事件触发所对应的操作标号。

在实际操作时，某一产品的事件码可以例如：510301001，其表示在交易场景(即，51)、自己进行支付(即，030)的支付操作(即，001)事件。

当然，上述针对产品码和事件码的示例说明，仅是一种可行的方式，在实际应用中，产品码、事件码中包含的字符数量、字符所表明的含义、字符的组合顺序等可以根据实际应用的需要进行调整和改变，这里并不应理解为对本申请的限定。

需要说明的是，同一产品中可能包含多种业务功能，相应地，可以通过不同的事件来触发该产品中不同的业务功能，那么，对于事件而言，便可以看作是产品中最小的功能单位，所以，同一产品中对应多种事件，也就是说，同一产品码对应着至少一个事件码。

相应地，对于同一事件而言，如：个人支付事件，可能在多个产品中都可以触发该个人支付事件，在此情况下，同一事件也可能对应着多个产品。

以上内容是业务集标识和事件标识的生成过程及含义的说明，此外，在本申请实施例中，基于上述的业务集标识和事件标识，各业务服务器在进行业务处理的过程也会相应发生变化，故本申请实施例中另提供一种针对业务标识的数据处理方法。

这里需要说明的是，该应用方法所采用的架构如图3a所示，业务提供方后台的各业务系统，均可以采用服务器集群的架构，以便适应于实际应用中大量的业务请求。相应地，业务提供方可提供业务应用，该业务应用安装于用户所使用的终端内，从而，用户通过业务应用可以使用不同的业务集对应的业务服务。当然，这里所述的终端可包括但不限于：智能手机、平板电脑、智能手表等移动终端，或计算机等非移动终端。

此外，需要说明的是，针对图3a所示的架构，在本申请后续内容中的所提及的第一业务服务器和第二业务服务器，具体可以是在业务流程中相邻的两个业务服务器，例如：假设现有3个业务服务器A、B、C，某种业务服务需要按照业务服务器A至B再至C的顺序完成，那么，针对业务服务器A、B而言，第一服务器就可以是业务服务器A，第二服务器就可以是业务服务器B；针对业务服务器B、C而言，第一服务器就可以是业务服务器B，第二服务器就可以是业务服务器C。换言之，本申请中的第一服务器和第二服务器并非只限于2个服务器的场景。

基于图3a所示的架构，针对业务标识的数据处理方法如图3b所示，具体包括以下步骤：

S301，第一业务服务器接收业务请求。

在一种情况下，在本申请实施例中，所述的业务请求，可以由用户发出，例如：下单请求、支付请求、登录请求等等。在另一种情况下，所述的业务请求，还可以是业务流程中的前一业务服务器发送的中间业务请求。

上述两种情况并不构成对本申请的限定。

S302：确定所述业务请求携带的标识信息，作为第一标识信息。

其中，所述标识信息，针对各业务服务器所提供的不同业务集以及用以触发所述业务集的不同业务事件所生成。

所述标识信息，可参考本申请前述实施例中的内容，这里不再进行过多赘述。

需要说明的是，实际应用中，如果该业务请求由前一业务服务器发出，那么，该业务请求将携带标识信息，但是，第一业务服务器所接收到的该业务请求可能需要另一产品下的业务功能实现，又或者，该业务请求可能会触发不同的业务事件，一旦这样的情况出现，第一业务服务器将会针对该业务请求使用不同的标识信息进行标记。所以，当业务流程到达该业务服务器时，对于接收到业务请求的业务服务器而言，往往需要执行以下步骤。

S303：确定所述第一标识信息所对应的业务集和业务事件，并确定所述业务请求自身所对应的业务集和业务事件。

在实际应用场景下，业务请求自身携带有第一标识信息，则可以认为，该业务请求来源于业务流程中的前一业务服务器，且通过第一标识信息能够反映出相应的业务集和业务事件。

此外，业务服务器需要针对接收到的业务请求进行处理，此时，该业务请求既有可能会触发其他事件，以便继续进行业务处理；也有可能不会触发其他事件(该情况下，业务服务器仅按照原来的业务流程继续执行)。故在本步骤中，将分别确定出第一标识信息及业务请求所对应的业务集及其业务事件。

S304：当确定出的业务事件以及业务集一致时，则在对所述业务请求进行处理后，向第二业务服务器发送携带有所述第一标识信息的中间业务请求。

业务集以及业务事件一致，则表明该业务系统在处理业务请求时，并不会有新的事件触发也不会涉及其他的产品，而是按照业务流程继续执行。那么，该第一业务服务器还会按照业务流程，向第二业务服务器发出中间业务请求，此时，中间业务请求中将携带上述的第一标识信息。

以上步骤的过程，可参考如4a所示的业务过程。在图4a中可见，业务请求发送至业务服务器A，从而开始执行相应的业务流程，这里假设，该业务请求对应的产品码和事件码(即，第一标识信息)分别为：001和007，业务服务器A进行处理后，会生成中间业务请求发送给业务服务器B，这里的中间业务请求中携带了上述的产品码和事件码，显然，业务服务器B在处理中间业务请求时，并未启动其他的产品，也并未触发其他的事件，那么，业务服务器B在对中间业务请求进行处理后，会向业务服务器C发出携带有上述产品码和事件码的中间业务请求，以此类推，直到完成整个业务流程。

当然，基于图4a所示的示例，对于业务服务器A而言，是业务流程中首个接收到业务请求的业务服务器，可以理解地，由于该业务请求并非中间业务请求，所以其中并不会包含标识信息(即，不会包含产品码和事件码)，该业务请求需要由业务服务器A为其标记相应的标识信息。所以，在本申请实施例中，确定所述业务请求携带的标识信息，作为第一标识信息，具体包括：判断所述业务请求中是否携带业务集标识及事件标识，若是，则将携带的业务集标识及事件标识作为所述第一标识信息；否则，则确定该业务请求所对应的业务集以及业务事件，生成该业务请求所对应的业务集标识及事件标识，并作为所述第一标识信息。

除了以上业务流程之外，在实际应用中，还可能出现另一种业务流程：该业务流程中会调用不同的产品，同时会触发不同的事件，在此情况下，对于该业务流程中的某一业务服务器而言，其接收到的业务请求所对应的产品码和事件码，将与该业务请求所携带的产品码和事件码不一致，故当确定出的业务事件以及业务集不一致时，所述方法还包括：确定该业务请求所对应的业务集以及业务事件，根据已生成的与各业务集相对应的业务集标识，以及与各业务事件所对应的事件标识，生成该业务请求所对应的业务集标识及事件标识，作为第二标识信息。

该业务流程如图4b所示，从图4b中可见，业务服务器A在对业务请求进行处理后，调用了某产品(该产品的产品码为0001)同时触发了相应的事件(该事件的事件码为007)，业务服务器A针对业务请求进行处理后，按照业务流程，将生成的中间业务请求发送给业务服务器B，此时，业务服务器为了处理该中间业务请求，调用了新的产品(该产品的产品码为0002)并触发了新的事件(该事件的事件码为008)，同样的，业务服务器B将向业务服务器C发出中间业务请求，这里不再赘述。

从上述过程中可以看出，在业务流程中的每一业务服务器，其会将前一业务服务器和自身的产品码和事件码保存，并只将自身的产品码和事件码发送给后一业务服务器。

这样的方式不仅能够减少业务流程中所生成的数据的数量，也能够方便地追踪识别完整的业务链。

以上为本申请实施例提供的针对业务标识的数据处理方法，基于同样的思路，本申请实施例还提供一种针对业务标识的数据处理装置，如图5所示。该装置包括：

接收模块501，接收业务请求；

标识确定模块502，确定所述业务请求携带的标识信息，作为第一标识信息；其中，所述标识信息，针对各业务服务器所提供的不同业务集以及用以触发所述业务集的不同业务事件所生成；

确定模块503，确定所述第一标识信息所对应的业务集和业务事件，并确定所述业务请求自身所对应的业务集和业务事件；

处理模块504，当确定出的业务事件以及业务集一致时，则在对所述业务请求进行处理后，向第二业务服务器发送携带有所述第一标识信息的中间业务请求。

所述标识信息包括：业务集标识，以及触发该业务集的业务事件所对应的事件标识。

所述标识确定模块502，判断所述业务请求中是否携带业务集标识及事件标识，若是，则将携带的业务集标识及事件标识作为所述第一标识信息；否则，则确定该业务请求所对应的业务集以及业务事件，生成该业务请求所对应的业务集标识及事件标识，并作为所述第一标识信息。

当确定出的业务事件以及业务集不一致时，所述标识确定模块502，确定该业务请求所对应的业务集以及业务事件，根据已生成的与各业务集相对应的业务集标识，以及与各业务事件所对应的事件标识，生成该业务请求所对应的业务集标识及事件标识，作为第二标识信息。

所述装置还包括：存储处理模块505，存储所述第一标识信息及第二标识信息，向所述第二业务服务器发送携带有所述第二标识信息的中间业务请求。

在管理设备侧，本申请实施例还提供一种针对业务标识的数据处理装置，如图6所示，包括：

生成模块601，针对各业务服务器所提供的不同业务集以及用以触发所述业务集的不同业务事件，生成标识信息；

分发模块602，将生成的所述标识信息分发给各业务服务器，以使得第一业务服务器在接收到业务请求后，确定所述业务请求携带的标识信息作为第一标识信息，确定所述第一标识信息所对应的业务集和业务事件是否与所述业务请求所对应的业务集和业务事件相一致，确定一致时，则在对所述业务请求进行处理后，向第二业务服务器发送携带有所述第一标识信息的中间业务请求。

所述标识信息包括：业务集标识，以及触发该业务集的业务事件所对应的事件标识。

所述生成模块601，针对每一业务集，确定能够触发该业务集的所有业务事件，根据预设的标识规则，生成该业务集所对应的业务集标识，以及该业务集对应的各业务事件的事件标识。

所述预设的标识规则包括：基于发出业务请求的用户类别、业务场景、业务类别的业务集编码生成规则；所述生成模块601，根据所述业务集编码生成规则，生成该业务集对应的业务集编码；

所述预设的标识规则包括：基于业务场景、事件类别的事件编码生成规则；所述生成模块601，针对每一业务事件，根据所述事件编码生成规则，生成该业务事件的事件编码。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device，PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

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

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

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

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

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

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

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

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

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

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

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

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

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

Claims (18)

1.一种针对业务标识的数据处理方法，其特征在于，包括：

第一业务服务器接收业务请求；

确定所述业务请求携带的标识信息，作为第一标识信息；其中，所述标识信息，针对各业务服务器所提供的不同业务集以及用以触发所述业务集的不同业务事件所生成；

确定所述第一标识信息所对应的业务集和业务事件，并确定所述业务请求自身所对应的业务集和业务事件；

当确定出的业务事件以及业务集一致时，则在对所述业务请求进行处理后，向第二业务服务器发送携带有所述第一标识信息的中间业务请求。

2.如权利要求1所述的方法，其特征在于，所述标识信息包括：业务集标识，以及触发该业务集的业务事件所对应的事件标识。

3.如权利要求2所述的方法，其特征在于，确定所述业务请求携带的标识信息，作为第一标识信息，具体包括：

判断所述业务请求中是否携带业务集标识及事件标识；

若是，则将携带的业务集标识及事件标识作为所述第一标识信息；

否则，则确定该业务请求所对应的业务集以及业务事件，生成该业务请求所对应的业务集标识及事件标识，并作为所述第一标识信息。

4.如权利要求2所述的方法，其特征在于，当确定出的业务事件以及业务集不一致时，所述方法还包括：

确定接收的所述业务请求所对应的业务集以及业务事件；

根据已生成的与各业务集相对应的业务集标识，以及与各业务事件所对应的事件标识，生成该业务请求所对应的业务集标识及事件标识，作为第二标识信息。

5.如权利要求4所述的方法，其特征在于，所述方法还包括：

存储所述第一标识信息及第二标识信息；

向所述第二业务服务器发送携带有所述第二标识信息的中间业务请求。

6.一种针对业务标识的数据处理方法，其特征在于，包括：

针对各业务服务器所提供的不同业务集以及用以触发所述业务集的不同业务事件，生成标识信息；

将生成的所述标识信息分发给各业务服务器，以使得第一业务服务器在接收到业务请求后，确定所述业务请求携带的标识信息作为第一标识信息，确定所述第一标识信息所对应的业务集和业务事件是否与所述业务请求所对应的业务集和业务事件相一致，确定一致时，则在对所述业务请求进行处理后，向第二业务服务器发送携带有所述第一标识信息的中间业务请求。

7.如权利要求6所述的方法，其特征在于，所述标识信息包括：业务集标识，以及触发该业务集的业务事件所对应的事件标识。

8.如权利要求7所述的方法，其特征在于，生成标识信息，具体包括：

针对每一业务集，确定能够触发该业务集的所有业务事件；

根据预设的标识规则，生成该业务集所对应的业务集标识，以及该业务集对应的各业务事件的事件标识。

9.如权利要求8所述的方法，其特征在于，所述预设的标识规则包括：基于发出业务请求的用户类别、业务场景、业务类别的业务集编码生成规则；

按照预设的标识规则，生成该业务集所对应的业务集标识，具体包括：

根据所述业务集编码生成规则，生成该业务集对应的业务集编码；

所述预设的标识规则包括：基于业务场景、事件类别的事件编码生成规则；

按照预设的标识规则，生成该业务集对应的各业务事件的事件标识，具体包括：

针对每一业务事件，根据所述事件编码生成规则，生成该业务事件的事件编码。

10.一种针对业务标识的数据处理装置，其特征在于，包括：

接收模块，接收业务请求；

标识确定模块，确定所述业务请求的标识信息，作为第一标识信息；其中，所述标识信息，针对各业务服务器所提供的不同业务集以及用以触发所述业务集的不同业务事件所生成；

确定模块，确定所述第一标识信息所对应的业务集和业务事件，并确定所述业务请求自身所对应的业务集和业务事件；

处理模块，当确定出的业务事件以及业务集一致时，则在对所述业务请求进行处理后，向第二业务服务器发送携带有所述第一标识信息的中间业务请求。

11.如权利要求10所述的装置，其特征在于，所述标识信息包括：业务集标识，以及触发该业务集的业务事件所对应的事件标识。

12.如权利要求11所述的装置，其特征在于，所述标识确定模块，判断所述业务请求中是否携带业务集标识及事件标识，若是，则将携带的业务集标识及事件标识作为所述第一标识信息；否则，则确定该业务请求所对应的业务集以及业务事件，生成该业务请求所对应的业务集标识及事件标识，并作为所述第一标识信息。

13.如权利要求12所述的装置，其特征在于，当确定出的业务事件以及业务集不一致时，所述标识确定模块，确定该业务请求所对应的业务集以及业务事件，根据已生成的与各业务集相对应的业务集标识，以及与各业务事件所对应的事件标识，生成该业务请求所对应的业务集标识及事件标识，作为第二标识信息。

14.如权利要求13所述的装置，其特征在于，所述装置还包括：存储处理模块，存储所述第一标识信息及第二标识信息，向所述第二业务服务器发送携带有所述第二标识信息的中间业务请求。

15.一种针对业务标识的数据处理装置，其特征在于，包括：

生成模块，针对各业务服务器所提供的不同业务集以及用以触发所述业务集的不同业务事件，生成标识信息；

分发模块，将生成的所述标识信息分发给各业务服务器，以使得第一业务服务器在接收到业务请求后，确定所述业务请求携带的标识信息作为第一标识信息，确定所述第一标识信息所对应的业务集和业务事件是否与所述业务请求所对应的业务集和业务事件相一致，确定一致时，则在对所述业务请求进行处理后，向第二业务服务器发送携带有所述第一标识信息的中间业务请求。

16.如权利要求15所述的装置，其特征在于，所述标识信息包括：业务集标识，以及触发该业务集的业务事件所对应的事件标识。

17.如权利要求16所述的装置，其特征在于，所述生成模块，针对每一业务集，确定能够触发该业务集的所有业务事件，根据预设的标识规则，生成该业务集所对应的业务集标识，以及该业务集对应的各业务事件的事件标识。

18.如权利要求17所述的装置，其特征在于，所述预设的标识规则包括：基于发出业务请求的用户类别、业务场景、业务类别的业务集编码生成规则；所述生成模块，根据所述业务集编码生成规则，生成该业务集对应的业务集编码；

所述预设的标识规则包括：基于业务场景、事件类别的事件编码生成规则；所述生成模块，针对每一业务事件，根据所述事件编码生成规则，生成该业务事件的事件编码。