CN117041321A - 一种业务处理系统和方法 - Google Patents

Abstract

本公开提供了一种业务处理系统和方法，应用于计算机领域，系统包括：客户端、网关集群、交换中心和业务中心；网关集群包括：Http网关集群、Websocket网关集群；交换中心与业务中心建立有通信关系；Http网关集群包括一个或多个Http网关；Websocket网关集群包括一个或多个Websocket网关；Http网关集群中的每个Http网关用于接收客户端的第一消息，将接收的第一消息发送到交换中心；Websocket网关集群中的每个Websocket网关用于接收交换中心发送的第二消息，将接收的第二消息发送给第二消息对应的客户端。通过多种网关实现多个通信链路，进而提高系统的通信效率。

Description

一种业务处理系统和方法

技术领域

本公开涉及计算机技术领域，尤其涉及一种业务处理系统和方法。

背景技术

现有技术中，业务处理系统一般服务多个客户端，随着客户端的增多、业务类型的增多，业务处理的响应效率、系统稳定性等均会受到影响，进而影响整个业务处理系统的服务性能。如何适应高速发展的业务，提高服务性能是需要解决的问题。

发明内容

本公开提供了一种业务处理系统和方法，以至少解决现有技术中存在的以上技术问题。

第一方面，本公开实施例提供了一种业务处理系统，所述系统包括：客户端、网关集群、交换中心和业务中心；所述网关集群，包括：Http（Hypertext transfer protocol，超文本传输协议）网关集群、Websocket网关集群；所述交换中心与所述业务中心建立有通信关系；

所述Http网关集群包括一个或多个Http网关；所述Websocket网关集群包括一个或多个Websocket网关；所述客户端的数量为一个或多个；

所述Http网关集群中的每个Http网关，用于接收客户端的第一消息，将接收的第一消息发送到交换中心；

所述Websocket网关集群中的每个Websocket网关，用于接收所述交换中心发送的第二消息，将接收的第二消息发送给所述第二消息对应的客户端；

所述业务中心，用于向所述交换中心发送第三消息，以请求所述交换中心进行业务处理；

所述交换中心，用于执行以下至少之一：

接收客户端发送的第一消息，根据所述第一消息进行业务处理；

向客户端发送第二消息；

接收业务中心发送的第三消息，根据所述第三消息进行业务处理。

第二方面，本公开实施例提供了一种业务处理方法，所述方法应用于以上所述的业务处理系统；所述方法包括：

Http网关集群中的每个Http网关接收客户端的第一消息，将接收的第一消息发送到交换中心；

Websocket网关集群中的每个Websocket网关接收所述交换中心发送的第二消息，将接收的第二消息发送给所述第二消息对应的客户端；

业务中心向所述交换中心发送第三消息，以请求所述交换中心进行业务处理；

所述方法还包括以下至少之一：

所述交换中心接收客户端发送的第一消息，根据所述第一消息进行业务处理；

所述交换中心向客户端发送第二消息；

所述交换中心接收业务中心发送的第三消息，根据所述第三消息进行业务处理。

本公开实施例提供的业务处理系统和方法，系统包括：客户端、网关集群、交换中心和业务中心；所述网关集群，包括：Http网关集群、Websocket网关集群；所述交换中心与所述业务中心建立有通信关系；

所述Http网关集群包括一个或多个Http网关；所述Websocket网关集群包括一个或多个Websocket网关；所述客户端的数量为一个或多个；

所述Http网关集群中的每个Http网关，用于接收客户端的第一消息，将接收的第一消息发送到交换中心；

所述Websocket网关集群中的每个Websocket网关，用于接收所述交换中心发送的第二消息，将接收的第二消息发送给所述第二消息对应的客户端；

所述业务中心，用于向所述交换中心发送第三消息，以请求所述交换中心进行业务处理；

所述交换中心，用于执行以下至少之一：

接收客户端发送的第一消息，根据所述第一消息进行业务处理；

向客户端发送第二消息；

接收业务中心发送的第三消息，根据所述第三消息进行业务处理。

