支付业务系统的服务控制管理组件装置的制作方法

本发明涉及支付业务技术领域，特别涉及一种支付业务系统的服务控制管理组件装置。

背景技术：

随着中国经济的快速增长和支付电子化发展，支付活动日益频繁，市场对支付系统的处理能力提出更高要求。现有支付业务系统均采用集中式应用处理架构，每个业务系统仅包括一个业务处理单元与相关的业务关联系统进行交互，对待支付业务进行处理，业务数据统一存储在单个数据库中，支付业务系统采用集中式的应用处理架构存在以下问题：

1)可扩展性不强：随着业务量的持续快速增长，单个数据库处理出现性能瓶颈，集中式的处理架构无法实现处理能力的横向收缩，仅通过纵向扩展来提升业务处理容量，不仅成本较高，且存在扩展极限。

2)应用架构不够灵活：系统运行对单一厂商的软硬件设备依赖性太强，无法灵活适应多样化灵活部署的需求，也不适应国家对关键业务信息系统自主可控的安全要求。

通过上述可知，现有支付业务系统普遍采用集中式应用处理架构，随着业务量的增大，处理能力达到饱和并会积聚风险，为应对未来高业务容量、高吞吐量的处理需求，支付业务系统应用架构由集中式调整为分布式为必然趋势。

然而，现有技术中，难以实现支付业务系统由集中式应用处理架构调整为分布式架构，或需要对现有支付业务系统进行大量复杂的改造，需要耗费很大的成本。

技术实现要素：

本发明实施例提供了一种支付业务系统的服务控制管理组件装置，用以方便将支付业务系统由集中式处理架构调整为分布式架构，支付业务系统为分布式支付业务系统，包括：多个业务处理单元和与多个业务处理单元交互的多个业务关联系统，服务控制管理组件装置包括：服务管理组件和多个路由组件，其中：

服务管理组件，用于接收每个业务处理单元的信息，根据每个业务处理单元的信息，配置每个业务处理单元应处理待支付业务的策略，将策略发送至多个路由组件；

每个路由组件，设置在与多个业务处理单元交互的每一个业务关联系统，每个路由组件与服务管理组件连接，用于根据策略，以及支付业务系统接收的待支付业务，从多个业务处理单元中确定出一个处理待支付业务的业务处理单元，将确定出的业务处理单元的信息提供给业务关联系统；

业务关联系统根据确定出的业务处理单元的信息，与确定出的业务处理单元进行交互；确定出的业务处理单元根据与业务关联系统的交互，处理待支付业务。

在一个实施例中，业务处理单元的信息包括以下其中之一或任意组合：业务处理单元的名称、业务处理单元待处理业务的队列信息、业务处理单元的状态信息、业务处理单元的业务受理范围信息、业务处理单元的备用业务处理单元信息和业务处理单元所在数据中心的信息。

在一个实施例中，业务处理单元的业务受理范围信息包括：发起行的行号、接收行的行号和报文类型；

服务管理组件具体用于：接收每个业务处理单元的业务受理范围信息，根据业务受理范围信息，配置每个业务处理单元应处理待支付业务的策略，将策略发送至多个路由组件；

每个业务处理单元应处理待支付业务的策略包括：

根据报文类型和发起行的行号，配置的每个业务处理单元应处理待支付业务的策略；

或，根据报文类型和接收行的行号，配置的每个业务处理单元应处理待支付业务的策略；

或，根据报文类型，配置的每个业务处理单元应处理待支付业务的策略。

在一个实施例中，路由组件具体用于：

接收根据待支付业务生成的业务关键字信息；

根据业务关键字信息，以及每个业务处理单元应处理待支付业务的策略，从多个业务处理单元中确定出一个处理待支付业务的业务处理单元；

将确定出的业务处理单元的信息提供给业务关联系统。

在一个实施例中，服务管理组件还用于接收每个业务处理单元对业务关联系统公共消息的预订消息，将预订消息发送至多个路由组件；

路由组件还用于将预订消息提供给业务关联系统；

业务关联系统根据预订消息，将公共消息发送至预订了公共消息的业务处理单元。

在一个实施例中，服务管理组件包括：

信息接收模块，用于接收每个业务处理单元的信息；

信息处理模块，与信息接收模块连接，用于根据每个业务处理单元的信息，配置每个业务处理单元应处理待支付业务的策略；

第一网络通信模块，用于将策略发送至多个路由组件。

在一个实施例中，信息接收模块具体用于：接收每个业务处理单元的变更信息；

信息处理模块具体用于：根据每个业务处理单元的变更信息，重新配置每个业务处理单元应处理待支付业务的策略；

