交易路由的回切方法、中间系统和业务处理系统

技术领域

本申请涉及数据处理领域，尤其涉及交易路由的回切方法、中间系统和业务处理系统。

背景技术

现代大型商业银行中，交易的请求流向一般包括：前台系统访问中台系统，中台系统进行控制、转发至后台系统，响应流向为请求的反方向，即中台系统作为前台和后台联系的枢纽，具有十分重要的作用。

中台系统包括服务集群，为了升级中台系统，开发与原有服务集群具有相同功能的升级服务集群，例如，中台系统中原有服务集群为A服务集群，开发了A服务集群的升级服务集群，可以简称为B服务集群。

为了保证中台系统升级后，可以平稳过渡运行，即为了保证中台系统中的B服务集群从初期的性能不稳定到性能稳定的使用过程中，不影响中台系统对交易请求的正常响应。如何在B服务集群出现异常的情况下，可以从B服务集群简单高效灵活地回切至A服务集群，是个需要解决的关键问题。例如某个交易T目前的路由流向为前台系统--中台系统B服务集群—后台系统，当B服务集群出现故障时，交易T路由流向需回切至前台--中台系统A服务集群--后台，在此回切过程中，要具备简单、高效和稳定等特点。

发明内容

本申请提供了交易路由的回切方法、中间系统和业务处理系统，目的在于提供一种简单灵活高效的交易路由回切方案。

为了实现上述目的，本申请提供了以下技术方案：

本申请提供了一种交易路由的回切方法，应用于中间系统；所述中间系统包括：中台系统和服务路由管理系统；所述中台系统包括API网关以及由原服务集群和升级服务集群构成的服务集群，所述方法包括：

所述服务路由管理系统，用于在接收到前台系统发送的交易请求的情况下，按照预设的交易类型与可配置的多种交易路由间的预设对应关系，确定所述交易请求指示的交易类型对应的交易路由，得到目标交易路由；任一交易类型对应的交易路由指示：该交易类型的交易请求被分配给所述原服务集群下的服务器站点个数的占比，以及，该交易类型的交易请求被分配给所述升级服务集群下的服务器站点个数的占比。

所述服务路由管理系统，还用于将所述目标交易路由的信息发送给所述API网关；

所述API网关，用于按照所述目标交易路由指示的负载均衡策略，为所述交易请求分配服务器站点；所述负载均衡策略表征：所述原服务集群和所述升级服务集群中，分别被分配用于响应所述目标交易路由对应的交易请求的服务器站点的个数占比，与，所述目标交易路由指示的对应服务集群下服务器站点个数的占比相同。

可选的，所述API网关，还用于在所述升级服务集群对全部类型的交易请求的响应出现异常的情况下，按照预设的负载均衡策略，为所述交易请求分配服务器站点。

可选的，所述预设的负载均衡策略表征：所述原服务集群与所述升级服务集群中，仅所述原服务集群中的服务器站点被分配用于响应全部交易请求。

可选的，所述服务路由管理系统，还用于在接收到对任一交易类型对应的交易路由的配置更新信息的情况下，将所述预设对应关系中该交易类型对应的交易路由更新为所述配置更新信息指示的交易路由。

可选的，所述API网关，还用于在接收到对任一交易路由对应的负载均衡策略的配置更新信息的情况下，将该交易路由对应的负载均衡策略更新为所述配置更新信息指示的负载均衡策略。

本申请还提供了一种中间系统，包括：中台系统和服务路由管理系统；所述中台系统包括API网关以及由原服务集群和升级服务集群构成的服务集群；

所述服务路由管理系统，用于在接收到前台系统发送的交易请求的情况下，按照预设的交易类型与可配置的多种交易路由间的预设对应关系，确定所述交易请求指示的交易类型对应的交易路由，得到目标交易路由；任一交易类型对应的交易路由指示：该交易类型的交易被分配给所述原服务集群下的服务器站点个数的占比，以及，该交易类型的交易被分配给所述升级服务集群下的服务器站点个数的占比；

所述服务路由管理系统，还用于将所述目标交易路由的信息发送给所述API网关；