如此，通过多种网关，对于不同的业务，客户端和服务端可以采用不同的通信链路进行传输，降低了单一网关（如Http网关）的通信压力；通过Websocket网关实现了交换中心主动向客户端发送消息的功能，对于某些业务结果（如查询结果、通知消息），可以及时的发送到客户端，且不影响增加Http网关的压力。并且，通过Websocket技术，实现了请求由同步到异步的转变，这一转变彻底解决了客户端开放端口时被攻击的问题。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

图1为本公开实施例提供的一种业务处理系统的结构示意图；

图2为本公开实施例提供的一种客户端的业务处理方法的流程示意图；

图3为本公开实施例提供的客户端的结构示意图；

图4为本公开应用实施例提供的一种业务处理方法的流程示意图；

图5为本公开应用实施例提供的一种业务处理系统的结构示意图；

图6为本公开实施例提供的一种业务处理方法的流程示意图。

具体实施方式

为使本公开的目的、特征、优点能够更加的明显和易懂，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而非全部实施例。基于本公开中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解,“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

在以下的描述中，所涉及的术语“第一\第二”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本公开实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本公开所使用的所有的技术和科学术语与属于本公开的技术领域的技术人员通常理解的含义相同。本公开中所使用的术语只是为了描述本公开实施例的目的，不是旨在限制本公开。

应理解，在本公开的各种实施例中，各实施过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本公开实施例的实施过程构成任何限定。

图1为本公开实施例提供的一种业务处理系统的结构示意图；如图1所示，所述系统包括：客户端、网关集群、交换中心和业务中心；其中，

所述网关集群，包括：Http（Hypertext transfer protocol，超文本传输协议）网关集群、Websocket网关集群；

所述Http网关集群包括一个或多个Http网关；

所述Websocket网关集群包括一个或多个Websocket网关；

所述交换中心与所述业务中心建立有通信关系；

所述客户端的数量为一个或多个；

所述Http网关集群中的每个Http网关，用于接收客户端的第一消息，将接收的第一消息发送到交换中心；

所述Websocket网关集群中的每个Websocket网关，用于接收所述交换中心发送的第二消息，将接收的第二消息发送给所述第二消息对应的客户端；

所述业务中心，用于向所述交换中心发送第三消息，以请求所述交换中心进行业务处理；

所述交换中心，用于执行以下至少之一：

接收客户端发送的第一消息，根据所述第一消息进行业务处理；

向客户端发送第二消息；

接收业务中心发送的第三消息，根据所述第三消息进行业务处理。

其中，每个Http网关可以连接至少一个客户端，实现所连接的至少一个客户端中每个客户端与业务中心的通信；可以理解的是，每个Http网关接收的客户端的第一消息，是该Http网关连接的客户端发送的第一消息。

每个Websocket网关可以连接至少一个客户端，实现所连接的至少一个客户端中每个客户端与业务中心的通信；可以理解的是，每个Websocket网关发送的第二消息，是向该Websocket网关连接的客户端发送第二消息。

其中，所述客户端为多目标交换服务客户端；每个客户端可以连接一个或多个前置机。

在一些实施例中，针对不同业务，所述第一消息可以是不同的，例如，所述第一消息可以包括：业务请求消息等。客户端发送给交换中的第一消息可以是一种基于Https（Hypertext Transfer Protocol Secure，超文本传输安全协议）协议的消息。

在一些实施例中，所述系统还包括：网络附属存储（NAS，Network AttachedStorage）设备；所述网关集群还包括：文件网关；

所述文件网关，用于接收客户端发送的文件上传消息，将所述文件上传消息发送给NAS设备进行存储；

所述NAS设备，用于接收并存储所述文件上传消息；

其中，所述文件上传消息可以携带：客户端所需上传并保存的任意文件；例如，客户端更新后的报告文件等。

所述文件上传消息可以是一种基于Https协议的消息；相应的，所述文件网关也可以是一种Http网关，用于实现文件传输、文件请求等。

在一些实施例中，所述第一消息可以为业务请求消息；

所述交换中心包括：交换服务器集群、Websocket服务集群；

所述客户端，用于通过Http网关向交换服务器集群发送业务请求消息；所述业务请求消息为一种Https请求，携带原始报文或客户端解析得到的报文；

