CN113285888B - 多业务系统多数据中心分流方法、装置、设备及介质 - Google Patents

Abstract

本申请公开了一种多业务系统多数据中心分流方法、装置、设备及介质，每个业务系统在数据中心均部署有具备业务逻辑处理功能的业务系统单元，分流方法应用于全交易链路上的任意业务系统中的接入层，分流方法包括：在接收到请求发起方发送的交易报文的情况下，获取由分流控制中心确定的第一分流策略信息组；根据本业务系统适用的分流维度，在第一分流策略信息组中选择本业务系统适用的分流策略信息；根据本业务系统适用的分流策略信息，在本业务系统部署在多数据中心的多个业务系统单元中，为交易报文确定实际执行业务逻辑处理的单元。本申请公开的方法，各业务系统可以依据一套分流策略信息组进行分流，使得分流决策一致，减少出现跨中心调用。

Description

多业务系统多数据中心分流方法、装置、设备及介质

技术领域

本申请属于计算机技术领域，尤其涉及一种多业务系统多数据中心分流方法、装置、设备及介质。

背景技术

随着业务需求的增长，越来越多的企业部署多个数据中心，通过多个数据中心可以处理复杂的业务场景。

在相关技术中，为了通过多个数据中心进行业务处理，可以根据业务请求的发起方附带的地理位置进行分流，就近接入请求发起方所在地区的数据中心。还可以探测可用的数据中心的时延，接入时延较小的数据中心。

在上述方案中，需要依赖请求发起方的地理位置，而有些业务场景下并没有请求发起方的地理位置，导致方案的通用性不好。而且，请求发起方的地理位置不稳定，如果出现请求发起方从一个区域到达另一个区域，那么会导致在进行业务处理时增加跨中心调用的情况。

另外，对于探测可用的数据中心的时延的方案，由于探测的结果有一定的时延，因此会导致对数据中心处理业务的性能带来一定影响。

发明内容

本申请实施例提供一种多业务系统多数据中心分流方法、装置、设备及介质，能够解决方案的通用性不好、增加出现跨中心调用的情况以及影响数据中心处理业务的性能的技术问题。

第一方面，本申请实施例提供一种面向全交易链路的多业务系统多数据中心分流方法，每个所述业务系统在所述数据中心均部署有具备业务逻辑处理功能的业务系统单元，所述分流方法应用于所述全交易链路上的任意业务系统中的接入层，所述分流方法包括：

在接收到请求发起方发送的交易报文的情况下，获取由分流控制中心确定的第一分流策略信息组；

根据本业务系统适用的分流维度，在所述第一分流策略信息组中选择本业务系统适用的分流策略信息；

根据本业务系统适用的分流策略信息，在本业务系统部署在所述多数据中心的多个业务系统单元中，为所述交易报文确定实际执行业务逻辑处理的单元。

第二方面，本申请实施例提供一种分流策略分配方法，应用于分流控制中心，所述分流方法包括：

接收全交易链路上的任意业务系统中的接入层发送的交易要素；

根据所述交易要素，确定所述业务系统适用的分流策略信息组；

将所述分流策略信息组发送至所述接入层。

第三方面，本申请实施例提供一种面向全交易链路的多业务系统多数据中心分流装置，每个所述业务系统在所述数据中心均部署有具备业务逻辑处理功能的业务系统单元，所述分流装置应用于所述全交易链路上的任意业务系统中的接入层，所述分流装置包括：

获取模块，用于在接收到请求发起方发送的交易报文的情况下，获取由分流控制中心确定的第一分流策略信息组；

选择模块，用于根据本业务系统适用的分流维度，在所述第一分流策略信息组中选择本业务系统适用的分流策略信息；

第一确定模块，用于根据本业务系统适用的分流策略信息，在本业务系统部署在所述多数据中心的多个业务系统单元中，为所述交易报文确定实际执行业务逻辑处理的单元。

第四方面，本申请实施例提供一种分流策略分配装置，应用于分流控制中心，所述分流装置包括：

接收模块，用于接收全交易链路上的任意业务系统中的接入层发送的交易要素；

第二确定模块，用于根据所述交易要素，确定所述业务系统适用的分流策略信息组；

第二发送模块，用于将所述分流策略信息组发送至所述接入层。

第五方面，本申请实施例提供了一种计算机存储介质，所述计算机存储介质上存储有计算机程序指令，所述计算机程序指令被处理器执行时实现第一方面提供的多业务系统多数据中心分流方法或者第二方面提供分流策略分配装置方法。