第一网络通信模块具体用于：将重新配置的每个业务处理单元应处理待支付业务的策略发送至多个路由组件。

在一个实施例中，信息接收模块具体用于：接收监控系统pams发来的业务处理单元的状态信息，以及业务处理单元各个节点的状态信息；

信息处理模块具体用于：根据监控系统pams发来的业务处理单元的状态信息，以及业务处理单元各个节点的状态信息，维护业务处理单元以及业务处理单元各个节点。

在一个实施例中，信息接收模块具体用于：接收每个业务处理单元各个节点的可用情况信息；

信息处理模块具体用于：根据每个业务处理单元各个节点的可用情况信息，判断每个业务处理单元的可用情况，根据每个业务处理单元的可用情况，配置每个业务处理单元应处理待支付业务的策略；

第一网络通信模块具体用于：将根据每个业务处理单元的可用情况，配置的每个业务处理单元应处理待支付业务的策略发送至多个路由组件。

在一个实施例中，服务管理组件具体用于：接收每个业务处理单元及其备用业务处理单元的信息，根据每个业务处理单元及其备用业务处理单元的信息，配置每个业务处理单元应处理待支付业务的策略，将策略发送至多个路由组件。

在一个实施例中，路由组件包括：第二网络通信模块、信息更新模块、共享内存区和路由接口，其中：

第二网络通信模块，与服务管理组件连接，用于接收每个业务处理单元应处理待支付业务的策略；

信息更新模块，用于将每个业务处理单元应处理待支付业务的策略更新至共享内存区，根据策略，以及支付业务系统接收的待支付业务，从多个业务处理单元中确定出一个处理待支付业务的业务处理单元；

路由接口，用于连接与业务处理单元交互的业务关联系统和信息更新模块，将确定出的业务处理单元的信息提供给业务关联系统。

在一个实施例中，共享内存区包括：主共享内存区和备共享内存区；

信息更新模块具体用于：

将每个业务处理单元应处理待支付业务的策略更新至备共享内存区；

将所述备共享内存区变更为主共享内存区，将原主共享内存区变更为备共享内存区；

根据变更后主共享内存区内的策略，以及支付业务系统接收的待支付业务，从多个业务处理单元中确定出一个处理待支付业务的业务处理单元。

在一个实施例中，路由组件具体用于将每个业务处理单元应处理待支付业务的策略存储在共享内存区，供业务关联系统调用；共享内存区包括：主共享内存区和备共享内存区；

服务管理组件具体用于：

将每个业务处理单元应处理待支付业务的策略发送至各个路由组件，接收各个路由组件发来的策略已更新至备共享内存区的响应信息；

将路由组件共享内存区加锁通知信息发送至各个路由组件，接收各个路由组件发来的路由组件共享内存区加锁完毕响应信息；

将路由组件主备内存切换信息发送至各个路由组件，接收各个路由组件发来的路由组件主备内存切换完毕响应信息；

将路由组件共享内存区解锁通知信息发送至各个路由组件，接收各个路由组件发来的路由组件共享内存区解锁完毕响应信息；

路由组件具体用于：

接收服务管理组件发来的每个业务处理单元应处理待支付业务的策略，将策略更新至备共享内存区，发送策略已更新至备共享内存区的响应信息至服务管理组件；

接收服务管理组件发来的路由组件共享内存区加锁通知信息，对共享内存区进行加锁，将路由组件共享内存区加锁完毕响应信息发送至服务管理组件；

接收服务管理组件发来的路由组件主备内存切换信息，将原备共享内存区变更为主共享内存区，将原主共享内存区变更为备共享内存区，将路由组件主备内存切换完毕响应信息发送至服务管理组件；

接收路由组件共享内存区解锁通知信息，对共享内存区进行解锁，将路由组件共享内存区解锁完毕响应信息发送至服务管理组件。

本发明实施例提供的服务控制管理组件装置通过：服务管理组件接收每个业务处理单元的信息，根据每个业务处理单元的信息，配置每个业务处理单元应处理待支付业务的策略，将策略发送至多个路由组件；通过：每个路由组件，设置在与多个业务处理单元交互的每一个业务关联系统，每个路由组件与服务管理组件连接，用于根据策略，以及支付业务系统接收的待支付业务，从多个业务处理单元中确定出一个处理待支付业务的业务处理单元，将确定出的业务处理单元的信息提供给业务关联系统，业务关联系统根据确定出的业务处理单元的信息，与确定出的业务处理单元进行交互；确定出的业务处理单元根据与业务关联系统的交互，处理待支付业务，实现了支付业务系统由集中式应用处理架构调整为分布式架构，具有良好的横向可伸缩性，由多个业务处理单元并行处理业务，极大地提升了业务处理容量，提高了业务处理效率，保证了业务连续运行能力，具体理由如下：