所述API网关，用于按照所述目标交易路由指示的负载均衡策略，为所述交易请求分配服务器站点；所述负载均衡策略表征：所述原服务集群和所述升级服务集群中，分别被分配用于响应所述目标交易路由对应的交易请求的服务器站点的个数占比，与，所述目标交易路由指示的对应服务集群下服务器站点个数的占比相同。

可选的，所述API网关，还用于在所述升级服务集群对全部类型的交易请求的响应出现异常的情况下，按照预设的负载均衡策略，为所述交易请求分配服务器站点。

可选的，所述服务路由管理系统，还用于在接收到对任一交易类型对应的交易路由的配置更新信息的情况下，将所述预设对应关系中该交易类型对应的交易路由更新为所述配置更新信息指示的交易路由。

可选的，所述API网关，还用于在接收到对任一交易路由对应的负载均衡策略的配置更新信息的情况下，将该交易路由对应的负载均衡策略更新为所述配置更新信息指示的负载均衡策略。

本申请还提供了一种交易处理系统，包括前台系统、中间系统和后台系统；

所述前台系统，用于在接收到待响应的交易请求的情况下，将所述交易请求发送给所述中间系统；

所述中间系统为上述任意一所述的中间系统；

所述后台系统，用于接收中台系统转发的交易请求，并将响应结果返回给中台系统。

本申请所述的交易路由的回切方法、中间系统和业务处理系统，服务路由管理系统在接收到前台系统发送的交易请求的情况下，按照预设的交易类型与可配置的多种交易路由间的预设对应关系，确定所述交易请求指示的交易类型对应的交易路由，得到目标交易路由；并将目标交易路由的信息发送给API网关；API网关按照目标交易路由指示的负载均衡策略，为交易请求分配服务器站点。

在本申请中，任一交易类型对应的交易路由指示：该交易类型的交易被分配给原服务集群下的服务器站点个数的占比，以及，该交易类型的交易被分配给升级服务集群下的服务器站点个数的占比。并且，交易路由的具体内容是可配置的。因此，在升级服务集群对某支交易的响应出现异常的情况下，本申请为通过修改该支交易的交易路由的方式，将该支交易简单灵活高效地回切至原服务集群，提供了可能。

并且，在本申请中，目标交易路由指示的负载均衡策略表征：原服务集群和升级服务集群中，分别被分配用于响应目标交易路由对应的交易请求的服务器站点个数的占比，与，目标交易路由指示的对应服务集群下的服务器站点个数的占比相同。即API网关按照目标路由指示的各个服务集群下的服务器站点个数的占比，实现对交易请求的响应。使得在交易路由更改的情况下，API网关可以按照更改后的交易路由指示的负载均衡策略进行响应，从而，实现回切。

综上所述，本申请提供的方案为从升级服务集群灵活高效方便地回切至原服务集群，提供了可能。

附图说明

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

图1为本申请实施例公开的一种中间系统的结构图；

图2为本申请实施例公开的中间系统对交易请求的响应过程的流程图；

图3为本申请实施例公开的一种用于响应目标交易路由对应的交易请求的服务器站点示意图；

图4为本申请实施例公开的一种交易处理系统的结构示意图。

具体实施方式

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

图1为本申请实施例提供的一种中间系统的结构示意图，包括：中台系统和服务路由管理系统。其中，中台系统包括API网关以及由原服务集群和升级服务集群构成的服务集群。

在本实施例中，服务路由管理系统中事先存储有可配置的路由列表，其中，路由列表中包含预设的交易类型与多种交易路由间的预设对应关系。

在本实施例中，为了直观展示交易路由的内容，给出了如下四种交易路由，分别表示为Route1、Route2、Route3和Route4，具体内容包括：

Route1：0％流量到B服务集群，100％流量到A服务集群

Route2：10％流量到B服务集群，90％流量到A服务集群

Route3：50％流量到B服务集群，50％流量到A服务集群

Route4：100％流量到B服务集群，0％流量到A服务集群