本申请实施例的多业务系统多数据中心分流方法、装置、设备及介质，在接收到请求发起方发送的交易报文的情况下，获取由分流控制中心确定的第一分流策略信息组；然后，根据本业务系统适用的分流维度，在所述第一分流策略信息组选择本业务系统适用的分流策略信息；根据本业务系统适用的分流策略信息，在本业务系统部署在所述多数据中心的多个业务系统单元中，为所述交易报文确定实际执行业务逻辑处理的单元，以实现数据分流。首先，由于本申请实施例是基于第一分流策略信息组进行分流，与请求发起方的地理位置无关，因此，本申请实施例可以适用于没有请求发起方的地理位置的业务场景，提升方案的通用性。其次，各业务系统均可以按此方法实现分流，各业务系统可以依据一套分流策略信息组(即第一分流策略信息组)进行分流，使得各业务系统的分流决策一致，以减少交易在跨系统调用的场景中的跨中心调用的情况。再次，由于本申请实施例不存在探测结果的时延问题，而是接入层根据第一分流策略信息组进行分流，避免出现由于探测结果的时延而对数据中心处理业务的性能带来影响。

附图说明

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

图1是本申请提供的一实施例的系统架构图。

图2是本申请第二方面提供的一种多业务系统多数据中心分流方法的一个实施例的流程示意图。

图3是本申请第二方面提供的一种分流策略分配方法的一个实施例的流程示意图。

图4是本申请第三方面提供的一种多业务系统多数据中心分流装置的一个实施例的结构示意图。

图5是本申请第四方面提供的一种分流策略分配装置的一个实施例的结构示意图。

图6是本申请第四方面提供的一种计算机设备的一个实施例的结构示意图。

具体实施方式

下面将详细描述本申请的各个方面的特征和示例性实施例，为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本申请进行进一步详细描述。应理解，此处所描述的具体实施例仅意在解释本申请，而不是限定本申请。对于本领域技术人员来说，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

在相关技术中，可以通过如下两种方案来实现多个数据中心的业务处理：

第一种方案：在多个地区分别部署数据中心，比如，建设异地的多个数据中心，将各省市、地区划分到不同的数据中心。通过请求发起方附带的地理位置对请求进行分流，就近接入请求发起方所在地区的数据中心。

第二种方案：对可用的数据中心进行实时探测，动态生成路由表；定时获取可用的各个数据中心的路由配置，并探测到可用的各个数据中心的时延，选择时延较小的数据中心处理业务。

对于第一种方案，适用于对地理位置信息有较强依赖的业务场景，比如外卖场景，商户、骑手、消费者都提供了地理位置信息，且大都处在一个区域。此外，考虑到用户体验的重要性，数据一致性向服务可用性做了妥协。但是有些场景(比如支付场景或者转账场景)对于地理位置信息并不具有很强的强依赖，该场景对于数据一致性的要求也更高。如此，导致该方案的通用性不好。

而且，在第一种方案中，地理位置不稳定，有可能出现漂移，即地理位置信息发生了变化。如果出现请求发起方从一个区域到达另一个区域，那么会导致在进行业务处理时增加跨中心调用的情况。

而跨中心调用存在较多隐患，例如：由于增加异地传输，全链路的交易时延大幅度增加，导致系统吞吐量降低、用户体验变差等；多中心数据同步存在延迟，可能引发数据一致性问题。

对于第二种方案，即使是实时探测数据中心，探测的结果也有一定的时延，导致对数据中心处理业务的性能带来一定影响。比如，如果数据中心出现故障或响应慢，无法及时调整路由规则时，会影响到部分正常交易。

基于上述对相关技术中的方案的分析，在异地传输时延客观存在的情况下，需要从总体架构上进行方案设计。如何设计一个多数据中心的分流控制机制，统一进行分流调度，以达到减少跨中心调用的目的，这是关键需求和难点。

本申请提供一种面向全交易链路的多业务系统多数据中心分流方法，每个业务系统在数据中心均部署有具备业务逻辑处理功能的业务系统单元，业务系统单元也可以称为业务系统实例。

下面先通过图1说明多业务系统多数据中心。

如图1所示，全交易链路包括A业务系统、B业务系统以及C业务系统。在多数据中心中，A业务系统、B业务系统以及C业务系统分别部署有两个单元。每个数据中心包括一个分流控制中心，分流控制中心用于分配分流策略信息组。分流策略信息组包括至少一个分流维度的分流策略信息。其中，分流维度可以为机构、商户以及用户等。

基于上述对多业务系统多数据中心，下面对多业务系统多数据中心分流方法进行说明。