首先，由于本发明实施例提供的技术方案将配置策略集中在服务管理组件，将根据所述策略，确定处理待支付业务的业务处理单元的决策集中在路由组件，对与业务处理单元交互的上层业务关联系统仅需进行简单的适应性改造，即可实现分布式业务处理，为支付业务系统由集中式处理架构调整为分布式提供了便利性和可靠性，简化了现有支付业务系统改造成本，降低了软硬件采购成本；

另外，服务管理组件根据不同的业务处理单元的信息，配置不同策略，即根据不同的业务处理单元的软硬件设备，分配给该业务处理单元相应处理能力的业务，这样业务处理单元可灵活部署，选用多厂商的多类型服务器、操作系统及数据库，支持多种类型的软硬件平台。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，并不构成对本发明的限定。在附图中：

图1是本发明实施例中支付业务系统的服务控制管理组件装置的结构示意图；

图2是本发明实施例中服务控制管理组件装置具体应用实例的结构示意图；

图3是本发明另一实施例中支付业务系统的服务控制管理组件装置结构示意图；

图4是本发明实施例中服务管理组件同步发送信息至路由组件相互通信示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面结合实施方式和附图，对本发明做进一步详细说明。在此，本发明的示意性实施方式及其说明用于解释本发明，但并不作为对本发明的限定。

随着中国经济的快速增长和支付电子化发展，支付活动日益频繁，市场对支付系统的处理能力提出更高要求。主要表现在以下三方面：

1)业务处理容量越来越大；

2)业务处理效率越来越高；

3)业务连续运行能力越来越强。

为达到上述三方面的要求，本发明实施构建的服务控制管理组件由服务管理组件和路由组件构成，其中：路由组件部署在各个业务关联系统(例如：轧差系统nets和支付报文传输系统pmts等)上，以动态链接库的形式提供接口供上层应用(例如：轧差系统nets和支付报文传输系统pmts等)调用，可以与位于中心的服务管理组件通过网络连接形成星型结构。服务管理组件提供统一的ui管理界面，支持业务处理单元信息、路由信息(包括：每个业务处理单元应处理待支付业务的策略和每个业务处理单元对业务关联系统公共消息的预订消息等)的灵活配置，作为信息源，会主动将最新的路由信息(包括：每个业务处理单元应处理待支付业务的策略和每个业务处理单元对业务关联系统公共消息的预订消息等)分发至各个路由组件，路由组件根据本地缓存的信息(例如：根据每个业务处理单元的信息，配置的每个业务处理单元应处理待支付业务的策略)为上层业务系统(例如：轧差系统nets和支付报文传输系统pmts等)提供路由决策。下面对该服务控制管理组件进行详细介绍。

本发明实施例提供了一种支付业务系统的服务控制管理组件装置，用以方便将支付业务系统由集中式处理架构调整为分布式架构，支付业务系统为分布式支付业务系统，包括：多个业务处理单元和与多个业务处理单元交互的多个业务关联系统，每个业务处理单元对应一个独立的数据库，图1是本发明实施例中支付业务系统的服务控制管理组件装置的结构示意图，如图1所示，服务控制管理组件装置包括：服务管理组件100和路由组件200，其中：

服务管理组件100，用于接收每个业务处理单元的信息，根据每个业务处理单元的信息，配置每个业务处理单元应处理待支付业务的策略，将所述策略发送至多个路由组件；

每个路由组件200，设置在与多个业务处理单元交互的每一个业务关联系统，每个路由组件与所述服务管理组件连接，用于根据所述策略，以及支付业务系统接收的待支付业务，从多个业务处理单元中确定出一个处理待支付业务的业务处理单元，将确定出的业务处理单元的信息提供给业务关联系统；

所述业务关联系统根据确定出的业务处理单元的信息，与确定出的业务处理单元进行交互；确定出的业务处理单元根据与业务关联系统的交互，处理待支付业务。

具体实施时，本发明实施例提供的服务控制管理组件装置中服务管理组件可以接收银行工作人员输入每个业务处理单元的信息，例如：每个业务处理单元的名称、业务受理范围信息、备用业务处理单元信息和业务处理单元所在的数据中心信息等信息。当然，也可以接收各个路由组件实时发来的信息，例如：每个业务处理单元的队列信息和状态信息等等。服务管理组件可以根据每个业务处理单元的信息，配置每个业务处理单元应处理的待支付业务策略，即根据每个业务处理单元的实际配置情况，制定该业务处理单元应处理的待支付业务策略，也可以称作：将不同的支付业务分配给具体哪个业务处理单元的策略。配置完成后，将策略发送至每个路由组件。路由组件根据支付业务系统接收到的待支付业务，以及从服务管理组件接收到的每个业务处理单元应处理的待支付业务策略，确定多个业务关联系统应该与那个业务关联系统交互，该确定的业务处理单元，根据与多个业务关联系统的交互，对待支付业务进行处理。