所述交换服务器集群中的交换服务器，用于根据业务请求消息调用业务中心的接口，得到业务处理结果；

通过Websocket服务集群和Websocket网关将业务处理结果发送给客户端。

这里，所述客户端通过Http网关向交换服务器集群发送业务请求消息，可以理解为，客户端发送业务请求消息给Http网关，Http网关转发给交换服务器集群。

本公开实施例中，集群就是指将很多设备集中起来一起进行同一种服务，例如，交换服务器集群中由多个交换服务器集中起来，当某一台交换服务器出现故障，另一台交换服务器可以保证服务的稳定性。每台交换服务器可以由一个服务器、电子设备或智能设备等实现。

在一些实施例中，所述交换中心还包括：交换服务管理设备；

所述客户端，还用于向文件网关发送文件请求消息；

所述文件网关，还用于接收所述文件请求消息，向所述交换中心的交换服务管理设备发送所述文件请求消息；所述文件请求消息用于请求获取客户端更新相关文件；

所述交换服务管理设备，用于根据所述文件请求消息向所述文件网关发送响应消息；所述响应消息携带所述客户端更新相关文件；

所述文件网关，还用于将所述响应消息发送给客户端；

所述客户端，还用于接收所述响应消息并下载所述客户端更新相关文件，对所述客户端更新相关文件进行本地解压，根据解压得到的文件进行更新。

本公开实施例中，Websocket网关、Websocket服务集群采用Websocket协议或WSS协议（一种加密版本的Websocket协议），Websocket协议是一种在单个TCP连接上进行全双工通信的协议。Websocket协议允许服务端（如交换中心）主动向客户端推送数据。实际应用时，客户端和服务端完成一次握手，两者之间就直接可以建立持久性的连接关系。客户端与服务端建立连接关系后，可以通过这个连接互发消息，服务端可以向客户端发送各类通知及查询结果报文，客户端主要可以上送心跳信息。

Http网关采用Https协议，Https协议是每进行一次报文收发交易时才进行通讯连接，交易完毕后立即断开；例如，客户端可以通过Http网关向服务端发送Https请求，以进行交易，两者经过一些交互完成交易后，连接关系可以断开。

所述Http网关具有对Https请求的加解密、令牌（token）有效性的校验等功能，客户端通过指定的软件开发工具包（SDK，Software Development Kit）插件（集成在客户端内）对与服务端交互的Https请求或报文进行加解密操作。

本公开实施例中，通过Websocket服务集群、Websocket网关等Websocket技术，实现了请求由同步到异步的转变，这一转变彻底解决了客户端开放端口时被攻击的问题，具体来说，相关技术中大多是从业务中心收到业务请求开始一直到发往客户端连接的前置机，整个链路都是同步发送的，少量异步的方式也是在服务端轮询再直发到前置机，以上两种方式都要求客户端向服务端开放端口进行访问；而本公开实施例中，将链路拆成了三部分，业务中心与服务中心通信、客户端通过Http网关主动访问服务端、结合Websocket技术（即Websocket服务集群、Websocket网关）服务端可以向客户端主动发送消息，如此，客户端不开放端口也可实现与服务中心、业务中心的交互，避免了客户端开放端口时被攻击的风险，同时也避免了轮询对服务端的压力，提升了交易处理的时效性。

本公开实施例的系统具体提供三种网关，包括：Websocket网关、Http网关、文件网关，对于不同的业务，客户端和服务端可以采用不同的网关进行传输，降低了单一网关（如Http网关）的通信压力，且通过Websocket网关实现了服务端主动向客户端发送消息的功能，对于某些业务结果（如查询结果、通知消息），可以及时的发送到客户端，且不影响增加Http网关的压力。而对于一些花费时间相对较久的文件传输，可以采用文本网关，进行文件传输，以避免对其它业务产生影响。

在一些实施例中，所述交换中心还包括：远程字典服务（Redis，RemoteDictionary Server）集群、数据库；

