CN110336702A - 一种消息中间件的系统和实现方法 - Google Patents

Abstract

本发明公开了一种消息中间件的系统和实现方法，实现了高性能、低延迟的效果，可以在不降低系统可靠性指标的基础上实现微秒级的延迟。其技术方案为：消息中间件的系统中设置的业务数据流模型架构是在金融衍生品交易领域中通过传输策略优选、无锁队列、内存零拷贝等技术实现的可靠的低延迟系统解决方案。同时系统中设置的统一API动态升级模型架构也解决了由于业务变更导致的API频繁更新的问题。

Description

一种消息中间件的系统和实现方法

技术领域

本发明涉及中间件技术，具体涉及应用于金融期货领域的高性能的针对金融消息的中间件方法和系统。

背景技术

近年来，随着中国金融开放步伐的加速推进，越来越多的投资者参与到了金融衍生品投资领域。随着投资者参与热情的增加，金融服务软件、交易系统的压力与日俱增。面对这一需求，如何解决在保证公平、公开、公正的基础上，提升系统处理能力和响应速度，同时又不以降低系统可靠性为代价这一问题迫在眉睫。

金融消息中间件，在解决这一问题的过程中，起着至关重要的核心作用。中间件是指一种独立的系统软件或者服务程序。基于中间件，用户可以定制化开发实现各种应用程序与接口。金融消息中间件是指针对金融领域需求特性，专门实现的一套定制化中间件解决方案。

2005年金融信息交换协议组织(FIX Protocol Limited简称FPL)提出了基于减少带宽使用率的FAST编码方法。该编码方法是一种面向消息数据流的，具有高的压缩率和处理效率的编解码方法，满足了绝大多数交易系统的信息处理需求。2013年FPL组织又提出了符合FIX规范的简单二进制编码方法(简称SBE)，其主要目标是通过对金融信息数据的简单压缩和编码，从而在数据处理方面实现更低的延迟。然而这些方法都仅仅只是针对消息通讯领域，并没有考虑到数据如何传输，以及应用层数据如何交互。

ZeroMQ是一种基于消息队列的多线程网络库，其对套接字、连接处理甚至底层路由进行抽象，提供了一种跨越多种传输协议的套接字。该方法虽然提供了数据发布订阅模型，然而，其仍然只是一种数据传输手段，并没有提供一套针对金融业务处理模型的解决方案。

发明内容

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。

本发明的目的在于解决上述技术问题，提出了一种消息中间件的系统和实现方法，实现了高性能、低延迟的效果，可以在不降低系统可靠性指标的基础上实现微秒级的延迟。

本发明的技术方案为：本发明揭示了一种消息中间件的系统，系统包括客户端、服务器、在客户端和服务器上实现的统一API动态升级模型架构，在统一API动态升级模型架构中，客户端包括升级服务处理模块和业务规则处理模块，服务器包括API升级服务模块和登录鉴权服务模块，其中统一API动态升级模型架构配置为进行以下的处理：

当客户端启动时升级服务处理模块首先与服务器的API升级服务模块之间建立通讯连接，解析并获取本地业务动态库版本号、版本类型，然后客户端通过API升级协议向服务器发起包括本地业务动态库版本号、版本类型在内的更新请求；

API升级服务模块在接收到来自客户端的更新请求后，首先检测请求报文中的动态库版本号是否与服务器中的本地业务动态库版本号一致，如果一致则服务器通知客户端无需更新，如果不一致则服务器通知客户端更新本地业务动态库，服务器向客户端推送业务动态库更新的数据及校验信息；

客户端在接收到来自服务器推送的业务动态库更新应答后，如果不需要更新本地业务动态库，则客户端断开与服务器的API升级服务模块的通讯连接，转而与服务器的登录鉴权服务模块建立通讯连接以进行登录操作，如果需要更新本地业务动态库，则客户端接收服务器的业务动态库更新的数据及校验信息，先校验更新本地业务动态库以防数据丢失或者出错再进行更新；