与现有技术相比较，本发明实施例提供的服务控制管理组件装置，为集中式支付业务系统向分布式支付业务系统迁移提供便利性和可靠性，具有良好的横向可伸缩性，由多个业务处理单元并行处理业务，极大地提升了业务处理容量，提高了业务处理效率，保证了业务连续运行能力，具体理由如下：

首先，由于本发明实施例提供的技术方案将配置策略集中在服务管理组件，将根据所述策略，确定处理待支付业务的业务处理单元的决策集中在路由组件，与业务处理单元交互的上层业务关联系统仅需进行简单的适应性改造，即可实现分布式业务处理，为支付业务系统由集中式处理架构调整为分布式提供了便利性和可靠性，简化了现有支付业务系统改造成本，降低了软硬件采购成本；

另外，服务管理组件根据不同的业务处理单元的信息，配置不同策略，即根据不同的业务处理单元的软硬件设备，分配给该业务处理单元相应处理能力的业务处理单元，这样业务处理单元部署可灵活选用多厂商的多类型服务器、操作系统及数据库，支持多种类型的软硬件平台。

具体实施时，与业务处理单元交互的业务关联系统可以包括：支付报文传输系统(pmts)、轧差系统(nets)和业务汇总核对子系统等等，请参见附图2以及下表1，如图2所示，每个业务处理单元还对应一个独立的数据库，该数据库可以存储对应业务处理单元的处理过程信息等等。

在一个实施例中，业务处理单元的信息包括以下其中之一或任意组合：业务处理单元的名称、业务处理单元待处理业务的队列信息、业务处理单元的状态信息、业务处理单元的业务受理范围信息、业务处理单元的备用业务处理单元信息和业务处理单元所在数据中心的信息。

具体实施时，业务处理单元的队列信息指的是，业务处理单元待处理的支付业务队列信息。

在一个实施例中，业务处理单元的业务受理范围信息包括：发起行的行号、接收行的行号和报文类型；

服务管理组件具体用于：接收每个业务处理单元的业务受理范围信息，根据业务受理范围信息，配置每个业务处理单元应处理待支付业务的策略，将策略发送至多个路由组件；

每个业务处理单元应处理待支付业务的策略包括：

根据报文类型和发起行的行号，配置的每个业务处理单元应处理待支付业务的策略；

或，根据报文类型和接收行的行号，配置的每个业务处理单元应处理待支付业务的策略；

或，根据报文类型，配置的每个业务处理单元应处理待支付业务的策略。

具体实施时，通过服务管理组件的ui界面管理业务处理单元及业务处理单元的各个节点信息，业务处理单元业务受理范围划分规则如下(即服务管理组件是如何根据每个业务处理单元的信息，配置每个业务处理单元应处理待支付业务的策略的)：

(1)根据报文类型和发起行的行号，配置的每个业务处理单元应处理待支付业务的策略，包括以下两种情况：

①发起行主动发起的业务报文，依据报文类型和发起行行号组合作为业务划分规则。划分业务规则时，假设一笔网银贷记业务由发起行banka发送给接收行bankb。则报文类型为网银贷记业务，发起行行号为banka的业务报文由网银业务处理单元1受理。

②由发起行发起的针对(1)类业务的业务状态查询/业务撤销申请/业务明细核对申请/业务明细核对下载申请报文，需要匹配原业务，依据报文类型和发起行行号组合作为业务划分规则。划分业务规则时，假设一笔业务状态查询报文由发起行banka发送给网银系统ibps。则报文类型为业务状态查询，发起行行号为banka的业务报文由网银业务处理单元1受理。如此，可与业务处理单元1的网银贷记业务相匹配。

(2)根据报文类型和接收行的行号，配置的每个业务处理单元应处理待支付业务的策略：

由接收行发起的针对(1)类的回执报文，需要匹配原业务，依据报文类型和接收行行号组合作为业务划分规则。划分业务规则时，假设一笔网银贷记回执业务由接收行bankb发送给发起行banka。则报文类型为网银贷记回执业务，接收行行号为banka的业务报文由网银业务处理单元1受理。如此，可与业务处理单元1的网银贷记业务相匹配。

