CN110336847A - 支付报文传输系统及方法 - Google Patents

Abstract

本申请提供一种支付报文传输系统及方法，系统包括：MQ传输模块，用于将对应的前置机接收的消息队列中的支付报文以MQ传输方式依次经城市处理中心和国家处理中心发送至对应的支付系统的网上支付跨行清算系统；Kafka传输模块，用于将对应的前置机接收的消息队列中的支付报文以Kafka传输方式依次经城市处理中心和国家处理中心发送至对应的支付系统的网上支付跨行清算系统，并在所述支付报文的传输过程中，向对应的zookeeper集群实时发送目的节点。本申请能够有效提高支付报文的传输方式的多样性，并能够有效提高支付报文传输的效率和可靠性，进而能够保证金融行业的银行系统的可靠运行。

Description

支付报文传输系统及方法

技术领域

本申请涉及数据传输技术领域，具体涉及一种支付报文传输系统及方法。

背景技术

在金融行业的银行系统中，目前用于一般使用IBM的消息队列WebSphere MQ来进行支付报文的传输。MQ是一种应用程序对应用程序的通信方法。应用程序通过写和检索出入列队的针对应用程序的数据(消息)来通信，而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。

现有技术中，由于仅应用MQ进行消息传输的方式单一，接入形式没有其他选择，随着手机支付等终端支付方式的增加带来的对消息传输的形式要求的增多，单一的支付报文的传输方式已无法金融行业的银行系统的报文传输需求和效率，且无法满足部分报文传输的可靠性要求。

因此，亟需提供一种报文传输方式多样且可靠性高的支付报文传输方法。

发明内容

针对现有技术中的问题，本申请提供一种支付报文传输系统及方法，能够有效提高支付报文的传输方式的多样性，并能够有效提高支付报文传输的效率和可靠性，进而能够保证金融行业的银行系统的可靠运行。

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

第一方面，本申请提供一种支付报文传输系统，包括：

MQ传输模块，用于将对应的前置机接收的消息队列中的支付报文以MQ传输方式依次经城市处理中心和国家处理中心发送至对应的支付系统的网上支付跨行清算系统；

Kafka传输模块，用于将对应的前置机接收的消息队列中的支付报文以Kafka传输方式依次经城市处理中心和国家处理中心发送至对应的支付系统的网上支付跨行清算系统，并在所述支付报文的传输过程中，向对应的zookeeper集群实时发送目的节点。

进一步地，还包括：

HTTP请求接入模块，用于应用HTTP代理单元将对应的前置机接收的支付报文依次经城市处理中心和国家处理中心发送至对应的支付系统的网上支付跨行清算系统。

进一步地，还包括：

混合传输模块，用于将对应的前置机接收的支付报文以MQ消息队列传输及Kafka分布式消息队列传输的方式依次经城市处理中心和国家处理中心发送至对应的支付系统的网上支付跨行清算系统，并在该支付报文以Kafka分布式消息队列传输的方式进行传输的过程中，向所述zookeeper集群实时发送目的节点。

进一步地，所述MQ传输模块包括：与所述前置机对应的第一MQ单元、与所述城市处理中心对应的第二MQ单元、与所述国家处理中心对应的第三MQ单元，以及，与所述支付系统的网上支付跨行清算系统对应的第四MQ单元；

所述第一MQ单元、第二MQ单元、第三MQ单元和第四MQ单元之间依次通信连接。

进一步地，所述Kafka传输模块包括：

与所述前置机对应的第一Kafka单元、与所述城市处理中心对应的第二Kafka单元、与所述国家处理中心对应的第三Kafka单元，以及，与所述支付系统的网上支付跨行清算系统对应的第四Kafka单元；

所述第一Kafka单元、第二Kafka单元、第三Kafka单元和第四Kafka单元之间依次通信连接，且所述第一Kafka单元、第二Kafka单元、第三Kafka单元和第四Kafka单元分别与所述zookeeper集群通信连接。

进一步地，所述HTTP请求接入模块包括：

与所述前置机对应的第一HTTP代理单元、与所述城市处理中心对应的第二HTTP代理单元、与所述国家处理中心对应的第三HTTP代理单元，以及，与所述支付系统的网上支付跨行清算系统对应的第四HTTP代理单元；

所述第一HTTP代理单元、第二HTTP代理单元、第三HTTP代理单元和第四HTTP代理单元之间依次通信连接。

进一步地，所述混合传输模块包括：

与所述前置机对应的第五MQ单元、与所述城市处理中心对应的第五Kafka单元、与所述国家处理中心对应的第六Kafka单元，以及，与所述支付系统的网上支付跨行清算系统对应的第六MQ单元；

所述第五MQ单元、第五Kafka单元、第六Kafka单元和第六MQ单元之间依次通信连接，且所述第五Kafka单元和第六Kafka单元分别与所述zookeeper集群通信连接。

第二方面，本申请提供一种支付报文传输方法，该支付报文传输方法应用所述的支付报文传输系统实现，所述支付报文传输方法包括：

所述前置机接收支付报文，并根据zookeeper集群查询各个所述城市处理中心的负载均衡情况以及各个所述城市处理中心与国家处理中心的连接情况，并选取一个所述城市处理中心作为所述支付报文当前的投递目的地，将包含有该城市处理中心的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后、将所述支付报文传输至所述Kafka传输模块中对应的所述城市处理中心对应的第二Kafka单元中；