客户端在完成本地业务动态库的更新后，主动断开与服务器的API升级会话，业务规则处理模块与服务器的登录鉴权服务模块建立业务会话。

根据本发明的消息中间件的系统的一实施例，客户端的升级服务处理模块和服务器的升级服务模块之间的通讯协议为基于TCP连接的API升级协议，客户端的业务规则处理模块和服务器的登录鉴权服务模块之间的通讯协议为基于TCP连接的FTD协议，API升级协议独立于FTD协议以保持稳定且向后兼容。

根据本发明的消息中间件的系统的一实施例，系统中的统一API接口包括数据发送接口、数据接收接口、行情接收接口和事件接收接口，其中数据发送接口用于发送业务请求，数据接收接口用于接收从服务器返回的应答报文，行情数据接收接口用于接收行情数据，事件接收接口用于接收事件信息，其中的事件包括但不限于：客户端与服务端的会话建立成功、连接断开、连接出错。

根据本发明的消息中间件的系统的一实施例，系统中采用的业务请求应答报文数据帧由业务信息域和业务数据域组成，其中，业务信息域分为业务唯一标识域和数据域大小两个字段，业务唯一标识域标识报文所携带的业务数据域具体的业务类型，用于服务端进行数据解析，数据域大小标识业务数据域的报文长度。

根据本发明的消息中间件的系统的一实施例，系统中采用的行情应答数据帧由行情主题、序列号、业务唯一标识、编码类型四个字段组成，其中行情主题标识行情报文所属的业务范围，序列号标识当前接收到的行情报文在所属的对应行情主题中的次序，业务唯一标识标识行情报文所属的具体业务类型，编码类型标识行情报文的编码方法以用于客户端解码识别。

根据本发明的消息中间件的系统的一实施例，系统还设置了业务数据流模型架构，在业务数据流模型架构中，客户端包括业务层编码单元、第一数据分发单元和第一传输控制单元，服务器包括第二传输控制单元、第二数据分发单元和业务层解码单元，其中业务数据流模型架构配置为进行以下的处理：

客户端发起的业务请求首先在业务层编码单元中进行数据编码，其中每一个编码后的业务数据都代表着一个数据单元；

第一数据分发单元根据指定规则，将业务数据编码后的数据包分发到不同的数据发送队列；

第一传输控制单元将数据发送队列中的数据包通过指定方式发送到服务器；

服务器收到从客户端发送来的请求数据后，交由第二传输控制单元进行处理，第二传输控制单元检测该数据包是否符合规范，校验码是否正确，以及接收序列号是否满足要求，如果检测不通过，则通过数据重传机制通知客户端重新发送请求数据，如果检测通过，则将该数据包交由第二数据分发单元进行处理；

第二数据分发单元在收到上传的数据包时，检测判断该数据包的业务类型，再将其路由给对应的业务层解码单元进行解码处理；

业务层解码单元对第二数据分发单元路由上来的请求进行解码识别，根据具体的业务类型触发业务规则引擎，然后根据业务规则引擎处理结果，更新相应的内存数据库表，并向客户端发送应答信息。

根据本发明的消息中间件的系统的一实施例，第一传输控制单元的触发方式包括事件触发和时钟触发，其中在事件触发方式中，当第一数据分发单元向数据分发队列缓存信息时，同时会触发一信息提交事件，该信息提交事件将激活处于休眠状态的第一传输控制单元使其立即工作；在时钟触发方式中，第一传输控制单元通过定时器触发。

根据本发明的消息中间件的系统的一实施例，第一传输控制单元包括请求应答管理模块、发布订阅管理模块和策略优选模块，其中：

请求应答管理模块用于维护各种请求应答信息、流速控制、超时响应机制；

发布订阅管理模块用于维护各类主题信息的订阅与发布管理，信息重传管理；

策略优选模块用于实现传输策略优选机制，根据业务数据包类型进行传输控制。

本发明还揭示了一种消息中间件的实现方法，方法包括：

当客户端启动时客户端中的升级服务处理模块首先与服务器中的API升级服务模块之间建立通讯连接，解析并获取本地业务动态库版本号、版本类型，然后客户端通过API升级协议向服务器发起包括本地业务动态库版本号、版本类型在内的更新请求；

