一种多区域中心银行间汇划路由调度的方法及系统与流程

1.本发明涉及调度方法，具体是一种多区域中心银行间汇划路由调度的方法及系统。


背景技术：

2.境内及其跨境电子支付作为信用货币流通中的一个重要环节，在现代经济中占据越来越重要的地位。在现有的跨行实时汇划的技术体系中，处理中心，合作行与结算行之间普遍采用消息队列异步解耦（比如mq）及消息传输路由（比如各种esb产品）的方式进行通讯，但是该方式存在着以下的一些问题：1.消息中间件复杂度高，部署及运维成本较高。
3.2.如果采用商用消息队列及esb产品，不仅成本高，由于部分产品需要特有的开发语言，开发及维护成本也较高。如果采用开源的相关产品，集群性能较弱且稳定性不高。
4.3.解耦的各系统间无法保证强一致性。对延迟不敏感。


技术实现要素：

5.本发明的目的在于提供一种多区域中心银行间汇划路由调度的方法及系统，以解决上述背景技术中提出的问题。
6.为实现上述目的，本发明提供如下技术方案：一种多区域中心银行间汇划路由调度的方法，包括如下步骤：（1）对每一个合作行或结算行在所属区域中心部署一套报文处理节点；（2）每个区域中心部署一套核心处理节点和一个路由处理节点；（3）每个区域中心部署一个注册中心，该区域的各节点将自己注册到该区域中心的注册中心，并对其他区域中心的节点可见；（4）每个区域中心的核心处理节点只处理该区域中心内各节点银行的业务；（5）每个区域中心的路由处理节点对接各个区域中心，并将业务处理分发给本区域中心或其他区域中心的各个节点。
7.作为本发明再进一步的优选方案，每个区域中心的注册中心通过zookeeper分布式集群实现。
8.作为本发明再进一步的优选方案，所述区域中心的注册中心之间通过多个zookeeper集群间的通讯实现。
9.作为本发明再进一步的优选方案，所述路由节点根据消息报文的请求，转发服务请求给其他报文处理节点或核心处理节点。
10.作为本发明再进一步的优选方案，所述各个节点服务基于hessian协议实现。
11.进一步的，本发明在上述方法的基础上，提供一种多区域中心银行间汇划路由调度系统，包括核心处理节点、报文处理节点、路由处理节点和注册中心，所述报文处理节点部署于每一个合作行或结算行在所属区域中心，所述核心处理节点、路由处理节点和注册中心部署于每个区域中心，该区域的核心处理节点、报文处理节点、路由处理节点将自己注册到该区域中心的注册中心，并对其他区域中心的节点可见，每个区域中心的核心处理节
点只处理该区域中心内各节点银行的业务，每个区域中心的路由处理节点对接各个区域中心，并将业务处理分发给本区域中心或其他区域中心的各个节点。
12.与现有技术相比，本发明的有益效果是：本发明核心处理节点、合作行与结算行之间的通讯采用异步解耦的方式，部分功能实现强一致性，并对延迟敏感，满足多区域间通讯以及高并发场景下的系统稳定性，确保消息的安全型，支持消息的追溯。
附图说明
13.图1为本发明系统原理图图2为本发明节点服务注册原理图图3为本发明单区域节点服务调用原理图。
14.图4为本发明跨区域节点服务调用原理图。
15.图5为本发明中路由服务的请求消息的原理示意图。
16.图6为本发明中路由服务的响应消息的原理示意图。
具体实施方式
17.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
18.请参阅图1，本发明实施例中一种多区域中心银行间汇划路由调度的方法，包括如下步骤：（1）对每一个合作行或结算行在所属区域中心部署一套报文处理节点；（2）每个区域中心部署一套核心处理节点和一个路由处理节点；（3）每个区域中心部署一个注册中心，该区域的各节点将自己注册到该区域中心的注册中心，并对其他区域中心的节点可见；（4）每个区域中心的核心处理节点只处理该区域中心内各节点银行的业务；（5）每个区域中心的路由处理节点对接各个区域中心，并将业务处理分发给本区域中心或其他区域中心的各个节点。
19.如图1所示，每个区域中心内的各个处理功能模块都作为单个节点存在，在启动时自动注册到该区域中心的注册中心，并广播给其他区域中心。每个区域中心的注册中心通过zookeeper分布式集群实现，保证该系统的可靠性和稳定性。多个区域中心的注册中心通过多个zookeeper集群间的通讯实现。路由节点根据消息报文的请求，转发服务请求给其他报文处理节点或核心处理节点。各节点服务基于hessian协议实现。
20.进一步的，本发明在上述方法的基础上，提供一种多区域中心银行间汇划路由调度系统，包括核心处理节点、报文处理节点、路由处理节点和注册中心，所述报文处理节点部署于每一个合作行或结算行在所属区域中心，所述核心处理节点、路由处理节点和注册中心部署于每个区域中心，该区域的核心处理节点、报文处理节点、路由处理节点将自己注册到该区域中心的注册中心，并对其他区域中心的节点可见，每个区域中心的核心处理节点只处理该区域中心内各节点银行的业务，每个区域中心的路由处理节点对接各个区域中心，并将业务处理分发给本区域中心或其他区域中心的各个节点。
21.下面通过具体的实施流程并结合附图对本发明作进一步详细的描述。
22.流程一：节点服务注册。如图2所示，各个节点服务在节点启动时自动注册到该区域中心的注册中心，并广播给其他区域中心的注册中心。
23.流程二：单区域节点服务调用。图3以单个区域中心内银行b01实时汇划资金给银行b02为例。
24.b01报文处理节点从注册中心订阅服务注册情况，调用该区域中心的路由节点。路由服务节点根据报文内容和路由规则调用核心处理节点的服务，同时调用b02报文处理节点的服务，通过b02报文处理节点调用银行接口。
25.流程三：跨区域节点服务调用。图4以不同区域中心内银行b01实时汇划资金给银行b03为例。
26.b01报文处理节点从注册中心订阅服务注册情况，调用该区域中心a001的路由节点01。路由服务根据报文内容和路由规则调用核心处理节点的服务，同时调用区域中心a002的路由节点02，路由节点02根据路由规则调用本区域中心的核心处理节点的服务，同时调用b03报文处理节点的服务，通过b03调用银行接口。
27.流程四：路由服务。
28.路由服务是整个路由调度算法系统中的核心，它根据报文消息，确定调度路由，分别调用注册的节点服务。图5分别以请求消息和响应消息为例进行说明。
29.4.1 服务请求：4.1.1 servce.request.in是请求消息流的起点，要求消息体必须能为xmlns：for xml messages (namespace aware)解析，在此判断消息体为xml报文。解析成功则进入log.enter.trace节点，解析失败则进入error.trace节点。
30.4.1.2 sign.certification通过公钥进行签名验证，验证失败则进入error.trace节点。
31.4.1.3 xml.validation判断报文头信息和报文体信息同时存在时，进入报文编码判断，报文编码必须为1208，判断失败则进入error.trace节点；判断成功进入下一节点msg.init节点。
32.4.1.4 msg.init重置报文体中的消息超时标识。设定成功则进入下一节点increase.seq节点，失败则回退到xml.validation节点，并且错误被捕捉，进入error.trace节点。
33.4.1.5 increase.seq解析报文头，获取报文头中的pass_seq（经过处理的序号）属性值，对此值+1处理，处理成功进入preparedata节点，如果失败，错误被捕捉，进入error.trace节点。
34.4.1.6 prepare.data通过共享缓存获取loglevel的值；通过共享缓存获取resoutexpiry的值，设置报文头中的超时时间；通过共享缓存获取msgloginterval的值，设置报文头中的间隔时间。处理成功进入is.trunk.service节点，处理失败，错误被捕捉，进入error.trace节点。
35.4.1.7 is.trunk.service判断是否为主干路由，通过报文头中的to_mh_id字段与从缓存配置文件中获取的获取的mh_id字段是否匹配。确定路由路径，从注册中心获取对应节点服务。
36.4.1.8 trank.service.router.out调用对应节点服务。
37.4.1.9 service.core调用核心处理节点的服务4.1.10 requset.out.service请求消息的结束处理。
38.4.1.11 log.entry.trace记录开始日志4.1.12 error.trace记录错误日志4.1.13 log.success.trace记录成功日志4.1.14 log.end.trace记录结束日志4.1.15 msg.record记录整个报文内容，并记录当前操作（参阅图6）。
39.4.2 服务响应：4.2.1 service.response.in是响应消息流的起点，要求消息体必须能为xmlns : for xml messages (namespace aware)解析，在此判断消息体为xml报文。解析成功则进入log.enter.trace节点，解析失败则进入error.trace节点。
40.4.2.2 xml.validation判断报文头信息和报文体信息同时存在时，进入报文编码判断，报文编码必须为1208，判断失败则进入error.trace节点；判断成功进入下一节点msg.init节点。
41.4.2.3 is.trunk.service判断是否为主干路由，通过报文头中的to_mh_id字段与从缓存配置文件中获取的获取的mh_id字段是否匹配。确定路由路径，从注册中心获取对应节点服务。
42.4.2.4 sign.certification根据对应节点对响应报文进行加签操作。
43.4.2.5 trunk.service.router.out调用对应节点服务。
44.4.2.6 response.out.service响应消息的结束服务。
45.4.2.7 log.entry.trace记录开始日志4.2.8 error.trace记录错误日志4.2.9 log.success.trace记录成功日志
4.2.10 log.end.trace记录结束日志4.2.11 msg.record记录整个报文内容，并记录当前操作。
46.综上所述，本发明核心处理节点、合作行与结算行之间的通讯采用异步解耦的方式，部分功能实现强一致性，并对延迟敏感，满足多区域间通讯以及高并发场景下的系统稳定性，确保消息的安全型，支持消息的追溯。
47.对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。
48.此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。