所述Redis集群，用于存储业务处理过程中所需保存的信息，所需保存的信息，包括：Https请求的token信息、客户端建立的Websocket连接信息、各种预设的报文模板、第二消息携带的报文等；

例如，所述报文模板可以包括：余额模板、明细模板等，考虑到某些业务信息的呈现一般只修改日期和金额数组，因此，预先设计报文模板并保存，还可以预先发送给客户端缓存，根据日期和金额数组修改报文模板，将修改得到的报文发送给前置机，提高业务处理效率。

通过Redis集群可以保存Https请求的token信息、保存客户端建立的Websocket连接信息，对于实时查询请求结果回调时进行广播等。

所述交换服务管理设备是内管应用，用于负责客户端的相关配置、更新、插件或底座版本管理、定时任务管理等；所述交换服务管理设备，用于通过Websocket服务集群和Websocket网关向客户端发送通知消息，例如，通知客户端进行版本更新的消息，通知客户端获取任务相关报文的消息等。

所述数据库，用于存储业务处理过程中所需使用的文件和所需保存的文件。这里，所述数据库采用ORACLE数据库。

在一些实施例中，所述Websocket服务集群包括：一个或多个Websocket服务器。

所述Websocket网关集群中的每个Websocket网关，用于从注册中心读取Websocket服务信息列表，根据所述Websocket服务信息列表在Websocket网关内存中创建哈希（Hash）环，并针对每个所述Websocket服务器插入一个或多个虚拟节点；

每个所述虚拟节点对应所述哈希环中的一个哈希值；每个所述Websocket服务器插入的虚拟节点的数量基于所述Websocket服务器的性能和/或存储空间的特征确定。

所述客户端，还用于向Websocket网关发送Websocket连接请求；

所述Websocket网关，还用于根据所述Websocket连接请求和保存的哈希环，从所述Websocket服务集群中确定目标Websocket服务器，将Websocket连接请求转发到目标Websocket服务器，以使所述客户端与所述目标Websocket服务器建立连接。

具体地，Websocket是基于传输控制协议（TCP，Transmission ControlProtocol），也就是说与哪个节点建立的连接则由连接的节点推送消息，例如，针对业务中心向某个客户端发送的Websocket请求，需确定出该客户端建立Websocket会话的Websocket服务节点。

举例来说，Websocket网关集群包括：多个Websocket网关；所述Websocket网关集群可以包括：4台Websocket服务器；采用erueka作为注册中心。

Websocket网关在服务启动时，从eureka中读取Websocket服务信息列表，根据Websocket服务信息列表在Websocket网关内存中创建哈希环，并针对每个Websocket服务器插入一个或多个虚拟节点。这里，插入虚拟节点的目的是为了解决数据倾斜问题，使在Websocket服务器较少时也能保持相对均匀的数据分布。每个Websocket服务器插入的虚拟节点的数量可以基于该Websocket服务器的性能、存储空间等确定，所述Websocket服务器的性能、存储空间等特征与所述虚拟节点的数量为正比例关系，即性能越高、存储空间越多，可以构建的虚拟节点的数量也相对更多。每个虚拟节点对应的一个哈希值。

所述Websocket网关，通过轮询方式从eureka读取Websocket服务信息列表，如果Websocket服务信息列表发生变化，则修改哈希环得到新的哈希环并修改虚拟节点。通过比对新的哈希环和旧哈希环，确定出不符合新的哈希环一致性的Websocket连接，通知Websocket服务器主动断开对应客户端的Websocket连接关系，让这一部分客户端重新建立Websocket连接。

在一些实施例中，所述Websocket网关，用于接收第二消息，根据所述第二消息携带的客户端的标识和哈希环，确定所述客户端对应的Websocket服务器；将所述第二消息转发到所述客户端对应的Websocket服务器；

所述客户端对应的Websocket服务器，用于将所述第二消息发送给客户端。

具体地，所述第二消息为Websocket消息或Websocket请求消息；Websocket网关采用分布式微服务架构网关（spring cloud gateway）实现，预先设有Websocket网关负载均衡策略，通过Websocket网关负载均衡策略将Websocket消息转发到指定的Websocket服务集群上。