多业务系统多数据中心分流方法应用于全交易链路上的任意业务系统中的接入层。其中，同一个系统(例如全渠道系统)在不同的交易场景，分流方法可以应用于可能是第一个业务系统，或者第二个业务系统，或者其他任意的业务系统链路。比如，分流方法可以应用于图1所示的A业务系统、B业务系统或者C业务系统。

图2是本申请提供的一种多业务系统多数据中心分流方法的一个实施例的流程示意图。如图2所示，多业务系统多数据中心分流方法包括：

S102，在接收到请求发起方发送的交易报文的情况下，获取由分流控制中心确定的第一分流策略信息组。

其中，第一分流策略信息组中包括至少一个分流维度的分流策略信息。

在一个具体示例中，全交易链路的多数据中心为三个数据中心，分别是第一数据中心、第二数据中心和第三数据中心。

(1)当第一分流策略信息组中的分流维度包括机构时，分流依据可以为机构编码(Identity Document，ID)，第一分流策略信息组中机构维度的分流策略信息具体可以包括：

在机构ID尾号在0-2范围内的情况下，交易报文分发至第一数据中心进行处理，以及第二数据中心同时作为第一数据中心的备份，那么在第一数据中心不可用时交易报文分发至第二数据中心进行处理；

在机构ID尾号在3-5范围内的情况下，交易报文分发至第二数据中心进行处理，以及第三数据中心同时作为第二数据中心的备份，那么在第二数据中心不可用时交易报文分发至第三数据中心；

在机构ID尾号在6-9范围内的情况下，交易报文分发至第三数据中心进行处理，以及第一数据中心同时作为第三数据中心的备份，那么在第三数据中心不可用时交易报文分发至第一数据中心。

(2)当第一分流策略信息组中的分流维度包括商户时，分流依据可以为商户ID，第一分流策略信息组中商户维度的分流策略信息具体可以包括：

在商户ID的第X至Y位在00-39范围内的情况下，交易报文分发至第一数据中心，第二数据中心同时作为第一数据中心的备份，那么在第一数据中心不可用时交易报文分发至第二数据中心；

在商户ID的第X至Y位在40-69范围内的情况下，交易报文分发至第二数据中心，以及第三数据中心同时作为第二数据中心的备份，那么在第二数据中心不可用时交易报文分发至第三数据中心；

在商户ID在第X至Y位在70-99范围内的情况下，交易报文分发至第三数据中心，以及第一数据中心同时作为第三数据中心的备份，那么在第三数据中心不可用时交易报文分发至第一数据中心。

(3)当第一分流策略信息组中的分流维度包括用户时，分流依据可以为用户(比如持有银行卡的用户)ID，第一分流策略信息组中用户维度的分流策略信息具体可以包括：

在用户ID前3位在C00-C33范围内的情况下，交易报文分发至第一数据中心，以及第二数据中心同时作为第一数据中心的备份，那么在第一数据中心不可用时交易报文分发至第二数据中心；

在用户ID前3位在C34-C66范围内的情况下，交易报文分发至第二数据中心，以及第三数据中心同时作为第二数据中心的备份，那么在第二数据中心不可用时交易报文分发至第三数据中心；

在用户ID前3位为C67-C99范围内的情况下，交易报文分发至第三数据中心，以及第一数据中心同时作为第三数据中心的备份，那么在第三数据中心不可用时交易报文分发至第一数据中心。

在S102之后，多业务系统多数据中心分流方法还包括：

S104，根据本业务系统适用的分流维度，在第一分流策略信息组中选择本业务系统适用的分流策略信息；

S106，根据本业务系统适用的分流策略信息，在本业务系统部署在多数据中心的多个业务系统单元中，为交易报文确定实际执行业务逻辑处理的单元。

在一个具体示例中，假设本业务系统适用的分流维度为用户，那么第一分流策略信息组中的用户维度的分流策略信息即为本业务系统适用的分流策略信息。然后，根据用户维度的分流策略信息，为交易报文确定实际执行业务逻辑处理的单元。

假设用户维度的分流策略信息为上述示例中的用户维度的分流策略信息，那么，当交易报文中的用户ID前3位在C00-C33范围时，确定实际执行业务逻辑处理的单元为第一数据中心中的单元；当交易报文中的用户ID前3位在C34-C66范围时，确定实际执行业务逻辑处理的单元为第二数据中心中的单元；当交易报文中的用户ID前3位在C67-C99范围时，确定实际执行业务逻辑处理的单元为第三数据中心中的单元。