API升级服务模块在接收到来自客户端的更新请求后，首先检测请求报文中的动态库版本号是否与服务器中的本地业务动态库版本号一致，如果一致则服务器通知客户端无需更新，如果不一致则服务器通知客户端更新本地业务动态库，服务器向客户端推送业务动态库更新的数据及校验信息；

客户端在接收到来自服务器推送的业务动态库更新应答后，如果不需要更新本地业务动态库，则客户端断开与服务器的API升级服务模块的通讯连接，转而与服务器中的登录鉴权服务模块建立通讯连接以进行登录操作，如果需要更新本地业务动态库，则客户端接收服务器的业务动态库更新的数据及校验信息，先校验更新本地业务动态库以防数据丢失或者出错再进行更新；

客户端在完成本地业务动态库的更新后，主动断开与服务器的API升级会话，然后客户端中的业务规则处理模块与服务器的登录鉴权服务模块建立业务会话。

根据本发明的消息中间件的实现方法的一实施例，方法还包括：

客户端在完成API升级会话后发起的业务请求首先在客户端的业务层编码单元中进行数据编码，其中每一个编码后的业务数据都代表着一个数据单元；

客户端的第一数据分发单元根据指定规则，将业务数据编码后的数据包分发到不同的数据发送队列；

客户端的第一传输控制单元将数据发送队列中的数据包通过指定方式发送到服务器；

服务器收到从客户端发送来的请求数据后，交由服务器中的第二传输控制单元进行处理，第二传输控制单元检测该数据包是否符合规范，校验码是否正确，以及接收序列号是否满足要求，如果检测不通过，则通过数据重传机制通知客户端重新发送请求数据，如果检测通过，则将该数据包交由第二数据分发单元进行处理；

服务器中的第二数据分发单元在收到上传的数据包时，检测判断该数据包的业务类型，再将其路由给对应的业务层解码单元进行解码处理；

服务器中的业务层解码单元对第二数据分发单元路由上来的请求进行解码识别，根据具体的业务类型触发业务规则引擎，然后根据业务规则引擎处理结果，更新相应的内存数据库表，并向客户端发送应答信息。

本发明对比现有技术有如下的有益效果：本发明的消息中间件的系统中设置的业务数据流模型架构是在金融衍生品交易领域中通过传输策略优选、无锁队列、内存零拷贝等技术实现的可靠的低延迟系统解决方案。同时系统中设置的统一API动态升级模型架构也解决了由于业务变更导致的API频繁更新的问题。

附图说明

在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。

图1示出了本发明的消息中间件的系统中所设置的统一API动态升级模型架构的示意图。

图2示出了本发明消息中间件的系统中所采用的请求应答报文帧结构的示意图。

图3示出了本发明消息中间件的系统中所采用的行情应答报文帧结构的示意图。

图4示出了本发明的消息中间件的系统中所设置的业务数据流模型架构的示意图。

图5示出了本发明的消息中间件的实现方法中的统一API动态升级模型的实现流程图。

图6示出了本发明的消息中间件的实现方法中的业务数据流模型的实现流程图。

具体实施方式

以下结合附图和具体实施例对本发明作详细描述。注意，以下结合附图和具体实施例描述的诸方面仅是示例性的，而不应被理解为对本发明的保护范围进行任何限制。

本发明的消息中间件的系统包括客户端和服务器、以及在客户端和服务器上实现的统一API动态升级模型架构和业务数据流模型架构。

图1示出了本发明的消息中间件的系统中设置的统一API动态升级模型架构。请参见图1，在这一架构中，客户端包括升级服务处理模块和业务规则处理模块，服务器包括API升级服务模块和登录鉴权服务模块。统一API动态升级模型架构解决了由于业务变更导致的API频繁更新的问题。

客户端的升级服务处理模块和服务器的升级服务模块之间的通讯协议为基于TCP连接的API升级协议。