其中，“B服务集群”表示升级服务集群，“A服务集群”表示原服务集群。为了方便描述，以任一交易路由为例，介绍交易路由的内容所表示的含义。例如，在Route1中，“0％流量到B服务集群，100％流量到A服务集群”表示：对于Route1对应的交易类型的交易请求，被分配给B服务集群下的服务器站点个数的占比为0％，被分配给A服务集群下的服务器站点个数的占比为100％。即B服务集群中用于响应Route1对应的交易类型的交易请求的服务器站点的个数，占，用于响应该交易类型的交易请求的服务器站点总个数的比例为0％。A服务集群中用于响应Route1对应的交易类型的交易请求的服务器站点的个数，占，用于响应该交易类型的交易请求的服务器站点总个数的比例为100％。

需要说明的是，在本实施例中，每种交易类型对应的交易路由的内容可以根据实际情况进行配置。

具体的，服务路由管理系统在接收到对任一交易类型对应的交易路由的配置更新信息的情况下，将预设对应关系中该交易类型对应的交易路由更新为配置更新信息指示的交易路由。

在本实施例中，中间系统在接收到前台系统发送的交易请求的情况下，对交易请求的响应过程，如图2所示，可以包括以下步骤：

S201、服务路由管理系统在接收到前台系统发送的交易请求的情况下，按照预设的交易类型与可配置的多种交易路由间的预设对应关系，确定交易请求指示的交易类型对应的交易路由，得到目标交易路由。

在本实施例中，任一交易类型对应的交易路由指示：该交易类型的交易请求被分配给原服务集群下的服务器站点个数的占比，以及，该交易类型的交易请求被分配给升级服务集群下的服务器站点个数的占比。其中，交易路由的具体示例和具体含义，可以参考上述对交易路由示例和含义的解释，这里不再赘述。

在本步骤中，为了描述方便，将本步骤确定出的交易路由，称为目标交易路由。

S202、服务路由管理系统将目标交易路由的信息发送给API网关。

在本实施例中，服务路由管理系统在确定出目标交易路由后，将目标交易路由发送给API网关。

S203、API网关按照目标交易路由指示的负载均衡策略，为交易请求分配服务器站点。

在本实施例中，API网关中保存有接入列表，该接入列表中包含交易路由与负载均衡策略之间的预设对应关系。其中，任一交易路由对应的负载均衡策略表征：原服务集群和升级服务集群中，分别被分配用于响应该交易路由对应的交易请求的服务器站点的个数占比，与，目标交易路由指示的对应服务集群下服务器站点个数的占比相同。

还以上述Rount1为例，Rount1对应的负载均衡策略表示的含义为：B服务集群中，被分配用于响应目标交易路由对应的交易请求的服务器站点的个数，占，B服务集群和A服务集群中被分配用于响应目标交易路由对应的交易请求的服务器站点的总个数的比值为0％。A服务集群中，被分配用于响应目标交易路由对应的交易请求的服务器站点的个数，占，B服务集群和A服务集群中被分配用于响应目标交易路由对应的交易请求的服务器站点的总个数的比值为100％。

如图3所示，在图3中，各个圆柱体表示服务器站点，其中，标有“A”的圆柱体表示A服务集群中，被分配用于响应目标交易路由对应的交易请求的服务器站点，标有“B”的圆柱体表示B服务集群中，被分配用于响应目标交易路由对应的交易请求的服务器站点。

从图3中，可以看出，标有“A”的圆柱体个数为9个，标有“B”的圆柱体个数为1个，服务器站点的总个数为10个，即用于响应目标交易路由对应的交易请求的服务器站点的总个数为10个。API网关采用负载均衡从这10个服务器站点分配交易请求，从而，使得A服务集群中，用于响应目标交易路由对应的交易请求的服务器站点的个数(标有“A”的圆柱体总个数9个)，占，用于响应目标交易路由对应的交易请求的服务站点的总个数(10个)的比值为90％。B服务集群中，用于响应目标交易路由对应的交易请求的服务器站点的个数(标有“B”的圆柱体总个数1个)，占，用于响应目标交易路由对应的交易请求的服务站点的总个数(10个)的比值为10％。

通过本实施例中，在升级服务集群可能出现故障，一种情况，升级服务集群对某支交易的响应异常，用户可以通过对交易类型与交易路由间的对应关系中，对该支交易对应的交易路由进行设置。服务路由管理系统在接收到对该支交易对应的交易路由内容的更新消息的情况下，将对应关系中该支交易对应的交易路由进行更新。从而，为交易路由灵活方便高效的回切提供可能。