在本业务系统的接入层为交易报文确定实际执行业务逻辑处理的单元之后；本业务系统的服务层按本地调用优先原则，调用下游业务系统进行业务处理。

需要说明的是，多业务系统中的每个业务系统适用的分流维度可以根据业务需求预先配置。

还需要说明的是，本业务系统是执行分流方法的业务系统。比如，该分流方法应用于A业务系统的接入层，那么本业务系统为A业务系统。

在本申请实施例中，由于本申请实施例是基于第一分流策略信息组进行分流，与请求发起方的地理位置无关，因此，本申请实施例可以适用于没有请求发起方的地理位置的业务场景，提升方案的通用性。

其次，各业务系统均可以按此方法实现分流，使得各业务系统可以依据一套分流策略信息组(即第一分流策略信息组)进行分流，如此，各业务系统的分流决策一致，不允许各业务系统分别设置分流维度。例如用户发起的交易报文按统一的分流策略(如持卡人ID)，不允许自行设定分流策略，具体不允许自行设定按GPS定位、手机号、身份证号等设定分流策略。如此，可以减少交易在跨系统调用的场景中的跨中心调用的情况。

再次，由于本申请不存在探测结果的时延问题，而是接入层根据第一分流策略信息组进行分流，避免出现由于探测结果的时延而对数据中心处理业务的性能带来影响。

在一些情况下，第一分流策略信息组中不包括本业务系统适用的分流策略信息，比如，前序交易过程中的交易要素不完备导致第一分流策略信息组中的分流维度缺失。

为了完善第一分流策略信息组，在本申请的一个或多个实施例中，S102之后，多业务系统多数据中心分流方法还可以包括：

若第一分流策略信息组中不包括本业务系统适用的分流策略信息，则根据交易报文中的交易要素，调用分流控制中心，并对第一分流策略信息组中的分流策略信息进行补充，以使补充后的第一分流策略信息组中包括本业务系统适用的分流策略信息。

下面对如何补充第一分流策略信息组中的分流策略信息进行具体说明。

根据交易报文中的交易要素，调用分流控制中心，并对第一分流策略信息组中的分流策略信息进行补充，具体可以包括：

向分流控制中心发送交易要素；

接收分流控制中心根据交易要素发送的第二分流策略信息组；

将第二分流策略信息组添加至第一分流策略信息组中，得到补充后的第一分流策略信息组，其中，第二分流策略信息组包括本业务系统适用的分流策略信息。

比如，本业务系统适用的分流策略信息为机构维度的分流策略信息，但是第一分流策略信息组中仅有用户维度的分流策略信息，没有本业务系统适用的分流策略信息。在此情况下，接入层可以将交易报文中的机构ID发送至分流控制中心，使得分流控制中心根据机构ID，确定第二分流策略信息组，第二分流策略信息组中包括机构维度的分流策略信息。

在接入层接收到第二分流策略信息组之后，将第二分流策略信息组添加至第一分流策略信息组中，使得第一分流策略信息组中不仅包括用户维度的分流策略信息，还包括机构维度的分流策略信息。

如此，通过对第一分流策略信息组进行补充，使得第一分流策略信息组中包括本业务系统适用的分流策略信息。

下面对本申请实施例进行示例性说明。

(1)如果初始化的交易要素较为完整，那么根据交易要素获取的第一分流策略信息组也比较完整，后续不需要对第一分流策略信息组进行补充。

比如，交易维度总共包括用户、机构和商户这三个分流维度，初始化的交易要素包括用户ID、机构ID和商户ID，即初始化的交易要素是完整的。那么，分流控制中心根据完整的交易要素，获取第一分流策略信息组，并且第一分流策略信息组中包括完整的分流维度的分流策略信息。也就是说第一分流策略信息组中已经包括各个分流维度的分流策略信息，不会出现分流维度缺失的情况。

(2)如果初始化的交易要素不完整，那么第一分流策略信息组中会出现分流维度缺失的情况，则后续发起交易时获得完整的交易要素，那么第二次可以补全第一分流策略信息组，后续可以不涉及补全。

比如，交易维度总共包括用户、机构和商户这三个分流维度，而初始化的交易要素仅包括用户ID，那么根据初始化的交易要素获取到的第一分流策略信息组中仅包括用户维度的分流策略信息，缺少机构维度和商户维度的分流策略信息。

在后续发起交易时获取完整的交易要素，即还获取到机构ID和商户ID，并根据该交易要素，获取第二分流策略信息组，第二分流策略信息组中包括机构维度的分流策略信息以及商户维度的分流策略信息。将第二分流策略信息组添加至第一分流策略信息组中，得到补全的第一分流策略信息组。