客户端的业务规则处理模块和服务器的登录鉴权服务模块之间的通讯协议为基于TCP连接的FTD协议。在本实施例中，FTD协议即Futures trading data exchangeprotocol,是指期货交易数据交换协议，详见中国证券监督管理委员会2014年55号公告《公布金融行业推荐性标准<期货交易数据交换协议>(JR/T0016-2014)》。

考虑到随着业务需求的变更，例如国密加密、通道加密、看穿式监管等需求的提出，业务规则处理模块与登录鉴权服务模块之间的通讯协议将会频繁更新。因此，为了实现服务端对客户端API的自动兼容，API升级协议必须独立于FTD协议，以保持稳定并且向后兼容。

当客户端启动时，客户端的升级服务处理模块首先与服务器的API升级服务模块之间建立一个TCP连接，然后解析并获取本地业务动态库版本号、版本类型，然后客户端通过API升级协议向服务器发起业务动态库更新请求，其中，更新请求信息包括但不限于：本地业务动态库版本类型、本地业务动态库版本号，例如，Linux、Windows32、Windows 64等。

服务器的API升级服务模块在接收到来自客户端的更新请求后，首先检测请求报文中的动态库版本号是否与服务器中的本地业务动态库版本号一致。如果一致则服务器通知客户端无需更新，如果不一致则服务器通知客户端更新本地业务动态库，并且服务器向客户端推送业务动态库更新的应答，包括完整的业务动态库的数据以及校验信息。

客户端在接收到来自服务器推送的业务动态库更新应答后，如果不需要更新本地业务动态库，则客户端断开与服务器的API升级服务模块的TCP连接，使用FTD协议连接服务器的登录鉴权服务模块，进行登录操作。如果需要更新本地业务动态库，则客户端接收服务器的业务动态库的数据及一致性校验信息，先校验更新本地业务动态库以防数据丢失或者出错，再进行更新。

客户端在完成本地业务动态库的更新(即业务动态库升级结束)后，客户端主动断开与服务器的API升级会话，业务规则处理模块立即与服务器的登录鉴权服务模块建立基于FTD协议的业务会话。当会话建立成功后，客户端即可进行登录认证等业务操作。

消息中间件的系统的统一API接口如下：

所有的业务请求(包括随着后续业务变更新增的业务需求)都通过数据发送接口(SendRequest接口)发送，这样可以极大的降低开发人员学习成本。其中，SendRequest为数据发送接口，nRequestID为请求序号，由用户自行维护。在收到服务器的应答报文时，客户端可以基于请求序号区分出该应答报文对应于哪一个请求报文。OnUserData为数据接收接口，用于接收从服务器返回的应答报文。OnMarketData则为行情数据接收接口。OnEvent为事件接收接口，这里的事件主要包括客户端与服务端的会话建立成功、连接断开、连接出错等。

图2示出了业务请求应答报文数据帧结构。一个业务报文帧由业务信息域和业务数据域组成。其中，业务信息域又分为业务唯一标识域和数据域大小两个字段。业务唯一标识域标识了该报文所携带的业务数据域具体的业务类型，用于服务端进行数据解析。而数据域大小则标识了业务数据域的报文长度。需要指出的是，随着服务端业务需求的升级更新，有可能部分客户并不更新升级API，此时，客户端的数据域大小明显会小于服务端识别的业务数据域大小。为了实现兼容，服务端需要根据这里的数据域大小进行报文切分。

图3示出了行情应答数据帧结构，即上述表格中的CUstpFtdcMdInfo接口。行情应答数据帧主要由行情主题、序列号、业务唯一标识、编码类型四个字段组成。行情主题标识了该行情数据属于哪一个具体的业务范围，例如中金所一档行情、中金所五档行情。序列号则标识了当前接收到的数据报文属于该行情主题的第几个报文。当客户发现序列号出现乱序或者丢失时，可以据此发送行情重传请求进行数据重传，以防由于网络原因引起的行情信息丢失。业务唯一标识则表示了该行情报文所属的具体业务类型，例如ETF期权行情、五年期国债行情。编码类型则标识了该行情报文的编码方法，用于客户端解码识别，例如SBE、FAST等。