Websocket网关默认集成了Ribbon（一种基于Http和TCP的客户端的负载均衡工具）用于负载均衡，根据建立连接时Websocket连接请求携带的客户端发来的客户端标识（customer Id）信息，重写Ribbon负载均衡算法。应用时，根据customer Id进行哈希，并在哈希环上寻找建立连接的Websocket服务器的IP，并将Websocket消息转发到该IP对应的Websocket服务器。

在一些实施例中，所述NAS设备，还用于保存客户端的底座和/或客户端的插件。

在一些实施例中，所述客户端，用于在接收到多个交易请求消息时，根据所述多个交易请求消息中每个交易请求消息对应的业务类型的优先级，依次处理每个交易请求消息；

所述客户端连接一个或多个前置机，所述客户端还用于针对不同前置机设置不同的并发数。

具体地，客户端在接收到交易请求消息（如转账请求、查询请求）后，将交易请求消息保存到线程池的队列中，线程池根据交易请求消息的优先级进行处理，处理的时候会按照优先级出队列。

如此，通过线程池的队列实现优先级排列，实现了交易优先级的可配置化，优化了交易处理机制，解决了定时任务阻塞正常交易发送的问题，提升了交易成功率。

在一些实施例中，所述客户端可以连接一个或多个前置机；所述客户端还用于针对不同银行的前置机设置不同的并发数；

具体地，可以根据实际情况对并发数进行调试、配置，通过设置不同的并发数的大小提升整个交易的稳定性。

图2为本公开实施例提供的一种客户端的业务处理方法的流程示意图；如图2所示，客户端拉取到转账报文或收到Websocket服务器发送的查询报文后，根据银行编号获取对应优先任务队列交易线程池（简称线程池），通过线程池按照各任务的优先级进行处理。

针对每个银行的前置机可以分别构建一个线程池；针对每个银行的前置机还可以分别配置并发数，如m、n、k。

所述客户端包括：不变的主体（即底座）和可变的插件两部分；通过服务端的后台管理（如交换服务管理设备）进行插件下发实现远程更新，替代了原有的上门更新的维护方式。

如图3所示，客户端包括：主体模块，该主体模块包括：插件管理模块、启动模块、客户端配置模块；

客户端还包括多个插件，具体包括：

多个处理插件（如银行对应所需的插件：工行插件、农行插件、中行插件、建行插件、招行插件）；

通讯路由插件；

定时任务插件；

SDK插件。

其中，通讯路由插件，用于通过各种网关接收或发送各种消息，对于接收的消息确定对应的处理插件，即确定采用哪个银行的处理插件；

各个处理插件，用于处理相应银行相关的报文，如加密报文、解密报文等，并发送到前置机。

SDK插件用于进行与Http网关对应的加解密操作，以保障报文安全。

针对客户端的各种插件，采用插件热更新机制，通过PF4J（Plugin Framework forJava，Java插件框架）实现插件管理，如此，打破了客户端必须是一个包的固有思路，为客户端版本管理提供了新的有效实践。

本公开实施例的系统，采用Websocket技术，实现了异步交互方式，大大降低了由于网络或者前置机导致的交易失败发生频率。而插件热更新机制可以实现服务端后台直接进行远程一键更新，大大降低了运维成本。

综上，本公开实施例提供的系统，利用PF4J、Websocket、线程池等技术构造的业务处理系统，提高了业务处理的响应效率，且提高了系统安全性、稳定性。相较于相关技术中，为避免客户端口暴露在互联网中存在被攻击的风险，通过引入虚拟专用网络（VPN，VirtualPrivate Network）、专线等方式，无需额外的成本，具有成本低、维护方便、便于操作的优点。

在一些实施例中，多目标交换服务可以是多银行交换服务，用于实现多个银行之间的业务、数据等方面的交换服务。

图4为本公开实施例提供的一种业务处理方法的流程示意图；如图4所示，所述方法包括：

步骤1、客户端向Websocket网关发送Websocket连接请求；

其中，所述Websocket连接请求，用于请求与Websocket服务集群建立连接。

步骤2、Websocket网关根据发送Websocket连接请求时客户端发来的客户端标识（customer Id），采用预设的Ribbon负载均衡算法，根据customer Id进行哈希。