所述城市处理中心自所述第二Kafka单元获取所述支付报文，并确定一国家处理中心作为所述支付报文当前的投递目的地，将包含有该国家处理中心的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后将所述支付报文传输至对应的所述国家处理中心对应的第三Kafka单元中；

所述国家处理中心自所述第三Kafka单元获取所述支付报文，并确定一支付系统的网上支付跨行清算系统作为所述支付报文当前的投递目的地，将包含有该支付系统的网上支付跨行清算系统的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后将所述支付报文传输至对应的所述支付系统的网上支付跨行清算系统对应的第四Kafka单元中；

所述支付系统的网上支付跨行清算系统自所述第四Kafka单元获取所述支付报文，并检查该支付报文的合法性并对该支付报文进行对应处理，并将包含有该支付报文对应处理结果的报文接收信息发送至所述zookeeper集群。

进一步地，所述前置机接收支付报文，并根据zookeeper集群查询各个所述城市处理中心的负载均衡情况以及各个所述城市处理中心与国家处理中心的连接情况，并选取一个所述城市处理中心作为所述支付报文当前的投递目的地，将包含有该城市处理中心的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后、将所述支付报文传输至所述Kafka传输模块中对应的所述城市处理中心对应的第二Kafka单元中，包括：

所述前置机接收预设参与机构发送的支付报文，并根据本地配置文件确定能够投递该支付报文的多个城市处理中心；

所述前置机根据所述zookeeper集群查询各个所述城市处理中心的负载均衡情况以及各个所述城市处理中心与国家处理中心的连接情况，进而得到三级链路的可用情况；

所述前置机根据第一预设规则以及所述三级链路的可用情况，选取一个所述城市处理中心作为所述支付报文当前的投递目的地，并将包含有该城市处理中心的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后应用其对应的第一Kafka单元将所述支付报文传输至对应的所述城市处理中心对应的第二Kafka单元中。

进一步地，所述第一预设规则包括：

若当前的所述城市处理中心和国家处理中心无法进行通信，则放弃投递该城市处理中心，并继续判断下一个所述城市处理中心是否可以与国家处理中心通信，直到确定能够与所述国家处理中心通信的一个城市处理中心作为所述支付报文当前的投递目的地；

在能够投递该支付报文的多个城市处理中心中选取负载小于预设负载值的城市处理中心作为所述支付报文当前的投递目的地；

根据负载均衡算法选取所述支付报文的投递方式。

进一步地，所述城市处理中心自所述第二Kafka单元获取所述支付报文，并确定一国家处理中心作为所述支付报文当前的投递目的地，将包含有该国家处理中心的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后将所述支付报文传输至对应的所述国家处理中心对应的第三Kafka单元中，包括：

所述城市处理中心自所述第二Kafka单元获取所述支付报文，并检查该支付报文的合法性并对该支付报文进行对应的添加操作；

所述城市处理中心读取所述支付报文对应的配置信息，并根据该配置信息及第二预设规则，确定一国家处理中心作为所述支付报文当前的投递目的地，将包含有该国家处理中心的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后应用所述第二Kafka单元将所述支付报文传输至对应的所述国家处理中心对应的第三Kafka单元中。

进一步地，所述第二预设规则包括：

根据所述配置信息获取第一投递列表，该第一投递列表用于存储所述支付报文与所述国家处理中心之间的对应关系，并获取所述支付系统的网上支付跨行清算系统和国家处理中心的连接情况，筛选得到与所述支付系统的网上支付跨行清算系统连接正常的国家处理中心；

在能够投递该支付报文的国家处理中心中选取负载小于预设负载值的国家处理中心作为所述支付报文当前的投递目的地；

根据负载均衡算法选取所述支付报文的投递方式。

进一步地，所述国家处理中心自所述第三Kafka单元获取所述支付报文，并确定一支付系统的网上支付跨行清算系统作为所述支付报文当前的投递目的地，将包含有该支付系统的网上支付跨行清算系统的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后将所述支付报文传输至对应的所述支付系统的网上支付跨行清算系统对应的第四Kafka单元中，包括：

所述国家处理中心自所述第三Kafka单元获取所述支付报文，并检查该支付报文的合法性并对该支付报文进行对应的添加操作；

所述国家处理中心读取所述支付报文对应的配置信息，并根据该配置信息及第三预设规则确定所述支付系统的网上支付跨行清算系统作为所述支付报文当前的投递目的地，将包含有该支付系统的网上支付跨行清算系统的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后应用所述第三Kafka单元将所述支付报文传输至对应的所述支付系统的网上支付跨行清算系统对应的第四Kafka单元中。

进一步地，所述第三预设规则包括：

根据所述配置信息获取第二投递列表，该第二投递列表用于存储所述支付报文与所述支付系统的网上支付跨行清算系统之间的对应关系，并筛选得到当前与所述国家处理中心连接正常的所述支付系统的网上支付跨行清算系统；

根据负载均衡算法选取所述支付报文的投递方式。

由上述技术方案可知，本申请提供一种支付报文传输系统及方法，其中的系统通过MQ传输模块，用于将对应的前置机接收的消息队列中的支付报文以MQ传输方式依次经城市处理中心和国家处理中心发送至对应的支付系统的网上支付跨行清算系统；Kafka传输模块，用于将对应的前置机接收的消息队列中的支付报文以Kafka传输方式依次经城市处理中心和国家处理中心发送至对应的支付系统的网上支付跨行清算系统，并在所述支付报文的传输过程中，向对应的zookeeper集群实时发送目的节点，能够有效提高支付报文的传输方式的多样性，并能够有效提高支付报文传输的效率和可靠性，进而能够保证金融行业的银行系统的可靠运行。