图4示出了本发明的消息中间件的系统中设置的业务数据流模型架构。请参见图4，在这一架构中，客户端包括业务层编码单元、第一数据分发单元和第一传输控制单元，服务器包括第二传输控制单元、第二数据分发单元和业务层解码单元。

客户端在登录成功后发起一个业务请求时，业务请求首先通过业务层编码单元在应用层对该业务请求的数据进行编码。本实施例的编码方式包括但不限于FAST、简单二进制编码SBE，Google Protocol Buffer等。每一个编码后的业务数据都代表着一个数据单元，具有特定的业务含义，例如订单请求、订单应答、撤单请求，撤单应答，强平请求等。编码后的数据包交由第一数据分发单元进行处理。

客户端在业务层对业务数据进行编码后，将数据包提交给第一数据分发单元。第一数据分发单元在本地维护一个业务数据分发列表。在客户端，第一数据分发单元负责根据指定的规则(例如数据包的具体业务类型)，将上层传递下来的数据包分发到不同的数据发送队列。这里数据发送队列主要包括请求-应答和发布-订阅。

在数据分发单元下有一个第一传输控制单元，第一传输控制单元用于根据业务数据分发列表进行数据传输，将数据发送队列中的数据包通过指定方式发送到服务器。第一传输控制单元的触发方式有两种，分别为事件触发和时钟触发。通常情况下，第一传输控制单元处于休眠状态，以降低系统资源使用率。在事件触发方式中，当第一数据分发单元向数据分发队列缓存信息时，同时会触发一个信息提交事件。该信息提交事件将激活处于休眠状态的第一传输控制单元，使第一传输控制单元立即工作，第一传输控制单元从数据分发列表读取数据并进行发送，从而降低传输延迟。另一方面，在时钟触发方式中，第一传输控制单元也可以通过定时器触发，从而从网络上读取可能存在的通信请求。

第一传输控制单元分为请求应答管理模块、发布订阅管理模块和策略优选模块。

请求应答管理模块用于维护各种请求应答信息、流速控制、超时响应机制等。在发送一个请求报文后，第一请求应答管理模块根据超时响应机制判断该报文是否有对应的应答信息，如果没有，则通知上层单元报文超时。流速控制则是在单位时间内，上层发送下来的业务请求报文有数量限制，一旦请求报文超过该数量，则直接抛弃并返回相应错误信息给上层单元。

发布订阅管理模块用于维护各类主题信息的订阅与发布管理，信息重传管理等。例如，发布订阅管理模块根据不同的主题进行信息订阅，当收到一个主题报文时，首先对该报文进行校验和序号确认。一旦发生乱序或者信息校验失败，则抛弃该报文，并通知服务器进行数据重传。

策略优选模块用于实现传输策略优选机制，根据业务数据包类型进行传输控制，从而在有限的系统资源下，进行高效的资源调度配置，进一步降低网络传输延迟。由于操作系统资源、网络硬件资源的限制，单个发送线程一次可以发送的最大数据量有最大限值，同时由于单个线程的串行发送机制，导致业务数据分发列表中的数据会产生累计延迟。例如假设第一个数据包完全发送需要耗时2us，那么第二个数据包必须等待2us以后才能进入发送流程，也就是总计耗时4us。策略优选模块用于解决这一传输累计延迟问题。具体而言，对于性能延迟要求极高的请求报文，第一传输控制单元会直接通过网卡将其发送出去。而对于性能延迟要求次高的请求报文，则在单位时间内，尽可能高的利用网络发送缓冲区大小，一次性批量发送多个报文。

服务器收到从客户端发送来的请求数据后，首先交由第二传输控制单元进行处理。

第二传输控制单元用于检测该数据包是否符合规范，校验码是否正确，以及接收序列号是否满足要求。如果检测不通过，则通过数据重传机制通知客户端重新发送请求数据。如果检测通过，则将该数据包交由第二数据分发单元进行处理。