(3)根据报文类型，配置的每个业务处理单元应处理待支付业务的策略：对第三方贷记及回执业务，涉及三方机构，依据报文类型作为业务划分规则。

在一个实施例中，路由组件具体用于：

接收根据待支付业务生成的业务关键字信息；

根据业务关键字信息，以及每个业务处理单元应处理待支付业务的策略，从多个业务处理单元中确定出一个处理待支付业务的业务处理单元；

将确定出的业务处理单元的信息提供给业务关联系统。

下面结合图2(在图2中主机平台实例、业务实例1，以及业务实例n均是本发明实施中提到的业务处理单元，图2中业务关联系统的英文含义请参见下表1)，以支付业务为网银贷记业务为例，说明本发明实施例提供的服务控制管理组件装置如何实施的。

假设有一笔支付业务：网银贷记业务，该网银贷记业务为：发起行为banka，接收行为bankb，期望通过划分业务受理范围实现将该笔报文路由至业务处理单元1(业务实例1)处理，则采用服务控制管理组件的具体业务处理流程如下：

(1)节点及业务处理单元注册：从服务管理组件录入业务处理单元1(业务处理实例1)的相关信息，该录入的功能可以通过下文提到的信息接收模块来实现，包含业务处理单元的业务受理范围信息(详见下文的详细介绍)，即由发起行banka发起网银贷记业务、及由接收行bankb接收的网银贷记回执业务均有业务处理单元1受理(该描述可以成为配置策略)。

(2)广播路由信息：服务管理组件将业务处理单元1注册后的最新路由信息(即可以包括：根据每个业务处理单元的信息，配置的每个业务处理单元应处理待支付业务的策略)广播至所有路由组件，本发明实施例中提到的路由信息可以包括：每个业务处理单元应处理待支付业务的策略，以及下文提到的每个业务处理单元对业务关联系统公共消息的预订消息(订阅消息)等。

(3)更新共享内存区：路由组件按照同步更新机制(下文进行详细介绍)将最新路由信息串进行解析，并更新至共享内存区(关于更新共享内存区的过程详见下文)。

(4)业务处理：支付业务系统收到了用户的一笔网银贷记业务：发起行为banka，接收行为bankb，与业务处理单元交互的业务关联系统：支付报文传输系统(pmts)根据待支付业务生成的业务关键字信息，例如：发起行为banka，接收行为bankb，将该业务关键字信息发送给路由组件，路由组件根据该业务关键字信息，以及所述每个业务处理单元应处理待支付业务的策略，确定多个业务关联系统(例如：支付报文传输系统(pmts)、轧差系统(nets)和业务汇总核对子系统等)应该与哪个业务关联系统交互，从多个业务处理单元中确定出一个处理待支付业务的业务处理单元1；支付报文传输系统(pmts)通过查询路由组件，了解了应该与业务处理单元1通信，根据确定出的业务处理单元1的信息，将该笔网银贷记业务发送至确定出的业务处理单元1，业务处理单元1根据通过与业务关联系统(例如：支付报文传输系统(pmts)、轧差系统(nets)和业务汇总核对子系统等)的交互，对待支付业务进行处理。处理完成后，该业务处理单元1(例如图2中的网银系统ibps)会将该笔网银贷记业务转发至接收行bankb，紧接着，支付报文传输系统(pmts)收到一笔网银贷记回执业务：发起行为bankb，接收行为banka，同上描述，通过调用路由组件进行路由，将该笔报文发送至业务处理单元1处理，正好与原网银贷记业务在同一业务处理单元1处理，可匹配到原业务。

在一个实施例中，服务管理组件还用于接收每个业务处理单元对业务关联系统公共消息的预订消息，将预订消息发送至多个路由组件；

路由组件还用于将预订消息提供给业务关联系统；

业务关联系统根据预订消息，将公共消息发送至预订了公共消息的业务处理单元。

具体实施时，通过服务管理组件的ui界面管理消息订阅范围，传统的集中式的一个业务处理单元转变为分布式的多个业务处理单元后，为解决业务关联系统服务间交互由一对一变为多变多后产生的公共消息发送问题，引入消息订阅机制，即：业务关联系统向业务处理单元发送公共消息时，通过查询路由组件的订阅信息(预订消息)，向所有已订阅的业务处理单元广播发送公共消息。如图2所示，以网银系统(ibps)实例订阅公共控制管理系统(ccms)的系统状态变更通知报文为例，ccms向ibps发送系统状态变更通知报文时，先查询路由组件的有哪些ibps实例订阅了该报文，再逐个向订阅了该报文的ibps实例(业务处理单元)发送报文，提高了支付业务系统的可靠性和支付效率。