附图说明

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

图1为现有的支付报文传输方式的逻辑示意图。

图2为本申请实施例中的支付报文传输系统的第一种结构示意图。

图3为本申请实施例中的支付报文传输系统的第二种结构示意图。

图4为本申请实施例中的支付报文传输系统的第三种结构示意图。

图5为本申请实施例中的支付报文传输系统的第四种结构示意图。

图6为本申请实施例中的支付报文传输系统的举例结构示意图。

图7为本申请实施例中的支付报文传输方法的流程示意图。

图8为本申请应用实例中的从外到内正常传递过程中的使用Kafka报文传输过程的流程示意图。

图9为本申请应用实例中的从外到内正常传递过程中的使用HTTP请求调用过程的流程示意图。

图10为本申请应用实例中的从外到内异常处理过程的流程示意图。

具体实施方式

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

在现有技术中的支付报文的传输过程中，参见图1，XML格式的报文通过IBM MQ或者东方通的TongLINK/Q(简称TLQ)将报文远程投递，通过实时的点到点探测存活状态和自定义路由判断确认报文传输的目的地，将报文投递到城市处理中心；路由处理、队列监控、负载均衡和节点探测存活状态等，独立于报文传输组件；模块代码和配置文件进行更新和发布时借助其他系统或者人工操作完成，而且不同层级的配置文件需要进行定制化，新增加业务系统需要定制化代码传输模块，导致代码的管理更加复杂；城市处理中心到国家处理中心也是通过实时的点到点探测存活状态和自定义路由判断确认报文传输的目的地，国家处理中心到内部系统使用同样的方法；点到点的探测范围是上下级之间，即两级探测；节点故障后，已经传输到队列中的信息不能被自动化的重新处理，人工处理时间长会导致报文超时，对用户体验相对差。也就是说，在现有技术中的支付报文的传输过程中，其接入形式单一，只有通过队列形式进行XML报文的传输，以及报文传输形式单一，目前支付系统大部分采用IBM MQ进行区域与区域之间的传输，小部分使用了TLQ；数据中心级别故障情况下，自动化切换需要第一级明确第三级的存活状态，即三级探测，目前的两级探测满足不了要求；而目前流行消息传输组件中出现很多实用的新颖功能，例如节点关系维护、负载均衡、存活情况探测、主动备份实现断点重续、事务性消息传输、独立订阅发布机制、节点自动发现等。通过在现有产品上进行改造实现新颖的功能设计，一方面将耗费很多的人力和精力，目前流行、成熟的产品也是经过了多年的开发和实践经验获得的，另外一方面还是建立在对IBM产品依赖的基础上。

基于此，考虑到现有的支付报文传输方式存在的单一的支付报文的传输方式已无法金融行业的银行系统的报文传输需求和效率，且无法满足部分报文传输的可靠性要求，本申请提供一种支付报文传输系统及方法，通过MQ传输模块，用于将对应的前置机接收的消息队列中的支付报文以MQ传输方式依次经城市处理中心和国家处理中心发送至对应的支付系统的网上支付跨行清算系统；Kafka传输模块，用于将对应的前置机接收的消息队列中的支付报文以Kafka传输方式依次经城市处理中心和国家处理中心发送至对应的支付系统的网上支付跨行清算系统，并在所述支付报文的传输过程中，向对应的zookeeper集群实时发送目的节点，能够有效提高支付报文的传输方式的多样性，并能够有效提高支付报文传输的效率和可靠性，进而能够保证金融行业的银行系统的可靠运行。

本申请提供一种支付报文传输系统的实施例，参见图2，所述支付报文传输系统具体包含有如下内容：

MQ传输模块10，用于将对应的前置机接收的消息队列中的支付报文以MQ传输方式依次经城市处理中心和国家处理中心发送至对应的支付系统的网上支付跨行清算系统。

在上述描述中，所述前置机是一种以报文交换为基础的中间交易设备，前置机处理的所有交易都以金融交易报文为基础。利用报文可以很容易将金融交易的各项要求表述清楚。只要将报文格式定义明确，任何金融交易的细节都可以包含在报文之中。交易报文的制定可以参照ISO 8583国际标准。交易报文的种类有通知类和请求/响应类两种。如果金融交易只涉及系统/网络管理，可简单地采用通知类报文；如果金融交易涉及帐务处理，可采用请求/响应类报文。目前在银行普遍采用前置机的有ATM、POS、IC卡、银联金卡、电话银行、券银通、银税通、即缴费、公积金管理系统、电子汇兑和同城清算等系统。这些前置机都具有前面所述的一种到多种功能。

可以理解的是，所述MQ传输方式是指以IBM的消息队列WebSphere MQ来进行支付报文的传输；所述支付系统的网上支付跨行清算系统(Online payment interbanksettlement system)是一种人民币跨行支付清算基础设施。网上支付跨行清算系统主要支持网上跨行零售业务的处理，业务指令逐笔发送、实时轧差、定时清算。客户可通过在线方式提交支付业务，并可实时获取业务处理结果。系统支持商业银行以及经中国人民银行批准的非金融支付服务机构接入，并向用户提供7×24小时全天候服务。

Kafka传输模块20，用于将对应的前置机接收的消息队列中的支付报文以Kafka传输方式依次经城市处理中心和国家处理中心发送至对应的支付系统的网上支付跨行清算系统，并在所述支付报文的传输过程中，向对应的zookeeper集群实时发送目的节点。