(3)如果初始化的交易要素不完整，那么第一分流策略信息组中会出现分流维度缺失的情况，则后续向全交易链路的系统发起交易报文，以及全交易链路上的业务系统受理交易报文时，发现第一分流策略信息组中没有本业务系统适用的分流维度的分流策略信息，则根据交易要素调用分流控制中心补充第一分流策略信息组。

比如，交易维度总共包括用户、机构和商户这三个分流维度，而第一分流策略信息组中仅包括用户维度的分流策略信息，缺少本业务系统适用的分流维度(即商户)。

在后续发起交易时获取商户ID，并根据商户ID，获取到第二分流策略信息组，第二分流策略信息组中包括商户维度的分流策略信息。然后，将第二分流策略信息组添加至第一分流策略信息组中，得到补全的第一分流策略信息组。此时，第一分流策略信息组中缺少机构维度。在需要用到机构维度的分流策略信息时，还需要再次调用分流控制中心，并向第一分流策略信息组中补充机构维度的分流策略信息。

(4)如果初始化的交易要素不完整，那么第一分流策略信息组中会出现分流维度缺失的情况。但是，如果第一分流策略信息组中包括本业务系统适用的分流策略信息，则不需要补充第一分流策略信息组。

交易维度总共包括用户、机构和商户这三个分流维度，而第一分流策略信息组中仅包括用户维度的分流策略信息。但是，本业务系统适用的分流维度为用户维度，则不需要补充第一分流策略信息组。

(5)如果交易报文中没有交易要素，也没有分流策略信息组，则本业务系统的接入层在多数据中心的多个业务系统单元中，为交易报文确定实际执行业务逻辑处理的单元为本地数据中心中的单元。那么，本业务系统的服务层调用本地数据中心中的单元进行业务处理。

在本申请的一个或多个实施例中，对分流策略信息组中的分流策略信息进行补充之后，多业务系统多数据中心分流方法还可以包括：

将补充后的第一分流策略信息组发送至请求发起方，以使请求发起方下一次发送相关联的交易报文时向接入层发送补充后的第一分流策略信息组。

本申请第二方面还提供一种分流策略分配方法，应用于分流控制中心。图3是本申请第二方面提供的一种分流策略分配方法的一个实施例的流程示意图。如图3所示，分流策略分配方法包括：

S202，接收全交易链路上的任意业务系统中的接入层发送的交易要素；

S204，根据交易要素，确定业务系统适用的分流策略信息组；

S206，将分流策略信息组发送至接入层。

其中，分流策略信息可以是上述的第一分流策略信息或者上述的第二分流策略信息。分流策略信息可以用于确定业务系统适用的分流策略信息，或者用于对已有的分流策略信息组进行补充。

作为一个具体示例，在S204中，如果交易要素为机构ID，那么第二分流策略信息组中包括机构维度的分流策略信息；如果交易要素为用户ID，那么第二分流策略信息组中包括用户维度的分流策略信息；如果交易要素为商户ID，那么第二分流策略信息组中包括商户维度的分流策略信息。

在本申请实施例中，通过分流控制中心为多业务系统多数据中心分配分流策略信息组，各业务系统可以依据一套分流策略信息组进行分流，使得各业务系统的分流决策一致，以减少交易在跨系统调用的场景中的跨中心调用的情况。其次，本申请实施例是基于分流策略信息组进行分流，与请求发起方的地理位置无关，因此，本申请实施例可以适用于没有请求发起方的地理位置的业务场景，提升方案的通用性。再次，由于本申请实施例在进行分流时不存在探测结果的时延问题，而是接入层根据第一分流策略信息组进行分流，避免出现由于探测结果的时延而对数据中心处理业务的性能带来影响。

本申请第三方面还提供一种面向全交易链路的多业务系统多数据中心分流装置，每个业务系统在数据中心均部署有具备业务逻辑处理功能的业务系统单元，分流装置应用于全交易链路上的任意业务系统中的接入层。

图4是本申请第三方面提供的一种多业务系统多数据中心分流装置的一个实施例的结构示意图。

如图4所示，多业务系统多数据中心分流装置300包括：

获取模块302，用于在接收到请求发起方发送的交易报文的情况下，获取由分流控制中心确定的第一分流策略信息组；

选择模块304，用于根据本业务系统适用的分流维度，在第一分流策略信息组中选择本业务系统适用的分流策略信息；

第一确定模块306，用于根据本业务系统适用的分流策略信息，在本业务系统部署在多数据中心的多个业务系统单元中，为交易报文确定实际执行业务逻辑处理的单元。