在一个实施例中，如图3所示，服务管理组件可以包括：

信息接收模块101，用于接收每个业务处理单元的信息；

信息处理模块102，与信息接收模块连接，用于根据每个业务处理单元的信息，配置每个业务处理单元应处理待支付业务的策略；

第一网络通信模块103，用于将策略发送至多个路由组件。

具体实施时，信息接收模块101还可以接收：

(1)订阅信息(预订消息，下文对该订阅消息进行了详细介绍)，如系统号(公共控制管理系统ccms和轧差系统nets等的系统号)、报文类型、订阅者、订阅范围等。

(2)业务处理单元的节点信息，如节点名称、所属业务处理单元、节点ip、节点端口号、节点存活状态(可用状态)等，具体实施时，本发明实施例中提到的节点指的是每个业务处理单元中的每台计算机(计算节点)，或服务器等。

(3)参数信息，包含服务管理组件的ip地址、端口号、及可用性信息等(新增第一个实例时需要)。

下面对服务管理组件的各个模块进行详细介绍。

在一个实施例中，信息接收模块具体用于：接收每个业务处理单元的变更信息；

信息处理模块具体用于：根据每个业务处理单元的变更信息，重新配置每个业务处理单元应处理待支付业务的策略；

第一网络通信模块具体用于：将重新配置的每个业务处理单元应处理待支付业务的策略发送至多个路由组件。

具体实施时，业务处理单元的信息发生变更时，根据变更后的业务处理单元的信息，重新配置每个业务处理单元应处理待支付业务的策略，即进行路由消息的补发，保证了支付系统支付的可靠性。

具体实施时，业务处理单元的信息发生变更的原因可以体现为：当服务管理组件判断业务处理单元处理待支付业务不符合预设指标值时，这时就需要根据每个业务处理单元的变更信息，重新配置每个业务处理单元应处理待支付业务的策略。

业务处理单元处理待支付业务不符合预设指标值指的是：业务处理单元的处理能力超过单个业务处理单元预设的处理能力，其衡量指标是报文响应时间和吞吐量不符合支付业务系统(例如：网银系统ibps)的性能指标，出现处理瓶颈。举个例子：例如对第三方贷记及回执业务，涉及三方机构，如果第三方贷记及回执业务量过大，超过了单个实例的处理能力，也无法有效解决性能问题，此时，可依据报文标识号按实例个数取模，对业务进行均衡划分，实现真正意义上的水平可扩展，具体理由为：每个报文的报文标识号具有唯一性，按照实例个数n取模，可保证业务报文被均衡的分发至n个网银业务实例处理，从而实现业务的均衡划分。

上述方案也正体现了：分布式支付业务处理场景下，部署同一支付业务系统的多个业务处理单元，每个业务处理单元包含多个节点，统一对外提供一致的服务，但是业务处理单元之间有着明确的业务范围划分，因此，通过调整各业务处理单元的业务受理范围，可将业务在各业务处理单元间均衡划分，从而实现支付业务系统并发处理能力的极大提升。

在一个实施例中，信息接收模块具体用于：接收监控系统pams发来的业务处理单元的状态信息，以及业务处理单元各个节点的状态信息；

信息处理模块具体用于：根据监控系统pams发来的业务处理单元的状态信息，以及业务处理单元各个节点的状态信息，维护业务处理单元以及业务处理单元各个节点。

具体实施时，服务管理组件可以维护节点健康状态，具体过程可以包括：支付应用监控系统pams定时监控节点健康状态(即可用状态或故障状态等)，并将业务处理单元以及业务处理单元各个节点的存活状态信息(即可用状态或故障状态信息等)发送至服务管理组件；服务管理组件根据监控的业务处理单元以及业务处理单元各个节点的状态信息，维护业务处理单元以及业务处理单元各个节点，保证了支付业务系统支付的可靠性。

在一个实施例中，信息接收模块具体用于：接收每个业务处理单元各个节点的可用情况信息；

信息处理模块具体用于：根据每个业务处理单元各个节点的可用情况信息，判断每个业务处理单元的可用情况，根据每个业务处理单元的可用情况，配置每个业务处理单元应处理待支付业务的策略；

第一网络通信模块具体用于：将根据每个业务处理单元的可用情况，配置的每个业务处理单元应处理待支付业务的策略发送至多个路由组件。

具体实施时，一个业务处理单元可包含多个节点，当单个业务处理单元的所有节点均不可用时，判断该业务处理单元为不可用；反之，若单个业务处理单元有一个及以上节点可用时，判断业务处理单元为可用，根据每个业务处理单元的可用情况，配置每个业务处理单元应处理待支付业务的策略，保证了支付业务系统支付的可靠性。