其中，Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。对于像Hadoop一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群来提供实时的消息。

可以理解的是，所述zookeeper集群是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。ZooKeeper是以Fast Paxos算法为基础的，Paxos算法存在活锁的问题，即当有多个proposer交错提交时，有可能互相排斥导致没有一个proposer能提交成功，而Fast Paxos作了一些优化，通过选举产生一个leader(领导者)，只有leader才能提交proposer，具体算法可见Fast Paxos。

从上述描述可知，本申请的支付报文传输系统，在提供以IBM的消息队列WebSphere MQ来进行支付报文的传输的同时，还提供以Kafka及zookeeper集群来进行支付报文的传输的方式，能够有效实现三级链路的监管，从管理功能上，通过zookeeper进行集群管理，节点自动完成周围节点的探测存活情况上报给zookeeper，zookeeper也可以负责配置文件的发布订阅；从传输安全性上，Kafka集群中节点一主多从进行备份，主故障时自动从副本中选主进行切换；从消息发送事务方式上，即支持同步也支持异步；从节点新增或删除操作上，在Kafka中对生产端和消费端没有影响，只需要更新zookeeper列表并发布，但是IBM MQ需要对双方进行点对点的队列建立，进而能够有效提高支付报文的传输方式的多样性，并能够有效提高支付报文传输的效率和可靠性，进而能够保证金融行业的银行系统的可靠运行。

在本申请的一个实施例中，参见图3，所述支付报文传输系统还具体包含有如下内容：

HTTP请求接入模块30，用于应用HTTP代理单元将对应的前置机接收的支付报文依次经城市处理中心和国家处理中心发送至对应的支付系统的网上支付跨行清算系统。

其中，HTTP协议即超文本传输协议，是Internet上行信息传输时使用最为广泛的一种非常简单的通信协议。部分局域网对协议进行了限制，只允许用户通过HTTP协议访问外部网站。可以理解的是，所述HTTP代理单元具体可以为一种代理服务器，其中，代理(proxy)服务器是网络的中间实体。代理位于Web客户端和Web服务器之间，扮演中间人的角色。HTTP的代理服务器即是Web服务器又是Web客户端。

在本申请中，使用HTTP请求的接入方式是相对独立的，在有多层级的情况下，需要使用HTTP的代理和反向代理进行HTTP路由的控制。

在本申请的一个实施例中，参见图4，所述支付报文传输系统还具体包含有如下内容：

混合传输模块40，用于将对应的前置机接收的支付报文以MQ消息队列传输及Kafka分布式消息队列传输的方式依次经城市处理中心和国家处理中心发送至对应的支付系统的网上支付跨行清算系统，并在该支付报文以Kafka分布式消息队列传输的方式进行传输的过程中，向所述zookeeper集群实时发送目的节点。

可以理解的是，IBM MQ和Kafka混合使用的情况，会增加队列监控的复杂度，两种消息组件的模型是不同的，Kafka使用订阅发布机制，MQ使用的AMQP协议，但是对原有系统的影响是最小的。

其中，参见图5和图6，本申请的支付报文传输系统可以同时包含有：MQ传输模块10、Kafka传输模块20、HTTP请求接入模块30和混合传输模块40，通过多样化的接入方式和多种的传输方法，能够有效实现兼容性以及逐步替换原有方式，减少对原有传输过程的改造，提高稳定性和自动化。具体说明如下：

(1)在保持原传输形式的基础上，增加Kafka的传输方式，同时新增了HTTP请求的接入方式。

(2)对于Kafka+zookeeper的传输方式引入，首先从开源自主上，它是近年流行的、成熟的产品；从管理功能上，通过zookeeper进行集群管理，节点自动完成周围节点的探测存活情况上报给zookeeper，zookeeper也可以负责配置文件的发布订阅；从传输安全性上，Kafka集群中节点一主多从进行备份，主故障时自动从副本中选主进行切换；从消息发送事务方式上，即支持同步也支持异步；从节点新增或删除操作上，在Kafka中对生产端和消费端没有影响，只需要更新zookeeper列表并发布，但是IBM MQ需要对双方进行点对点的队列建立。

(3)从兼容性上，图6中的四条线路可以并行独立运行，具体如下：

3-1.使用kafka的方式有两种，一种是从参与机构的前置机接入开始就接入Kafka，到支付系统的各子系统也采用Kafka的形式；两外一种是参与机构到城市处理中心还是使用原有形式，从国家处理中心到支付系统各子系统采用原有方式，这样对参与机构和支付系统影响较小。

3-2.使用HTTP请求的接入方式是相对独立的，在有多层级的情况下，需要使用HTTP的代理和反向代理进行HTTP路由的控制；

3-3.新增的报文传输方式和原有方式的共同点，在进行层级与层级之间转发报文时需要通过根据定制化的需求控制消息的投递小组对象，城市处理中心按城市划为一个小组，国家处理中心按数据中心划分为一个小组，支付系统按系统或者实例划分为一个小组。

(4)IBM MQ和Kafka混合使用的情况，会增加队列监控的复杂度，两种消息组件的模型是不同的，Kafka使用订阅发布机制，MQ使用的AMQP协议，但是对原有系统的影响是最小的。

在本申请的一个具体实施例中，所述MQ传输模块10具体包含有：与所述前置机对应的第一MQ单元、与所述城市处理中心对应的第二MQ单元、与所述国家处理中心对应的第三MQ单元，以及，与所述支付系统的网上支付跨行清算系统对应的第四MQ单元；所述第一MQ单元、第二MQ单元、第三MQ单元和第四MQ单元之间依次通信连接。