第二数据分发单元在收到上传的数据包时，首先检测判断该数据包的业务类型，然后将其路由给对应的业务层解码单元进行解码处理。

业务层解码单元对第二数据分发单元路由上来的请求进行解码识别，根据具体的业务类型触发业务规则引擎，例如资金冻结、持仓更新等，然后根据业务规则引擎处理结果，更新相应的内存数据库表，向客户端发送应答信息。

图5示出了本发明的消息中间件的实现方法中的统一API动态升级模型的实现流程。请参见图5，本实施例的方法步骤详述如下。

步骤S11：当客户端启动时客户端中的升级服务处理模块首先与服务器中的API升级服务模块之间建立通讯连接，解析并获取本地业务动态库版本号、版本类型，然后客户端通过API升级协议向服务器发起包括本地业务动态库版本号、版本类型在内的更新请求。

步骤S12：API升级服务模块在接收到来自客户端的更新请求后，首先检测请求报文中的动态库版本号是否与服务器中的本地业务动态库版本号一致，如果一致则服务器通知客户端无需更新，如果不一致则服务器通知客户端更新本地业务动态库，服务器向客户端推送业务动态库更新的数据及校验信息。

步骤S13：客户端在接收到来自服务器推送的业务动态库更新应答后，如果不需要更新本地业务动态库，则客户端断开与服务器的API升级服务模块的通讯连接，转而与服务器中的登录鉴权服务模块建立通讯连接以进行登录操作，如果需要更新本地业务动态库，则客户端接收服务器的业务动态库更新的数据及校验信息，先校验更新本地业务动态库以防数据丢失或者出错再进行更新。

步骤S14：客户端在完成本地业务动态库的更新后，主动断开与服务器的API升级会话，然后客户端中的业务规则处理模块与服务器的登录鉴权服务模块建立业务会话。

图6示出了本发明的消息中间件的实现方法中的业务数据流模型的实现流程图。请参见图6，本实施例的方法步骤在图5所示步骤之后进行处理，其具体步骤详述如下。

步骤S21：客户端在完成API升级会话后发起的业务请求首先在客户端的业务层编码单元中进行数据编码，其中每一个编码后的业务数据都代表着一个数据单元。

步骤S22：客户端的第一数据分发单元根据指定规则，将业务数据编码后的数据包分发到不同的数据发送队列。

步骤S23：客户端的第一传输控制单元将数据发送队列中的数据包通过指定方式发送到服务器。

步骤S24：服务器收到从客户端发送来的请求数据后，交由服务器中的第二传输控制单元进行处理，第二传输控制单元检测该数据包是否符合规范，校验码是否正确，以及接收序列号是否满足要求，如果检测不通过，则通过数据重传机制通知客户端重新发送请求数据，如果检测通过，则将该数据包交由第二数据分发单元进行处理。

步骤S25：服务器中的第二数据分发单元在收到上传的数据包时，检测判断该数据包的业务类型，再将其路由给对应的业务层解码单元进行解码处理。

步骤S26：服务器中的业务层解码单元对第二数据分发单元路由上来的请求进行解码识别，根据具体的业务类型触发业务规则引擎，然后根据业务规则引擎处理结果，更新相应的内存数据库表，并向客户端发送应答信息。

尽管为使解释简单化将上述方法图示并描述为一系列动作，但是应理解并领会，这些方法不受动作的次序所限，因为根据一个或多个实施例，一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。

本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。

结合本文所公开的实施例描述的各种解说性逻辑板块、模块、和电路可用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其设计成执行本文所描述功能的任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合，例如DSP与微处理器的组合、多个微处理器、与DSP核心协作的一个或多个微处理器、或任何其他此类配置。

结合本文中公开的实施例描述的方法或算法的步骤可直接在硬件中、在由处理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动盘、CD-ROM、或本领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读取和写入信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在ASIC中。ASIC可驻留在用户终端中。在替换方案中，处理器和存储介质可作为分立组件驻留在用户终端中。