在一个实施例中，服务管理组件具体用于：接收每个业务处理单元及其备用业务处理单元的信息，根据每个业务处理单元及其备用业务处理单元的信息，配置每个业务处理单元应处理待支付业务的策略，将策略发送至多个路由组件。

具体实施时，分布式支付业务系统的每个业务处理单元都设置一个备用业务处理单元，服务管理组件在配置策略时，将业务处理单元的备用业务处理单元信息也考虑在内，在业务处理单元出现故障或不可用时，利用该业务处理单元的备用业务处理单元进行业务处理，这样实例(业务处理单元)间通过互为备份可实现业务自动接管，从而提供更高的业务连续运行能力，降低了单实例节点的可靠性要求，例如：由于每个业务处理单元都设置一个备用业务处理单元，因此，在配置业务处理单元时，可以选用配置相对低，价格相对便宜的服务器等，业务处理单元部署可选用多厂商多类型的服务器、操作系统及数据库，支持多种类型的软硬件平台等。

在一个实施例中，路由组件200可以包括：路由接口201、第二网络通信模块202、信息更新模块203和共享内存区204，其中：

第二网络通信模块202，与服务管理组件连接，用于接收每个业务处理单元应处理待支付业务的策略；

信息更新模块203，用于将每个业务处理单元应处理待支付业务的策略更新至共享内存区204，根据策略，以及支付业务系统接收的待支付业务，从多个业务处理单元中确定出一个处理待支付业务的业务处理单元；

路由接口201，用于连接与业务处理单元交互的业务关联系统和信息更新模块203，将确定出的业务处理单元的信息提供给业务关联系统。

具体实施时，与路由接口201连接的业务关联系统包括如下表1所示的业务关联系统(调用方)，下表1中也示出了路由接口201具体包括哪些类型的接口、功能及与之连接的业务关联系统。

表1

在一个实施例中，共享内存区可以包括：主共享内存区和备共享内存区；

信息更新模块具体用于：

将每个业务处理单元应处理待支付业务的策略更新至备共享内存区；

将所述备共享内存区变更为主共享内存区，将原主共享内存区变更为备共享内存区；

根据变更后主共享内存区内的策略，以及支付业务系统接收的待支付业务，从多个业务处理单元中确定出一个处理待支付业务的业务处理单元。

具体实施时，信息更新模块203先将每个业务处理单元应处理待支付业务的策略更新至备共享内存区，然后进行主备切换：将备共享内存区更换为主共享内存区，将原主共享内存区更换为备共享内存区，确保了路由信息(包括业务处理单元应处理待支付业务的策略)在多个路由组件的同步更新，保证业务处理正确性与一致性。

服务管理组件对处理支付业务的业务处理单元信息进行管理和存储，并将变更后的路由信息组织为消息串发送给所有的消息路由组件，为保证多个节点间路由信息的同步更新与启用，服务管理组件采用四阶段同步生效机制，以保证广播的路由信息同步更新至所有路由组件，本发明实施例中，路由消息可以包括：预订的公共消息(订阅消息)、策略等等。下面结合图4，对这四阶段同步生效机制进行详细介绍。

在一个实施例中，路由组件具体用于将每个业务处理单元应处理待支付业务的策略存储在共享内存区，供业务关联系统调用；共享内存区包括：主共享内存区和备共享内存区；

服务管理组件具体用于：

将每个业务处理单元应处理待支付业务的策略发送至各个路由组件，接收各个路由组件发来的策略已更新至备共享内存区的响应信息；

将路由组件共享内存区加锁通知信息发送至各个路由组件，接收各个路由组件发来的路由组件共享内存区加锁完毕响应信息；

将路由组件主备内存切换信息发送至各个路由组件，接收各个路由组件发来的路由组件主备内存切换完毕响应信息；

将路由组件共享内存区解锁通知信息发送至各个路由组件，接收各个路由组件发来的路由组件共享内存区解锁完毕响应信息；

路由组件具体用于：

接收服务管理组件发来的每个业务处理单元应处理待支付业务的策略，将策略更新至备共享内存区，发送策略已更新至备共享内存区的响应信息至服务管理组件；

接收服务管理组件发来的路由组件共享内存区加锁通知信息，对共享内存区进行加锁，将路由组件共享内存区加锁完毕响应信息发送至服务管理组件；

接收服务管理组件发来的路由组件主备内存切换信息，将原备共享内存区变更为主共享内存区，将原主共享内存区变更为备共享内存区，将路由组件主备内存切换完毕响应信息发送至服务管理组件；