在本申请的一个具体实施例中，所述Kafka传输模块20具体包含有：与所述前置机对应的第一Kafka单元、与所述城市处理中心对应的第二Kafka单元、与所述国家处理中心对应的第三Kafka单元，以及，与所述支付系统的网上支付跨行清算系统对应的第四Kafka单元；所述第一Kafka单元、第二Kafka单元、第三Kafka单元和第四Kafka单元之间依次通信连接，且所述第一Kafka单元、第二Kafka单元、第三Kafka单元和第四Kafka单元分别与所述zookeeper集群通信连接。

在本申请的一个具体实施例中，所述HTTP请求接入模块30具体包含有：与所述前置机对应的第一HTTP代理单元、与所述城市处理中心对应的第二HTTP代理单元、与所述国家处理中心对应的第三HTTP代理单元，以及，与所述支付系统的网上支付跨行清算系统对应的第四HTTP代理单元；所述第一HTTP代理单元、第二HTTP代理单元、第三HTTP代理单元和第四HTTP代理单元之间依次通信连接。

在本申请的一个具体实施例中，所述混合传输模块40具体包含有：与所述前置机对应的第五MQ单元、与所述城市处理中心对应的第五Kafka单元、与所述国家处理中心对应的第六Kafka单元，以及，与所述支付系统的网上支付跨行清算系统对应的第六MQ单元；所述第五MQ单元、第五Kafka单元、第六Kafka单元和第六MQ单元之间依次通信连接，且所述第五Kafka单元和第六Kafka单元分别与所述zookeeper集群通信连接。

在上述描述中，所述第一至第六MQ单元均可以为MQ服务器，所述第一至第六Kafka单元均可以为Kafka服务器，所述第一至第四HTTP代理单元均可以为HTTP代理服务器。

为了能够有效提高支付报文传输的效率和可靠性，进而能够保证金融行业的银行系统的可靠运行，本申请还提供一种应用上述支付报文传输系统中的全部或部分内容实现的一种支付报文传输方法的实施例，参见图7，所述支付报文传输方法具体包含有如下内容：

步骤100：所述前置机接收支付报文，并根据zookeeper集群查询各个所述城市处理中心的负载均衡情况以及各个所述城市处理中心与国家处理中心的连接情况，并选取一个所述城市处理中心作为所述支付报文当前的投递目的地，将包含有该城市处理中心的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后、将所述支付报文传输至所述Kafka传输模块中对应的所述城市处理中心对应的第二Kafka单元中。

步骤200：所述城市处理中心自所述第二Kafka单元获取所述支付报文，并确定一国家处理中心作为所述支付报文当前的投递目的地，将包含有该国家处理中心的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后将所述支付报文传输至对应的所述国家处理中心对应的第三Kafka单元中。

步骤300：所述国家处理中心自所述第三Kafka单元获取所述支付报文，并确定一支付系统的网上支付跨行清算系统作为所述支付报文当前的投递目的地，将包含有该支付系统的网上支付跨行清算系统的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后将所述支付报文传输至对应的所述支付系统的网上支付跨行清算系统对应的第四Kafka单元中。

步骤400：所述支付系统的网上支付跨行清算系统自所述第四Kafka单元获取所述支付报文，并检查该支付报文的合法性并对该支付报文进行对应处理，并将包含有该支付报文对应处理结果的报文接收信息发送至所述zookeeper集群。

从上述描述可知，本申请的支付报文传输方法，在提供以IBM的消息队列WebSphere MQ来进行支付报文的传输的同时，还提供以Kafka及zookeeper集群来进行支付报文的传输的方式，能够有效实现三级链路的监管，从管理功能上，通过zookeeper进行集群管理，节点自动完成周围节点的探测存活情况上报给zookeeper，zookeeper也可以负责配置文件的发布订阅；从传输安全性上，Kafka集群中节点一主多从进行备份，主故障时自动从副本中选主进行切换；从消息发送事务方式上，即支持同步也支持异步；从节点新增或删除操作上，在Kafka中对生产端和消费端没有影响，只需要更新zookeeper列表并发布，但是IBM MQ需要对双方进行点对点的队列建立，进而能够有效提高支付报文的传输方式的多样性，并能够有效提高支付报文传输的效率和可靠性，进而能够保证金融行业的银行系统的可靠运行。

在一种具体实施方式中，所述支付报文传输方法中的步骤100具体包含有如下内容：

步骤101：所述前置机接收预设参与机构发送的支付报文，并根据本地配置文件确定能够投递该支付报文的多个城市处理中心。

步骤102：所述前置机根据所述zookeeper集群查询各个所述城市处理中心的负载均衡情况以及各个所述城市处理中心与国家处理中心的连接情况，进而得到三级链路的可用情况。

步骤103：所述前置机根据第一预设规则以及所述三级链路的可用情况，选取一个所述城市处理中心作为所述支付报文当前的投递目的地，并将包含有该城市处理中心的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后应用其对应的第一Kafka单元将所述支付报文传输至对应的所述城市处理中心对应的第二Kafka单元中。

可以理解的是，所述第一预设规则具体包含有如下内容：

(1)若当前的所述城市处理中心和国家处理中心无法进行通信，则放弃投递该城市处理中心，并继续判断下一个所述城市处理中心是否可以与国家处理中心通信，直到确定能够与所述国家处理中心通信的一个城市处理中心作为所述支付报文当前的投递目的地。