在一个或多个示例性实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现为计算机程序产品，则各功能可以作为一条或更多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者，其包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，这样的计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的合意程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线(DSL)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来，则该同轴电缆、光纤电缆、双绞线、DSL、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(CD)、激光碟、光碟、数字多用碟(DVD)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据，而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可读介质的范围内。

提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。

Claims (10)

1.一种消息中间件的系统，其特征在于，包括客户端、服务器、在客户端和服务器上实现的统一API动态升级模型架构，在统一API动态升级模型架构中，客户端包括升级服务处理模块和业务规则处理模块，服务器包括API升级服务模块和登录鉴权服务模块，其中统一API动态升级模型架构配置为进行以下的处理：

当客户端启动时升级服务处理模块首先与服务器的API升级服务模块之间建立通讯连接，解析并获取本地业务动态库版本号、版本类型，然后客户端通过API升级协议向服务器发起包括本地业务动态库版本号、版本类型在内的更新请求；

API升级服务模块在接收到来自客户端的更新请求后，首先检测请求报文中的动态库版本号是否与服务器中的本地业务动态库版本号一致，如果一致则服务器通知客户端无需更新，如果不一致则服务器通知客户端更新本地业务动态库，服务器向客户端推送业务动态库更新的数据及校验信息；

客户端在接收到来自服务器推送的业务动态库更新应答后，如果不需要更新本地业务动态库，则客户端断开与服务器的API升级服务模块的通讯连接，转而与服务器的登录鉴权服务模块建立通讯连接以进行登录操作，如果需要更新本地业务动态库，则客户端接收服务器的业务动态库更新的数据及校验信息，先校验更新本地业务动态库以防数据丢失或者出错再进行更新；

客户端在完成本地业务动态库的更新后，主动断开与服务器的API升级会话，业务规则处理模块与服务器的登录鉴权服务模块建立业务会话。

2.根据权利要求1所述的消息中间件的系统，其特征在于，客户端的升级服务处理模块和服务器的升级服务模块之间的通讯协议为基于TCP连接的API升级协议，客户端的业务规则处理模块和服务器的登录鉴权服务模块之间的通讯协议为基于TCP连接的FTD协议，API升级协议独立于FTD协议以保持稳定且向后兼容。

3.根据权利要求1所述的消息中间件的系统，其特征在于，系统中的统一API接口包括数据发送接口、数据接收接口、行情接收接口和事件接收接口，其中数据发送接口用于发送业务请求，数据接收接口用于接收从服务器返回的应答报文，行情数据接收接口用于接收行情数据，事件接收接口用于接收事件信息，其中的事件包括但不限于：客户端与服务端的会话建立成功、连接断开、连接出错。

4.根据权利要求3所述的消息中间件的系统，其特征在于，系统中采用的业务请求应答报文数据帧由业务信息域和业务数据域组成，其中，业务信息域分为业务唯一标识域和数据域大小两个字段，业务唯一标识域标识报文所携带的业务数据域具体的业务类型，用于服务端进行数据解析，数据域大小标识业务数据域的报文长度。

5.根据权利要求4所述的消息中间件的系统，其特征在于，系统中采用的行情应答数据帧由行情主题、序列号、业务唯一标识、编码类型四个字段组成，其中行情主题标识行情报文所属的业务范围，序列号标识当前接收到的行情报文在所属的对应行情主题中的次序，业务唯一标识标识行情报文所属的具体业务类型，编码类型标识行情报文的编码方法以用于客户端解码识别。

6.根据权利要求1所述的消息中间件的系统，其特征在于，系统还设置了业务数据流模型架构，在业务数据流模型架构中，客户端包括业务层编码单元、第一数据分发单元和第一传输控制单元，服务器包括第二传输控制单元、第二数据分发单元和业务层解码单元，其中业务数据流模型架构配置为进行以下的处理：

客户端发起的业务请求首先在业务层编码单元中进行数据编码，其中每一个编码后的业务数据都代表着一个数据单元；

第一数据分发单元根据指定规则，将业务数据编码后的数据包分发到不同的数据发送队列；

第一传输控制单元将数据发送队列中的数据包通过指定方式发送到服务器；