接收路由组件共享内存区解锁通知信息，对共享内存区进行解锁，将路由组件共享内存区解锁完毕响应信息发送至服务管理组件。

下面结合图4，举个例子以说明本发明实施例提供的四阶段同步生效机制如何实施。

(1)一阶段：服务管理组件组织“路由变更预通知报文”(包括每个业务处理单元应处理待支付业务的策略)并广播至各个路由组件，路由组件收到“路由变更预通知报文”后，尝试更新备用共享内存区，并依据更新状态组织“路由变更预响应报文”(包括：策略已更新至备共享内存区的响应信息)回复至服务管理组件。

服务管理组件收到各个路由组件反馈的“路由变更预响应报文”后，确认是否所有的路由组件均已成功更新备用内存区。如果是，则进入(2)二阶段。否则，转至1a)。

1a)记录错误日志，转入人工处理，查看问题原因。

(2)二阶段：服务管理组件组织“路由变更加锁通知报文”(包括：路由组件共享内存区加锁通知信息)并广播至各个路由组件，路由组件收到“路由变更加锁通知报文”后，尝试对主共享内存区和备共享内存区加锁，加锁成功后业务系统无法访问路由组件，处于锁等待状态，并依据加锁状态组织“路由变更加锁响应报文”(包括：路由组件共享内存区加锁完毕响应信息)回复至服务管理组件。

服务管理组件收到各个路由组件反馈的“路由变更加锁响应报文”后，确认是否所有的路由组件均已成功对共享内存加锁。如果是，则进入(3)三阶段；否则，转至2a)。

2a)记录错误日志，转至人工处理，查看问题原因。

(3)三阶段：服务管理组件组织“路由变更切换通知报文”(包括：路由组件主备内存切换信息)并广播至各个路由组件，路由组件收到“路由变更切换通知报文”后，尝试切换共享内存区的主备标识(即将原备共享内存区变更为主共享内存区，将原主共享内存区变更为备共享内存区)，并依据切换状态组织“路由变更切换响应报文”(包括：路由组件主备内存切换完毕响应信息)回复至服务管理组件。

服务管理组件收到各个路由组件反馈的“路由变更切换响应报文”(包括：路由组件主备内存切换完毕响应信息)后，确认是否所有的路由组件均已成功对完成主备内存的切换。如果是，则进入(4)四阶段；否则，转至3a)。

3a)进入(4)四阶段。

(4)四阶段：服务管理组件组织“路由变解锁通知报文”(包括：路由组件共享内存区解锁通知信息)并广播至各个路由组件，路由组件收到“路由变更解锁通知报文”后，尝试对主共享内存区和备共享内存区解锁，解锁成功后支付业务系统继续进行，并依据解锁状态组织“路由变更解锁响应报文”回复至服务管理组件。

服务管理组件收到各个路由组件反馈的“路由变更解锁响应报文”(包括：路由组件共享内存区解锁完毕响应信息)后，确认是否所有的路由组件均已成功解锁共享内存。如果是，则路由变更信息广播已成功；否则，转至4a)。

4a)记录错误日志，转至人工处理。

具体实施时，上述四阶段的消息同步机制中，在进行主备内存切换时，即：将原备共享内存区变更为主共享内存区，将原主共享内存区变更为备共享内存区时，进行加锁和解锁的过程原因是：主共享内存区供路由决策使用，即各个业务关联系统调用路由组件的存储信息时，是调用主共享内存区的存储内容，更新共享内存和路由决策是两个异步的过程，分属不同的进程，因此会涉及到对共享区的互斥读写。因此，在进行主备内存切换时，对主共享内存区和备共享内存区进行加锁，加锁成功后各个业务关联系统无法访问路由组件，处于锁等待状态，待主备内存切换完毕时，各个业务关联系统可以访问路由组件，保证了各个业务关联系统调用路由消息(包括策略和订阅消息)的准确性，即保证了支付业务系统处理支付业务的可靠性。

另外，服务管理组件也可以根据上述四阶段的消息同步机制，将上述预订的公共消息(订阅消息)发送至各个路由组件，与路由组件进行通信。

本发明实施例实现了如下技术效果：本发明通过构建服务控制管理组件装置，支持支付业务系统由集中式应用处理架构调整为分布式架构，具有良好的横向可伸缩性，由多个业务处理单元并行处理支付业务，极大地提升了支付业务处理容量，提高了支付业务的处理效率，保证了支付业务的连续运行能力，同时简化了现有支付业务系统改造，降低了软硬件采购成本。

显然，本领域的技术人员应该明白，上述的本发明实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明实施例不限制于任何特定的硬件和软件结合。

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