(2)在能够投递该支付报文的多个城市处理中心中选取负载小于预设负载值的城市处理中心作为所述支付报文当前的投递目的地。

(3)根据负载均衡算法选取所述支付报文的投递方式。

在一种具体实施方式中，所述支付报文传输方法中的步骤200具体包含有如下内容：

步骤201：所述城市处理中心自所述第二Kafka单元获取所述支付报文，并检查该支付报文的合法性并对该支付报文进行对应的添加操作。

步骤202：所述城市处理中心读取所述支付报文对应的配置信息，并根据该配置信息及第二预设规则，确定一国家处理中心作为所述支付报文当前的投递目的地，将包含有该国家处理中心的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后应用所述第二Kafka单元将所述支付报文传输至对应的所述国家处理中心对应的第三Kafka单元中。

可以理解的是，所述第二预设规则具体包含有如下内容：

(1)根据所述配置信息获取第一投递列表，该第一投递列表用于存储所述支付报文与所述国家处理中心之间的对应关系，并获取所述支付系统的网上支付跨行清算系统和国家处理中心的连接情况，筛选得到与所述支付系统的网上支付跨行清算系统连接正常的国家处理中心。

(2)在能够投递该支付报文的国家处理中心中选取负载小于预设负载值的国家处理中心作为所述支付报文当前的投递目的地。

(3)根据负载均衡算法选取所述支付报文的投递方式。

在一种具体实施方式中，所述支付报文传输方法中的步骤300具体包含有如下内容：

步骤301：所述国家处理中心自所述第三Kafka单元获取所述支付报文，并检查该支付报文的合法性并对该支付报文进行对应的添加操作。

步骤302：所述国家处理中心读取所述支付报文对应的配置信息，并根据该配置信息及第三预设规则确定所述支付系统的网上支付跨行清算系统作为所述支付报文当前的投递目的地，将包含有该支付系统的网上支付跨行清算系统的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后应用所述第三Kafka单元将所述支付报文传输至对应的所述支付系统的网上支付跨行清算系统对应的第四Kafka单元中。

可以理解的是，所述第三预设规则具体包含有如下内容：

(1)根据所述配置信息获取第二投递列表，该第二投递列表用于存储所述支付报文与所述支付系统的网上支付跨行清算系统之间的对应关系，并筛选得到当前与所述国家处理中心连接正常的所述支付系统的网上支付跨行清算系统。

(2)根据负载均衡算法选取所述支付报文的投递方式。

面临越来越多的业务接入需求，国产化、开源的产品越来成熟、功能更加完善，实现多样化的接入方式和多种的传输方法面临的主要技术问题是如何实现兼容性以及逐步替换原有方式，减少对原有传输过程的改造，提高稳定性和自动化。为了进一步说明本方案，本申请还提供一种应用所述支付报文传输系统实现支付报文传输方法的具体应用实例，本具体应用实例给出一种支付报文传输平台多渠道接入方法，如下：

(一)参见图8，从外到内正常传递过程中的使用Kafka报文传输过程

S11：某一银行作为支付系统参与机构，受理了网上支付跨行清算系统(简称网银)业务后组对应报文。

S12：通过访问前置机获取报文投递的目的地，前置机根据配置文件确认可以投递的城市处理中心，通过向zookeeper查询城市处理中心的负载均衡情况以及其和国家处理中心的连接情况，获取三级链路的情况，防止了信息在队列中的堵塞，处理过程如下描述：①如果城市处理中心和国家处理中心不能联通，放弃投递到这个城市处理中心，直到找到联通的；②查看联通的城市处理中心的负载情况，选择负载较少的；③根据均衡算法选择合适的TOPIC的partition投递报文。最后通知zookeeper相关情况。

S13：城市处理中心从Kafka拉消息，检查报文合法性、重新添加报文头等。

S14：读取配置信息判断报文投递的目的地信息，判断过程如下：①根据配置文件信息获取投递的对象-国家处理中心的列表，并获取支付系统的网上支付跨行清算系统和国家处理中心的连接情况，保留连接正常的；②从国家处理中心的负载情况，选择一个负载较弱的；③根据Kafka的partition负载均衡算法选择合适的投递。最后通知zookeeper相关情况。

S15：国家处理中心从Kafka中拉取报文，检查报文合法性、组报文等。

S16：读取配置信息判断报文投递的目的地信息，判断过程如下：①根据配置文件信息获取投递的对象列表，找到状态存活组；②根据Kafka的partition负载均衡算法选择合适的投递。最后通知zookeeper相关情况。

对于节点配置文件的更新，使用zookeeper的配置管理功能实现Kafka节点配置文件的发布订阅。节点关系维护、负载均衡、存活情况探测、主动备份实现断点重续、事务性消息传输、独立订阅发布机制、节点自动发现等功能通过Kafka和zookeeper可以实现。

(二)参见图9，从外到内正常传递过程中的使用HTTP请求调用过程

S21：某一银行受理网银业务后，组成对应的Http请求报文。

S22：前置机定时发起健康状态探测请求，①读取可以投递报文的目的地列表；②HTTP代理收到请求后可以直接返回应答表示和本节点的链路健康情况，也可以再次向下一层级的节点发送健康状态请求，接收到应答后返回结果给上层请求方，实现了三级探测的功能，或者实现全链路探测，全链路探测和服务调用路径一致，虽然全链路安全性高，但是灵活性相对差；③前置机根据请求返回结果更新目的地列表中状态。

S23：根据报文信息获取可投递的目的地列表，在目的地列表中选择状态正常的，根据报文投递的负载均衡算法选择一个对象投递报文。