在实际中，升级服务集群出现故障的另一种情况为：升级服务集群对每支交易类型对应的交易请求都响应异常，在该情况下，可以通过修改服务路由管理系统中每个交易类型对应的交易路由的内容，从而将交易路由回切至原服务集群。为了更便于将交易路由回切至原服务集群，在本实施例中，可以通过在API网关中配置预设的负载均衡策略，API网关在升级服务集群对全部类型交易请求的响应出现故障的情况下，按照该预设负载均衡策略，为交易请求分配服务器站点，具体为S204所示的操作。

S204、API网关在升级服务集群对全部类型的交易请求的响应出现异常的情况下，按照预设的负载均衡策略，为交易请求分配服务器站点。

在本实施例中，预设的负载均衡的内容，需要根据实际内容进行配置的。可选的，在本实施例中，预设的负载均衡策略可以表征：原服务集群和升级服务集群中，仅原服务集群中的服务器站点被分配用于响应交易请求。即API网关仅将交易请求分配给原服务集群中的服务器站点。

在本实施例中，预设的负载均衡的内容可以根据实际情况进行更新，可选的，预设的负载均衡的更新方式可以包括：API网关在接收到对交易路由对应的负载均衡策略的配置更新信息的情况下，将交易路由对应的负载均衡策略，更新为该配置更新信息指示的负载均衡策略。在更新完成后，API网关在升级服务集群对全部类型的交易请求出现异常的情况下，按照更新后的负载均衡策略，为交易请求分配服务器站点。

图4为本申请实施例提供的一种交易处理系统，包括：前台系统、中间系统和后台系统。

在本实施例中，前台系统用于接收待响应的交易请求，并将接收的交易请求发送给中间系统。其中，在本实施例中，前台系统可以为掌银、网银和电话银行中的任意一种。

中间系统包含的部件如图1对应的实施例，这里不再赘述。中间系统包含的各部件之间的交互过程，可以参考图2对应的对交易请求的响应过程，这里不再赘述。

后台系统用于接收中台系统转发的交易请求，并将响应结果返回给中台系统。

本申请实施例具有以下有益效果：

有益效果一：

在本申请实施例中，任一交易类型对应的交易路由指示：该交易类型的交易被分配给原服务集群下的服务器站点个数的占比，以及，该交易类型的交易被分配给升级服务集群下的服务器站点个数的占比。并且，交易路由的具体内容是可配置的。因此，在升级服务集群对某支交易的响应出现异常的情况下，本申请为通过修改该支交易的交易路由的方式，将该支交易简单灵活高效地回切至原服务集群，提供了可能。

并且，在本申请中，目标交易路由指示的负载均衡策略表征：原服务集群和升级服务集群中，分别被分配用于响应目标交易路由对应的交易请求的服务器站点个数的占比，与，目标交易路由指示的对应服务集群下的服务器站点个数的占比相同。即API网关按照目标路由指示的各个服务集群下的服务器站点个数的占比，实现对交易请求的响应。使得在交易路由更改的情况下，API网关可以按照更改后的交易路由指示的负载均衡策略进行响应，从而，实现回切。

综上所述，本申请实施例为从升级服务集群灵活高效方便地回切至原服务集群，提供了可能。

有益效果二：

在本申请实施例中，在升级服务集群出现故障，即升级服务集群对每种交易类型的交易请求的响应都出现问题的情况下，提供了可配置的预设负载均衡策略，从而，为用户仅通过配置该预设的负载均衡策略的内容，将交易请求回切至原服务集群提供了可能。因此，与通过修改服务路由管理系统中每类交易对应的交易路由相比，修改预设的负载均衡的策略的方式，对于用户来说更方便。

有益效果三：

由于本申请实施例中，在前台系统与中台系统之间添加了服务路由管理系统，以及中台系统中包括API网关，因此，在前台系统遭受到恶意攻击的情况下，API网关可以对交易请求进行分配和响应，因此，对后台系统的遭受恶意攻击具有一定的缓冲作用，因此，本申请实施例具有安全可控的有益效果。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。

对所公开的实施例的上述说明，本说明书中各实施例中记载的特征可以相互替换或者组合，使本领域专业技术人员能够实现或使用本申请。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。