在本申请实施例中，由于本申请实施例是基于第一分流策略信息组进行分流，与请求发起方的地理位置无关，因此，本申请实施例可以适用于没有请求发起方的地理位置的业务场景，提升方案的通用性。

其次，各业务系统均可以按此方法实现分流，各业务系统可以依据一套分流策略信息组(即第一分流策略信息组)进行分流，使得各业务系统的分流决策一致，不允许各业务系统分别设置分流维度，可以减少交易在跨系统调用的场景中的跨中心调用的情况。

再次，由于本申请不存在探测结果的时延问题，而是接入层根据第一分流策略信息组进行分流，避免出现由于探测结果的时延而对数据中心处理业务的性能带来影响。

在本申请的一个或多个实施例中，多业务系统多数据中心分流装置300还可以包括：

调用模块，用于若第一分流策略信息组中不包括本业务系统适用的分流策略信息，则根据交易报文中的交易要素，调用分流控制中心，并对第一分流策略信息组中的分流策略信息进行补充，以使补充后的第一分流策略信息组中包括本业务系统适用的分流策略信息。

如此，通过对第一分流策略信息组进行补充，使得第一分流策略信息组中包括本业务系统适用的分流策略信息。

在本申请的一个或多个实施例中，调用模块包括：

发送单元，用于向分流控制中心发送交易要素；

接收单元，用于接收分流控制中心根据交易要素发送的第二分流策略信息组；

添加单元，用于将第二分流策略信息组添加至第一分流策略信息组中，得到补充后的第一分流策略信息组，其中，第二分流策略信息组包括本业务系统适用的分流策略信息。

在本申请的一个或多个实施例中，多业务系统多数据中心分流装置300还可以包括：

第一发送模块，用于将补充后的第一分流策略信息组发送至请求发起方，以使请求发起方下一次发送相关联的交易报文时向接入层发送补充后的第一分流策略信息组。

本申请第四方面还提供一种分流策略分配装置，应用于分流控制中心。

图5是本申请第四方面提供的一种分流策略分配装置的一个实施例的结构示意图。

如图5所示，分流策略分配装置400包括：

接收模块402，用于接收全交易链路上的任意业务系统中的接入层发送的交易要素；

第二确定模块404，用于根据交易要素，确定业务系统适用的分流策略信息组；

第二发送模块406，用于将分流策略信息组发送至接入层。

在本申请实施例中，通过分流控制中心为多业务系统多数据中心分配分流策略信息组，各业务系统可以依据一套分流策略信息组进行分流，使得各业务系统的分流决策一致，以减少交易在跨系统调用的场景中的跨中心调用的情况。其次，本申请实施例是基于分流策略信息组进行分流，与请求发起方的地理位置无关，因此，本申请实施例可以适用于没有请求发起方的地理位置的业务场景，提升方案的通用性。再次，由于本申请实施例在进行分流时不存在探测结果的时延问题，而是接入层根据第一分流策略信息组进行分流，避免出现由于探测结果的时延而对数据中心处理业务的性能带来影响。

本申请第五方面提供一种计算机设备，计算机设备包括：处理器以及存储有计算机程序指令的存储器；处理器执行计算机程序指令时实现第一方面提供的多业务系统多数据中心分流方法或者第二方面提供的分流策略分配方法。

其中，计算机设备可以为数据中心的接入层的设备，用于实现第一方面提供的多业务系统多数据中心分流方法。计算机设备可以为分流控制中心的设备，用于实现第二方面提供的分流策略分配方法。

图6是本申请提供的一种计算机设备的硬件结构示意图。

如图6所示，计算机设备可以包括处理器501以及存储有计算机程序指令的存储器502。

具体地，上述处理器501可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