S24：HTTP代理收到报文后调起服务，进行报文检查、组报文。

S25：HTTP代理判断此报文投递的国家处理中心目的地列表，同S22的定时探测进行多级或两级，探测结果更新到每个对象的状态。

S26：在国家处理中心的目的地列表中选择状态正常的，根据报文投递的负载均衡算法选择一个对象投递报文。

S27：国家处理中心根据报文类型等判断需要触发的服务对象所在的IP地址和端口等信息，然后调用对应服务。

S28：通过引入HTTP的接入形式，对用户的体验会更加丰富，为支付系统扩展业务提供了基础的技术支持。

(三)参见图10，从外到内异常处理过程

在支付报文传输链路中出现异常情况的处理方法，以HTTP请求的处理过程为例说明。

S31：如果前置机连接北京城市处理中心是不通的，那么可以转而连接广东城市处理中心。

S32：广东城市处理中心继续判断可以连接国家处理中心，如果国家处理中心1连接不通，可以连接国家处理中心2，保持业务的不间断。

S33：国家处理中心1判断网银系统实例状态，网银系统是多实例模式，如果节点1或者实例1故障，将报文投递到节点2或者实例2处理。

从上述描述可知，本申请的应用实例提供的支付报文传输方法，增加了支付报文传输方式及增加了支付报文接入方式，能够有效提高支付报文的传输方式的多样性，并能够有效提高支付报文传输的效率和可靠性，进而能够保证金融行业的银行系统的可靠运行。

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

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

虽然本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

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

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

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

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

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

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

本领域技术人员应明白，本说明书的实施例可提供为方法、系统或计算机程序产品。因此，本说明书实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。

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

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书实施例的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

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

Claims (14)

1.一种支付报文传输系统，其特征在于，包括：

MQ传输模块，用于将对应的前置机接收的消息队列中的支付报文以MQ传输方式依次经城市处理中心和国家处理中心发送至对应的支付系统的网上支付跨行清算系统；

Kafka传输模块，用于将对应的前置机接收的消息队列中的支付报文以Kafka传输方式依次经城市处理中心和国家处理中心发送至对应的支付系统的网上支付跨行清算系统，并在所述支付报文的传输过程中，向对应的zookeeper集群实时发送目的节点。

2.根据权利要求1所述的支付报文传输系统，其特征在于，还包括：

HTTP请求接入模块，用于应用HTTP代理单元将对应的前置机接收的支付报文依次经城市处理中心和国家处理中心发送至对应的支付系统的网上支付跨行清算系统。

3.根据权利要求1或2所述的支付报文传输系统，其特征在于，还包括：

混合传输模块，用于将对应的前置机接收的支付报文以MQ消息队列传输及Kafka分布式消息队列传输的方式依次经城市处理中心和国家处理中心发送至对应的支付系统的网上支付跨行清算系统，并在该支付报文以Kafka分布式消息队列传输的方式进行传输的过程中，向所述zookeeper集群实时发送目的节点。

4.根据权利要求1所述的支付报文传输系统，其特征在于，所述MQ传输模块包括：与所述前置机对应的第一MQ单元、与所述城市处理中心对应的第二MQ单元、与所述国家处理中心对应的第三MQ单元，以及，与所述支付系统的网上支付跨行清算系统对应的第四MQ单元；

所述第一MQ单元、第二MQ单元、第三MQ单元和第四MQ单元之间依次通信连接。

5.根据权利要求1所述的支付报文传输系统，其特征在于，所述Kafka传输模块包括：

与所述前置机对应的第一Kafka单元、与所述城市处理中心对应的第二Kafka单元、与所述国家处理中心对应的第三Kafka单元，以及，与所述支付系统的网上支付跨行清算系统对应的第四Kafka单元；

所述第一Kafka单元、第二Kafka单元、第三Kafka单元和第四Kafka单元之间依次通信连接，且所述第一Kafka单元、第二Kafka单元、第三Kafka单元和第四Kafka单元分别与所述zookeeper集群通信连接。

6.根据权利要求2所述的支付报文传输系统，其特征在于，所述HTTP请求接入模块包括：

与所述前置机对应的第一HTTP代理单元、与所述城市处理中心对应的第二HTTP代理单元、与所述国家处理中心对应的第三HTTP代理单元，以及，与所述支付系统的网上支付跨行清算系统对应的第四HTTP代理单元；

所述第一HTTP代理单元、第二HTTP代理单元、第三HTTP代理单元和第四HTTP代理单元之间依次通信连接。

7.根据权利要求3所述的支付报文传输系统，其特征在于，所述混合传输模块包括：

与所述前置机对应的第五MQ单元、与所述城市处理中心对应的第五Kafka单元、与所述国家处理中心对应的第六Kafka单元，以及，与所述支付系统的网上支付跨行清算系统对应的第六MQ单元；

所述第五MQ单元、第五Kafka单元、第六Kafka单元和第六MQ单元之间依次通信连接，且所述第五Kafka单元和第六Kafka单元分别与所述zookeeper集群通信连接。

8.一种支付报文传输方法，其特征在于，该支付报文传输方法应用权利要求1至7任一项所述的支付报文传输系统实现，所述支付报文传输方法包括：

所述前置机接收支付报文，并根据zookeeper集群查询各个所述城市处理中心的负载均衡情况以及各个所述城市处理中心与国家处理中心的连接情况，并选取一个所述城市处理中心作为所述支付报文当前的投递目的地，将包含有该城市处理中心的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后、将所述支付报文传输至所述Kafka传输模块中对应的所述城市处理中心对应的第二Kafka单元中；