步骤3、Websocket网关在哈希环上寻找Websocket服务器的IP。

步骤4、将Websocket连接请求转发到该IP对应的Websocket服务器，客户端与Websocket服务集群建立连接。

具体地，客户端与IP对应的Websocket服务器建立连接，后续可由该Websocket服务器向建立连接关系的客户端发送消息。

步骤5、结算中心（仅为一种业务中心的示例）向交换服务器集群发送支付请求。

步骤6、交换服务器集群收到支付请求后进行必要的校验，然后将支付请求保存到数据库中，即交易入库。

步骤7、交换服务器集群向Websocket网关发送通知消息。

步骤8、交换服务器集群向结算中心发送转账响应。

步骤9、Websocket网关根据客户端标识查询哈希环。

步骤10、确定客户端连接的Websocket服务器的IP。

步骤11、通过客户端连接的Websocket服务器将通知消息发送给客户端，以要求客户端来拉取交易。

步骤12、客户端收到通知消息后向Http网关发起拉取交易请求，以获取支付信息。

步骤13、Http网关向交换服务器集群发送拉取交易明文请求。

步骤14、交换服务器集群将保存在数据库中的支付请求查询出来，并根据银行的前置机报文组织逻辑进行报文组装。

步骤15、交换服务器集群向Http网关发送拉取交易明文响应。

步骤16、Http网关向客户端发送拉取交易响应。

其中，拉取交易响应包括组装好的发往前置机的报文；客户端接收后对相应的报文进行发送处理，完成后还可以向Http网关发送处理结果；Http网关将处理结果发送到交换服务器集群和结算中心。

对于查询类的业务，可以分为两种：

第一种，客户端运行的定时任务，每天定期从服务端拉取（即发送一种Https请求）已维护账号所属银行的查询报文模板（服务端根据前置机接口规范组装的查询请求报文，查询日期用占位符代替，方便客户端复用）；

第二种，报表中心（仅一种业务中心的示例）页面发起的实时查询，报表中心向交换服务器集群发送查询请求，交换服务器集群利用Spring提供的DeferredResult类（一种用于处理请求的类）将请求挂起，同时将需要查询的账号进行报文组装，通过Websocket服务器发送到客户端，客户端发送给前置机获取结果后通过Https请求经过Http网关发送到交换服务器集群，交换服务器集群报文解析完成后再通过恢复被挂起的请求给报表中心发送响应内容，完成查询。

图5为本公开应用实施例提供的一种业务处理系统的结构示意图；如图5所示，所述业务处理系统用于多银行交互，但本公开实施例的业务处理系统不仅限于用在银行交互，所述业务处理系统包括：

各个企业使用的多银行交换客户端（如图5中的MBC），每个MBC可以连接一个或多个前置机（如图5中的银行A银企前置机、银行B银企前置机、银行C银企前置机等）；这里，所述MBC相当于上述客户端，可以实现上述客户端的各种功能；例如，发送文件上传消息以上传文件到NAS设备；发送版本更新消息以请求获取客户端更新相关文件。

网关系统（相当于上述网关集群），包括：Http网关集群、Websocket网关集群、文件网关；Http网关集群包括多个Http网关，各Http网关至少可以实现以上所述的各种功能，例如，接收并发送任务读取消息以请求获取待处理业务；接收并发送结果回调消息以告知业务处理结果；Websocket网关集群包括多个Websocket网关，各Websocket网关至少可以实现以上所述的各种功能，例如，接收并发送Websocket请求以实现与Websocket服务器建立连接；文件网关用于接收并发送文件上传消息、文件请求消息、客户端更新相关文件等；这里不再一一赘述。网关系统可以使用F5或Nginx负载均衡技术。

多银行交换中心，包括：多银行交换服务器（MBS）、Websocket服务、Redis集群、Oracle（仅一种数据库的示例）、MBS管理设备（仅一种交换服务管理设备的示例）；这里，多个MBS形成MBS集群，作为一种交换服务器集群的示例，MBS集群在银行交互过程中至少可以实现以上所述的交换服务器集群的各种功能。多个Websocket服务形成Websocket服务集群，可以由上述Websocket服务器和Websocket服务器上的虚拟节点实现。