服务器收到从客户端发送来的请求数据后，交由第二传输控制单元进行处理，第二传输控制单元检测该数据包是否符合规范，校验码是否正确，以及接收序列号是否满足要求，如果检测不通过，则通过数据重传机制通知客户端重新发送请求数据，如果检测通过，则将该数据包交由第二数据分发单元进行处理；

第二数据分发单元在收到上传的数据包时，检测判断该数据包的业务类型，再将其路由给对应的业务层解码单元进行解码处理；

业务层解码单元对第二数据分发单元路由上来的请求进行解码识别，根据具体的业务类型触发业务规则引擎，然后根据业务规则引擎处理结果，更新相应的内存数据库表，并向客户端发送应答信息。

7.根据权利要求6所述的消息中间件的系统，其特征在于，第一传输控制单元的触发方式包括事件触发和时钟触发，其中在事件触发方式中，当第一数据分发单元向数据分发队列缓存信息时，同时会触发一信息提交事件，该信息提交事件将激活处于休眠状态的第一传输控制单元使其立即工作；在时钟触发方式中，第一传输控制单元通过定时器触发。

8.根据权利要求6所述的消息中间件的系统，其特征在于，第一传输控制单元包括请求应答管理模块、发布订阅管理模块和策略优选模块，其中：

请求应答管理模块用于维护各种请求应答信息、流速控制、超时响应机制；

发布订阅管理模块用于维护各类主题信息的订阅与发布管理，信息重传管理；

策略优选模块用于实现传输策略优选机制，根据业务数据包类型进行传输控制。

9.一种消息中间件的实现方法，其特征在于，方法包括：

当客户端启动时客户端中的升级服务处理模块首先与服务器中的API升级服务模块之间建立通讯连接，解析并获取本地业务动态库版本号、版本类型，然后客户端通过API升级协议向服务器发起包括本地业务动态库版本号、版本类型在内的更新请求；

API升级服务模块在接收到来自客户端的更新请求后，首先检测请求报文中的动态库版本号是否与服务器中的本地业务动态库版本号一致，如果一致则服务器通知客户端无需更新，如果不一致则服务器通知客户端更新本地业务动态库，服务器向客户端推送业务动态库更新的数据及校验信息；

客户端在接收到来自服务器推送的业务动态库更新应答后，如果不需要更新本地业务动态库，则客户端断开与服务器的API升级服务模块的通讯连接，转而与服务器中的登录鉴权服务模块建立通讯连接以进行登录操作，如果需要更新本地业务动态库，则客户端接收服务器的业务动态库更新的数据及校验信息，先校验更新本地业务动态库以防数据丢失或者出错再进行更新；

客户端在完成本地业务动态库的更新后，主动断开与服务器的API升级会话，然后客户端中的业务规则处理模块与服务器的登录鉴权服务模块建立业务会话。

10.根据权利要求9所述的消息中间件的实现方法，其特征在于，方法还包括：

客户端在完成API升级会话后发起的业务请求首先在客户端的业务层编码单元中进行数据编码，其中每一个编码后的业务数据都代表着一个数据单元；

客户端的第一数据分发单元根据指定规则，将业务数据编码后的数据包分发到不同的数据发送队列；

客户端的第一传输控制单元将数据发送队列中的数据包通过指定方式发送到服务器；

服务器收到从客户端发送来的请求数据后，交由服务器中的第二传输控制单元进行处理，第二传输控制单元检测该数据包是否符合规范，校验码是否正确，以及接收序列号是否满足要求，如果检测不通过，则通过数据重传机制通知客户端重新发送请求数据，如果检测通过，则将该数据包交由第二数据分发单元进行处理；

服务器中的第二数据分发单元在收到上传的数据包时，检测判断该数据包的业务类型，再将其路由给对应的业务层解码单元进行解码处理；

服务器中的业务层解码单元对第二数据分发单元路由上来的请求进行解码识别，根据具体的业务类型触发业务规则引擎，然后根据业务规则引擎处理结果，更新相应的内存数据库表，并向客户端发送应答信息。