所述城市处理中心自所述第二Kafka单元获取所述支付报文，并确定一国家处理中心作为所述支付报文当前的投递目的地，将包含有该国家处理中心的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后将所述支付报文传输至对应的所述国家处理中心对应的第三Kafka单元中；

所述国家处理中心自所述第三Kafka单元获取所述支付报文，并确定一支付系统的网上支付跨行清算系统作为所述支付报文当前的投递目的地，将包含有该支付系统的网上支付跨行清算系统的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后将所述支付报文传输至对应的所述支付系统的网上支付跨行清算系统对应的第四Kafka单元中；

所述支付系统的网上支付跨行清算系统自所述第四Kafka单元获取所述支付报文，并检查该支付报文的合法性并对该支付报文进行对应处理，并将包含有该支付报文对应处理结果的报文接收信息发送至所述zookeeper集群。

9.根据权利要求8所述的支付报文传输方法，其特征在于，所述前置机接收支付报文，并根据zookeeper集群查询各个所述城市处理中心的负载均衡情况以及各个所述城市处理中心与国家处理中心的连接情况，并选取一个所述城市处理中心作为所述支付报文当前的投递目的地，将包含有该城市处理中心的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后、将所述支付报文传输至所述Kafka传输模块中对应的所述城市处理中心对应的第二Kafka单元中，包括：

所述前置机接收预设参与机构发送的支付报文，并根据本地配置文件确定能够投递该支付报文的多个城市处理中心；

所述前置机根据所述zookeeper集群查询各个所述城市处理中心的负载均衡情况以及各个所述城市处理中心与国家处理中心的连接情况，进而得到三级链路的可用情况；

所述前置机根据第一预设规则以及所述三级链路的可用情况，选取一个所述城市处理中心作为所述支付报文当前的投递目的地，并将包含有该城市处理中心的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后应用其对应的第一Kafka单元将所述支付报文传输至对应的所述城市处理中心对应的第二Kafka单元中。

10.根据权利要求9所述的支付报文传输方法，其特征在于，所述第一预设规则包括：

若当前的所述城市处理中心和国家处理中心无法进行通信，则放弃投递该城市处理中心，并继续判断下一个所述城市处理中心是否可以与国家处理中心通信，直到确定能够与所述国家处理中心通信的一个城市处理中心作为所述支付报文当前的投递目的地；

在能够投递该支付报文的多个城市处理中心中选取负载小于预设负载值的城市处理中心作为所述支付报文当前的投递目的地；

根据负载均衡算法选取所述支付报文的投递方式。

11.根据权利要求8所述的支付报文传输方法，其特征在于，所述城市处理中心自所述第二Kafka单元获取所述支付报文，并确定一国家处理中心作为所述支付报文当前的投递目的地，将包含有该国家处理中心的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后将所述支付报文传输至对应的所述国家处理中心对应的第三Kafka单元中，包括：

所述城市处理中心自所述第二Kafka单元获取所述支付报文，并检查该支付报文的合法性并对该支付报文进行对应的添加操作；

所述城市处理中心读取所述支付报文对应的配置信息，并根据该配置信息及第二预设规则，确定一国家处理中心作为所述支付报文当前的投递目的地，将包含有该国家处理中心的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后应用所述第二Kafka单元将所述支付报文传输至对应的所述国家处理中心对应的第三Kafka单元中。

12.根据权利要求11所述的支付报文传输方法，其特征在于，所述第二预设规则包括：

根据所述配置信息获取第一投递列表，该第一投递列表用于存储所述支付报文与所述国家处理中心之间的对应关系，并获取所述支付系统的网上支付跨行清算系统和国家处理中心的连接情况，筛选得到与所述支付系统的网上支付跨行清算系统连接正常的国家处理中心；

在能够投递该支付报文的国家处理中心中选取负载小于预设负载值的国家处理中心作为所述支付报文当前的投递目的地；

根据负载均衡算法选取所述支付报文的投递方式。

13.根据权利要求8所述的支付报文传输方法，其特征在于，所述国家处理中心自所述第三Kafka单元获取所述支付报文，并确定一支付系统的网上支付跨行清算系统作为所述支付报文当前的投递目的地，将包含有该支付系统的网上支付跨行清算系统的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后将所述支付报文传输至对应的所述支付系统的网上支付跨行清算系统对应的第四Kafka单元中，包括：

所述国家处理中心自所述第三Kafka单元获取所述支付报文，并检查该支付报文的合法性并对该支付报文进行对应的添加操作；

所述国家处理中心读取所述支付报文对应的配置信息，并根据该配置信息及第三预设规则确定所述支付系统的网上支付跨行清算系统作为所述支付报文当前的投递目的地，将包含有该支付系统的网上支付跨行清算系统的所述支付报文的投递目的地信息发送至所述zookeeper集群，而后应用所述第三Kafka单元将所述支付报文传输至对应的所述支付系统的网上支付跨行清算系统对应的第四Kafka单元中。

14.根据权利要求13所述的支付报文传输方法，其特征在于，所述第三预设规则包括：

根据所述配置信息获取第二投递列表，该第二投递列表用于存储所述支付报文与所述支付系统的网上支付跨行清算系统之间的对应关系，并筛选得到当前与所述国家处理中心连接正常的所述支付系统的网上支付跨行清算系统；

根据负载均衡算法选取所述支付报文的投递方式。