业务中心，包括：财资金融服务系统、财资增值能力系统、财资基础业务能力系统等。

NAS设备，用于存储各种文件。

财资基础技术支撑系统，可以包括：erueka集群、阿波罗（apollo）集群等，用于实现业务处理系统的底层支撑系统，如实现服务注册并获取相关配置信息等。

图6为本公开实施例提供的一种业务处理方法的流程示意图；如图6所示，所述方法应用于业务处理系统，该系统如图1所示，这里不再赘述。所述业务处理方法，包括：

步骤601、Http网关集群中的每个Http网关接收客户端的第一消息，将接收的第一消息发送到交换中心；

步骤602、Websocket网关集群中的每个Websocket网关接收所述交换中心发送的第二消息，将接收的第二消息发送给所述第二消息对应的客户端；

步骤603、业务中心向所述交换中心发送第三消息，以请求所述交换中心进行业务处理；

所述方法还包括步骤604，所述步骤604包括以下至少之一：

所述交换中心接收客户端发送的第一消息，根据所述第一消息进行业务处理；

所述交换中心向客户端发送第二消息；

所述交换中心接收业务中心发送的第三消息，根据所述第三消息进行业务处理。

需要说明的是，以上步骤601、步骤602、步骤603、步骤604仅表示所述方法可以包括以上步骤，对于步骤的执行顺序不做限定。

其中，所述Http网关可以连接至少一个客户端，用于实现所连接的至少一个客户端中每个客户端与业务中心的通信；

所述Websocket网关可以连接至少一个客户端，用于实现所连接的至少一个客户端中每个客户端与业务中心的通信。

其中，所述客户端为多目标交换服务客户端；每个客户端可以连接一个或多个前置机。

在一些实施例中，所述方法还包括：

所述客户端向Websocket网关发送Websocket连接请求；

所述Websocket网关根据发送Websocket连接请求从所述websoket服务集群中确定目标Websocket服务器，将Websocket连接请求转发到目标Websocket服务器，以使所述客户端与websoket服务集群建立连接。

在一些实施例中，所述第二消息为Websocket消息；所述将接收的第二消息发送给所述第二消息对应的客户端，包括：

所述Websocket网关根据所述Websocket消息携带的客户端的标识和哈希环，确定所述客户端对应的Websocket服务器；

将所述Websocket消息转发到所述客户端对应的Websocket服务器，由所述客户端对应的Websocket服务器将所述Websocket消息发送给客户端。

需要说明的是，上述实施例提供的业务处理方法与业务处理系统的实施例属于同一构思，还可以执行系统所作的其它操作，其具体实现过程详见系统实施例，这里不再赘述。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或隐含地包括至少一个该特征。在本公开的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

以上所述，仅为本公开的具体实施方式，但本公开的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种业务处理系统，其特征在于，所述系统包括：客户端、网关集群、交换中心和业务中心；所述网关集群，包括：超文本传输协议Http网关集群、Websocket网关集群；所述交换中心与所述业务中心建立有通信关系；

所述Http网关集群包括一个或多个Http网关；所述Websocket网关集群包括一个或多个Websocket网关；所述客户端的数量为一个或多个；

所述Http网关集群中的每个Http网关，用于接收客户端的第一消息，将接收的第一消息发送到交换中心；

所述Websocket网关集群中的每个Websocket网关，用于接收所述交换中心发送的第二消息，将接收的第二消息发送给所述第二消息对应的客户端；

所述业务中心，用于向所述交换中心发送第三消息，以请求所述交换中心进行业务处理；

所述交换中心，用于执行以下至少之一：

接收客户端发送的第一消息，根据所述第一消息进行业务处理；

向客户端发送第二消息；

接收业务中心发送的第三消息，根据所述第三消息进行业务处理。

2.根据权利要求1所述的系统，其特征在于，所述系统还包括：网络附属存储NAS设备；所述网关集群还包括：文件网关；