存储器502可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器502可包括硬盘驱动器(Hard Disk Drive，HDD)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(Universal Serial Bus，USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器502可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器502可在综合网关容灾设备的内部或外部。在特定实施例中，存储器502是非易失性固态存储器。

存储器可包括只读存储器(ROM)，随机存取存储器(RAM)，磁盘存储介质设备，光存储介质设备，闪存设备，电气、光学或其他物理/有形的存储器存储设备。因此，通常，存储器包括一个或多个编码有包括计算机可执行指令的软件的有形(非暂态)计算机可读存储介质(例如，存储器设备)，并且当该软件被执行(例如，由一个或多个处理器)时，其可操作来执行参考根据本申请第一方面提供的多业务系统多数据中心分流方法或者第二方面提供的分流策略分配方法。

处理器501通过读取并执行存储器502中存储的计算机程序指令，以实现上述第一方面提供的多业务系统多数据中心分流方法或者第二方面提供的分流策略分配方法。

在一个示例中，计算机设备还可包括通信接口503和总线510。其中，如图6所示，处理器501、存储器502、通信接口503通过总线510连接并完成相互间的通信。

通信接口503，主要用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。

总线510包括硬件、软件或两者，将在线数据流量计费设备的部件彼此耦接在一起。举例来说而非限制，总线可包括加速图形端口(AGP)或其他图形总线、增强工业标准架构(EISA)总线、前端总线(FSB)、超传输(HT)互连、工业标准架构(ISA)总线、无限带宽互连、低引脚数(LPC)总线、存储器总线、微信道架构(MCA)总线、外围组件互连(PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(SATA)总线、视频电子标准协会局部(VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线510可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。

另外，本申请第八方面还提供一种计算机存储介质，该计算机存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现第一方面提供的多业务系统多数据中心分流方法或者第二方面提供的分流策略分配方法。

需要明确的是，本申请并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本申请的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本申请的精神后，作出各种改变、修改和添加，或者改变步骤之间的顺序。

以上的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时，本申请的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质可以包括非暂态计算机可读存储介质，比如包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD-ROM、光盘、硬盘、光纤介质，机器可读介质还可以包括射频(RF)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。

还需要说明的是，本申请中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本申请不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。

上面参考根据本公开的实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本公开的各方面。应当理解，流程图和/或框图中的每个方框以及流程图和/或框图中各方框的组合可以由计算机程序指令实现。这些计算机程序指令可被提供给通用计算机、专用计算机、或其它可编程数据处理装置的处理器，以产生一种机器，使得经由计算机或其它可编程数据处理装置的处理器执行的这些指令使能对流程图和/或框图的一个或多个方框中指定的功能/动作的实现。这种处理器可以是但不限于是通用处理器、专用处理器、特殊应用处理器或者现场可编程逻辑电路。还可理解，框图和/或流程图中的每个方框以及框图和/或流程图中的方框的组合，也可以由执行指定的功能或动作的专用硬件来实现，或可由专用硬件和计算机指令的组合来实现。

以上，仅为本申请的具体实施方式，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。应理解，本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。

Claims (12)

1.一种面向全交易链路的多业务系统多数据中心分流方法，其特征在于，每个所述业务系统在数据中心均部署有具备业务逻辑处理功能的业务系统单元，所述分流方法应用于所述全交易链路上的任意业务系统中的接入层，每个所述数据中心包括分流控制中心，多数据中心中不同分流控制中心包括相同的分流策略信息；所述分流方法包括：

在接收到请求发起方发送的交易报文的情况下，获取由分流控制中心确定的第一分流策略信息组，其中，所述第一分流策略信息组包括多个分流维度，各个所述业务系统适用相同的分流维度；

根据本业务系统适用的分流维度，在所述第一分流策略信息组中选择本业务系统适用的分流策略信息；

根据本业务系统适用的分流策略信息，在本业务系统部署在所述多数据中心的多个业务系统单元中，为所述交易报文确定实际执行业务逻辑处理的单元，其中，所述实际执行业务逻辑处理的单元为数据中心中与业务系统相对应的业务系统单元。

2.根据权利要求1所述的方法，其特征在于，所述获取由分流控制中心确定的第一分流策略信息组之后，所述方法还包括：

若所述第一分流策略信息组中不包括本业务系统适用的分流策略信息，则根据所述交易报文中的交易要素，调用所述分流控制中心，并对所述第一分流策略信息组中的分流策略信息进行补充，以使补充后的第一分流策略信息组中包括本业务系统适用的分流策略信息。

3. 根据权利要求2 所述的方法，其特征在于，所述根据所述交易报文中的交易要素，调用所述分流控制中心，并对所述第一分流策略信息组中的分流策略信息进行补充，包括：

向所述分流控制中心发送所述交易要素；

接收所述分流控制中心根据所述交易要素发送的第二分流策略信息组；

将所述第二分流策略信息组添加至所述第一分流策略信息组中，得到补充后的第一分流策略信息组，其中，所述第二分流策略信息组包括本业务系统适用的分流策略信息。

4. 根据权利要求2 所述的方法，其特征在于，所述对所述分流策略信息组中的分流策略信息进行补充之后，所述方法还包括：

将补充后的第一分流策略信息组发送至所述请求发起方，以使所述请求发起方下一次发送相关联的交易报文时向所述接入层发送补充后的第一分流策略信息组。

5.一种分流策略分配方法，其特征在于，应用于分流控制中心，所述分流控制中心包括的分流策略信息与多数据中心中其他分流控制中心包括的分流策略信息相同，方法包括：

接收全交易链路上的任意业务系统中的接入层发送的交易要素；

根据所述交易要素，确定所述业务系统适用的分流策略信息组；

将所述分流策略信息组发送至所述接入层，所述分流策略信息组用于所述接入层根据本业务系统适用的分流维度，在所述分流策略信息组中选择本业务系统适用的分流策略信息，以使所述接入层根据本业务系统适用的分流策略信息，在本业务系统部署在所述多数据中心的多个业务系统单元中，为交易报文确定实际执行业务逻辑处理的单元，其中，所述实际执行业务逻辑处理的单元为数据中心中与业务系统相对应的业务系统单元，其中，所述分流策略信息组包括多个分流维度，各个所述业务系统适用相同的分流维度。

6.一种面向全交易链路的多业务系统多数据中心分流装置，其特征在于，每个所述业务系统在所述数据中心均部署有具备业务逻辑处理功能的业务系统单元，所述分流装置应用于所述全交易链路上的任意业务系统中的接入层，每个所述数据中心包括分流控制中心，多数据中心中不同分流控制中心包括相同的分流策略信息；所述分流装置包括：

获取模块，用于在接收到请求发起方发送的交易报文的情况下，获取由分流控制中心确定的第一分流策略信息组，其中，所述第一分流策略信息组包括多个分流维度，各个所述业务系统适用相同的分流维度；

选择模块，用于根据本业务系统适用的分流维度，在所述第一分流策略信息组中选择本业务系统适用的分流策略信息；

第一确定模块，用于根据本业务系统适用的分流策略信息，在本业务系统部署在所述多数据中心的多个业务系统单元中，为所述交易报文确定实际执行业务逻辑处理的单元，其中，所述实际执行业务逻辑处理的单元为数据中心中与业务系统相对应的业务系统单元。

7.根据权利要求6所述的装置，其特征在于，所述装置还包括：

调用模块，用于若所述第一分流策略信息组中不包括本业务系统适用的分流策略信息，则根据所述交易报文中的交易要素，调用所述分流控制中心，并对所述第一分流策略信息组中的分流策略信息进行补充，以使补充后的第一分流策略信息组中包括本业务系统适用的分流策略信息。

8.根据权利要求7所述的装置，其特征在于，所述调用模块包括：

发送单元，用于向所述分流控制中心发送所述交易要素；

接收单元，用于接收所述分流控制中心根据所述交易要素发送的第二分流策略信息组；

添加单元，用于将所述第二分流策略信息组添加至所述第一分流策略信息组中，得到补充后的第一分流策略信息组，其中，所述第二分流策略信息组包括本业务系统适用的分流策略信息。

9.根据权利要求7所述的装置，其特征在于，所述装置还包括：

第一发送模块，用于将补充后的第一分流策略信息组发送至所述请求发起方，以使所述请求发起方下一次发送相关联的交易报文时向所述接入层发送补充后的第一分流策略信息组。

10.一种分流策略分配装置，其特征在于，应用于分流控制中心，所述分流控制中心包括的分流策略信息与多数据中心中其他分流控制中心包括的分流策略信息相同；装置包括：

接收模块，用于接收全交易链路上的任意业务系统中的接入层发送的交易要素；

第二确定模块，用于根据所述交易要素，确定所述业务系统适用的分流策略信息组；

第二发送模块，用于将所述分流策略信息组发送至所述接入层，所述分流策略信息组用于所述接入层根据本业务系统适用的分流维度，在所述分流策略信息组中选择本业务系统适用的分流策略信息，以使所述接入层根据本业务系统适用的分流策略信息，在本业务系统部署在所述多数据中心的多个业务系统单元中，为交易报文确定实际执行业务逻辑处理的单元，其中，所述实际执行业务逻辑处理的单元为数据中心中与业务系统相对应的业务系统单元，其中，所述分流策略信息组包括多个分流维度，各个所述业务系统适用相同的分流维度。

11.一种计算机设备，其特征在于，所述设备包括：处理器以及存储有计算机程序指令的存储器；

所述处理器执行所述计算机程序指令时实现如权利要求1-5任意一项所述的方法。

12.一种计算机存储介质，其特征在于，所述计算机存储介质上存储有计算机程序指令，所述计算机程序指令被处理器执行时实现如权利要求1-5任意一项所述的方法。