所述文件网关，用于接收客户端发送的文件上传消息，将所述文件上传消息发送给NAS设备进行存储；

所述NAS设备，用于接收并存储所述文件上传消息。

3.根据权利要求1所述的系统，其特征在于，所述交换中心包括：交换服务器集群、Websocket服务集群；所述第一消息包括：业务请求消息；

所述客户端，用于通过Http网关向交换服务器集群发送业务请求消息；

所述交换服务器集群中的交换服务器，用于根据所述业务请求消息调用所述业务中心的接口，得到业务处理结果；

通过Websocket服务集群和Websocket网关将所述业务处理结果发送给客户端。

4.根据权利要求2所述的系统，其特征在于，所述交换中心还包括：Redis集群、交换服务管理设备、数据库；

所述Redis集群，用于存储业务处理过程中所需保存的信息，所需保存的信息至少包括：预设的报文模板；所述报文模板包括：余额模板、明细模板；

所述客户端，还用于向文件网关发送文件请求消息；

所述文件网关，还用于接收所述文件请求消息，向所述交换中心的交换服务管理设备发送所述文件请求消息；所述文件请求消息用于请求获取客户端更新相关文件；

所述交换服务管理设备，用于根据所述文件请求消息向所述文件网关发送响应消息；所述响应消息携带所述客户端更新相关文件；

所述文件网关，还用于将所述响应消息发送给客户端；

所述客户端，还用于接收所述响应消息并下载所述客户端更新相关文件，对所述客户端更新相关文件进行本地解压，根据解压得到的文件进行更新。

5.根据权利要求1所述的系统，其特征在于，所述客户端，用于在接收到多个交易请求消息时，根据所述多个交易请求消息中每个交易请求消息对应的业务类型的优先级，依次处理每个交易请求消息；

所述客户端连接一个或多个前置机；所述客户端，还用于针对不同前置机设置不同的并发数。

6.根据权利要求5所述的系统，其特征在于，所述客户端包括：主体模块、多个处理插件、通讯路由插件、定时任务插件、软件开发工具包SDK插件；采用Java插件框架管理所述客户端的各个插件。

7.根据权利要求3所述的系统，其特征在于，所述Websocket服务集群包括：一个或多个Websocket服务器；

所述Websocket网关集群中的每个Websocket网关，用于从注册中心读取Websocket服务信息列表，根据所述Websocket服务信息列表在Websocket网关内存中创建哈希环，并针对每个所述Websocket服务器插入一个或多个虚拟节点；

每个所述虚拟节点对应所述哈希环中的一个哈希值；每个所述Websocket服务器插入的虚拟节点的数量基于所述Websocket服务器的性能和/或存储空间的特征确定。

8.根据权利要求7所述的系统，其特征在于，所述客户端，还用于向Websocket网关发送Websocket连接请求；

所述Websocket网关，还用于根据所述Websocket连接请求和保存的哈希环，从所述Websocket服务集群中确定目标Websocket服务器，将Websocket连接请求转发到目标Websocket服务器，以使所述客户端与所述目标Websocket服务器建立连接。

9.根据权利要求7所述的系统，其特征在于，所述Websocket网关，用于接收第二消息，根据所述第二消息携带的客户端的标识和哈希环，确定所述客户端对应的Websocket服务器；将所述第二消息转发到所述客户端对应的Websocket服务器；

所述客户端对应的Websocket服务器，用于将所述第二消息发送给客户端。

10.一种业务处理方法，其特征在于，所述方法应用于权利要求1至9中任一项所述的业务处理系统；所述方法包括：

Http网关集群中的每个Http网关接收客户端的第一消息，将接收的第一消息发送到交换中心；

Websocket网关集群中的每个Websocket网关接收所述交换中心发送的第二消息，将接收的第二消息发送给所述第二消息对应的客户端；

业务中心向所述交换中心发送第三消息，以请求所述交换中心进行业务处理；

所述方法还包括以下至少之一：

所述交换中心接收客户端发送的第一消息，根据所述第一消息进行业务处理；

所述交换中心向客户端发送第二消息；

所述交换中心接收业务中心发送的第三消息，根据所述第三消息进行业务处理。