金融系统的开发方法及系统与流程

本发明属于金融技术领域，尤其涉及金融系统的开发方法及系统。

背景技术：

各种金融类的交易需要开发商提供强大的后台计算系统，以处理众多金融交易所产生的海量数据。目前，金融市场出现了一些在分布式环境下解决大型复杂金融问题的集群化应用平台，这些大型金融系统，不仅需要处理实际的金融领域问题，还要为这些处理金融问题的程序提供辅助功能以及底层支持。

然而，现有的业务逻辑只能基于C++开发，C++语法复杂，开发效率低，对开发人员的要求很高。同时，开发出来的业务逻辑模块移植性较差，需要针对不同的平台、不同的编译器进行专门性的开发、测试、部署，因此，现有的金融系统开发人员在开发金融业务应用时，还需要关注底层系统，浪费了开发人员的时间成本以及加大了开发和维护的难度。

技术实现要素：

有鉴于此，本发明实施例提供了金融系统的开发方法及系统，以解决现有的金融交易系统在开发时调试困难以及业务逻辑移植性较差的问题。第一方面，创建金融系统的业务逻辑，并创建用于支持所述业务逻辑运行的系统工作单元；接收客户端发送的业务请求；将所述业务请求发送到代理队列中；按照公平队列方式将所述业务请求分发到一个以上的所述工作单元中；调用业务逻辑，使所述业务逻辑运行在所述工作单元中，并对所述业务请求进行处理，生成处理结果；将所述处理结果发送给客户端。

第二方面，提供了一种金融系统的开发系统，包括：创建模块，用于创建金融系统的业务逻辑，并创建用于支持所述业务逻辑运行的系统工作单元；

第一接收模块，用于接收客户端发送的业务请求；转发模块，用于将所述业务请求发送到代理队列中；代理队列模块，用于按照公平队列方式将所述业务请求分发到一个以上的所述工作单元中；处理模块，用于调用业务逻辑，使所述业务逻辑运行在所述工作单元中，并对所述业务请求进行处理，生成处理结果；发送模块，用于将所述处理结果发送给客户端。

在本发明实施例中，通过创建金融系统的业务逻辑以及用于支持业务逻辑运行的工作单元；接收客户端发送的业务请求；将业务请求发送到代理队列中；按照公平队列方式将业务请求分发到一个以上的工作单元中；调用业务逻辑，使业务逻辑运行在工作单元中，并对业务请求进行处理，生成处理结果；将处理结果发送给客户端，使得开发人员只需要开发应用层的业务逻辑，而不需要关注底层细节。本发明实施例的有益效果是降低了开发和维护金融交易系统的难度，且提高了开发效率。

附图说明

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

图1是本发明实施例一提供的金融系统的开发方法的实现流程图；

图2是本发明实施例一提供的金融系统的层次结构图；

图3是本发明实施例一提供的金融系统的逻辑结构图；

图4是本发明实施例一提供的金融系统的开发方法S101的具体实现流程图；

图5是本发明实施例一提供的金融系统的开发方法S105的具体实现流程图；

图6是本发明实施例二提供的金融系统的开发方法的实现流程图；

图7是本发明实施例三提供的金融系统的开发方法的实现流程图；

图8是本发明实施例四提供的金融系统的开发方法的实现流程图；

图9是本发明实施例五提供的金融系统的开发系统结构框图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本发明实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本发明。在其它情况中，省略对众所周知的系统、系统、电路以及方法的详细说明，以免不必要的细节妨碍本发明的描述。

建立工作单元以及业务逻辑；接收客户端发送的业务请求；将业务请求发送到代理队列中；按照公平队列方式将业务请求分发到一个以上的工作单元中；调用业务逻辑，使业务逻辑运行在工作单元中，并对业务请求进行处理，生成处理结果；将处理结果发送给客户端。

实施例一：

图1示出了本发明实施例一提供的金融系统的开发方法的实现流程，详述如下：

在S101中，创建金融系统的业务逻辑，并创建用于支持业务逻辑运行的工作单元；接收客户端发送的业务请求。

为了更好的解决金融领域需要处理海量交易数据的问题，本发明实施例开发出了一个金融交易系统，为分布式环境下解决大型复杂的集群化应用提供灵活和易用的平台。本系统最主要的两个概念，一个是工作单元，另一个是业务逻辑。

业务逻辑是开发人员为实现某些金融交易功能开发的应用程序，开发人员可以使用一些API函数(应用程序编程接口函数)调用一些已存在的业务逻辑来实现业务功能。也可以自己编写一些可装载的业务逻辑模块来实现业务功能。这里提到的可装载的业务逻辑模块是用户编写的，可以在不中断系统运行的情况下动态加载或卸载业务逻辑模块。

工作单元封装了属于网络层、数据库等一些底层的功能，为业务逻辑提供了运行环境、系统资源和调用接口。这样金融业务的开发者可以把精力放在业务逻辑的开发上，而不需要关心网络和数据处理等系统功能细节。

业务逻辑和工作单元开发完成以后，可以像搭积木一样，通过配置文件任意组合不同的业务逻辑以及工作单元，从而实现不同的业务需求。

图2示出了本发明实施例一提供的金融系统的层次结构图。

图中的IB-kernel是整个系统的最底层，用于支撑整个系统的运行，这一层不是本发明实施例的创新点，因此其运行方式和原理不在此详述。

图中的IB-Engine分为若干个中间引擎如队列引擎、数据库引擎、内存数据库引擎以及日志引擎等，上文提到的工作单元就属于这一层，也就是工作单元运行在IB-kernel层之上。值得注意的是整个系统有多个工作单元，每个工作单元支持的应用程序可能存在不同，每个工作单元自身的系统程序以及封装的接口也可能存在不同。

图中的脚本引擎，可以为业务逻辑提供执行环境。

图中的业务脚本即上文提到的业务逻辑，用于处理具体的金融交易问题。

图3示出了本发明实施例一提供的金融系统的逻辑结构图。本金融系统支持在Linux及Windows上运行。本发明实施例的交易平台,都是以一个个工作单元的形式存在,每个工作单元是一个独立的线程,每个工作单元上有多个业务逻辑来执行任务,每个业务逻辑都是由事件驱动的。每个工作单元有一个Listener端点和若干个Connector端点。Listener用于接收客户端的请求，并根据请求的业务逻辑名把请求分派到内部的工作单元上。每个工作单元可以通过Connector连接到其他工作上，业务逻辑可以通过Connector请求其他工作单元上的业务逻辑。

图4示出了本发明实施例一提供的金融系统的开发方法S101的具体实现流程。详述如下：

在S401中，读取配置文件。

在本发明实施例中，配置文件是YAML格式的配置文件。YAML(另一种标记语言)是一种直观的能够被计算机识别的数据序列化格式，它的可读性强，容易被人阅读且容易和脚本语言交互，常用来表达资料序列。

在本发明实施例中，在系统启动时，读取YAML格式的配置文件。

在S402中，根据配置文件创建工作单元。

在本发明实施例中，系统启动时，会首先读取当前目录下ison.yaml配置文件，根据配置文件的内容创建工作单元。配置文件格式如下：

在S403中，根据配置文件创建业务逻辑，创建业务逻辑包括：创建Javascript或C++脚本文件。

在本发明实施例中，处理金融业务的程序是由Javascript或C++脚本文件编写的。

在S102中，接收客户端发送的业务请求。

在本发明实施例中，系统接收来自客户端发送的金融交易业务请求，在后续的流程中，系统会根据这个业务请求选择合适的工作单元和业务逻辑。

在S103中，将业务请求发送到代理队列中。

在本发明实施例中，在工作单元运行之前，客户端的业务请求会先经过一个代理队列(也可以称作Shared Queue)。因为在本发明实施例可以同时运行多个处理相同业务的工作单元，通过代理队列可以实现工作单元的横向扩展。

在S104中，按照公平队列方式将业务请求分发到一个以上的工作单元中。

代理队列的工作方式是，当接收到客户端的业务请求后，代理队列会把业务请求按顺序逐个发送到多个工作单元中进行处理。例如：客户端c和客户端d发送业务请求到系统，系统接收了这些业务请求后，先传递到代理队列中，再由代理队列按顺序逐个把业务请求转发到工作单元b和工作单元c。

在S105中，调用业务逻辑，使业务逻辑运行在工作单元中，并对业务请求进行处理，生成处理结果。

图5示出了本发明实施例一提供的金融系统的开发方法S105的具体实现流程。详述如下：

在S501中，获取业务请求。

在本发明实施例中，工作单元在S501步骤中接收代理队列转发的业务请求。每个工作单元有一个Listener端点和若干个Connector端点。Listener用于接收客户端的请求，并根据请求的业务逻辑名把请求分派到内部的工作单元上。每个工作单元可以通过Connector连接到其他工作上，业务逻辑可以通过Connector请求其他工作单元上的业务逻辑。

在S502中，根据业务请求中包含的业务逻辑名，调用业务逻辑，使业务逻辑运行在工作单元中。

客户端发送的业务请求中，包含需要调用的业务逻辑名。工作单元接收到业务请求后，会根据业务逻辑名，分析出需要调用哪些业务逻辑。上文介绍过工作单元作为底层系统为业务逻辑提供运行环境，业务逻辑运行在工作单元基础之上。

在S503中，组合业务逻辑，生成完整业务执行逻辑。

在本发明实施例中，有些业务请求通过工作单元调用一个业务逻辑就可以完成，然而也有很多业务请求需要调用多个业务逻辑才可以完成。因此对于那些调用多个业务逻辑才可以完成的业务请求，工作单元需要组合多个业务逻辑并生成一个完整的业务执行逻辑。

在S106中，通过完整业务执行逻辑，处理业务请求，生成处理结果。

在S107中，将处理结果发送给客户端。

实施例二：

图6示出了本发明实施例二提供的金融系统的开发方法的实现流程，详述如下：

在S601中，建立工作单元以及业务逻辑。

为了更好的解决金融领域需要处理海量交易数据的问题，本发明实施例开发出了一个金融交易系统，为分布式环境下解决大型复杂的集群化应用提供灵活和易用的平台。本系统最主要的两个概念，一个是工作单元，另一个是业务逻辑。

业务逻辑是开发人员为实现某些金融交易功能开发的应用程序，开发人员可以调用一些业务系统中已经存在的API函数(应用程序编程接口函数)作为业务逻辑，来实现业务功能。也可以自己编写一些可装载的业务逻辑模块来作为业务逻辑，来实现业务功能。这里提到的可装载的业务逻辑模块是用户编写的，可以在不中断系统运行的情况下动态加载或卸载业务处理模块。

工作单元封装了网络层、数据库、内部数据库以及日志等一些底层功能，为业务逻辑提供了运行环境、系统资源和调用接口。这样金融业务的开发者可以把精力放在业务逻辑的开发上，而不需要关心网络和数据处理等系统功能细节。

业务逻辑和工作单元开发完成以后，可以像搭积木一样，通过配置文件任一组合不同的业务逻辑以及工作单元，从而实现不同的业务需求。

图2示出了本发明实施例二提供的金融系统的层次结构图。

图中的IB-kernel是整个系统的最底层，用于支撑整个系统的运行，这一层不是本发明实施例的创新点，因此其运行方式和原理不在此详述。

图中的IB-Engine分为若干个中间引擎如队列引擎、数据库引擎、内存数据库引擎以及日志引擎，这一层就相当于上文提到的工作单元。指的注意的是整个系统有多个工作单元，每个工作单元支持的应用程序可能存在不同，每个工作单元自身的系统程序以及封装的接口也可能存在不同。

图中的脚本引擎，可以为业务逻辑提供执行环境。

图中的业务脚本即上文提到的业务逻辑，用于处理具体的金融交易问题。

图3示出了本发明实施例二提供的金融系统的逻辑结构图。本金融系统支持在Linux及Windows上运行。本发明实施例的交易平台,都是以一个个工作单元的形式存在,每个工作单元是一个独立的线程,每个工作单元上有多个业务逻辑来执行任务,每个业务逻辑都是由事件驱动的。每个工作单元有一个Listener端点和若干个Connector端点。Listener用于接收客户端的请求，并根据请求的业务逻辑名把请求分派到内部的工作单元上。每个工作单元可以通过Connector连接到其他工作上，业务逻辑可以通过Connector请求其他工作单元上的业务逻辑。

图4示出了本发明实施例二提供的金融系统的开发方法S101的具体实现流程。详述如下：

在S401中，读取配置文件。

在本发明实施例中，配置文件是YAML格式的配置文件。YAML(另一种标记语言)是一种直观的能够被计算机识别的数据序列化格式，它的可读性强，容易被人阅读且容易和脚本语言交互，常用来表达资料序列。

在本发明实施例中，在系统启动时，读取YAML格式的配置文件。

在S402中，根据配置文件创建工作单元，工作单元为业务逻辑提供网络层、数据库以及日志接口。

在本发明实施例中，系统启动时，会首先读取当前目录下ison.yaml配置文件，根据配置文件的内容创建工作单元。配置文件格式如下：

在S403中，根据配置文件创建业务逻辑，创建业务逻辑包括：创建Javascript或C++脚本文件。

在本发明实施例中，处理金融业务的程序是由Javascript或C++脚本文件编写的。

在S602中，接收客户端的订阅主题。

在本发明实施例中，在工作单元之前存在一个转运代理，系统在接收到客户端发送的订阅主题之后，会把订阅主题发送到转运代理中。

在S603中，接收各个工作单元发布的消息作为待发送消息。

各个工作单元会把发布的待发送的消息首先发送到转运代理中，作为待发送消息。

在S604中，将主题为订阅主题的待发送消息发送给客户端。

转运代理会比对接收到的订阅主题，以及接收到的待发送消息，接着将主题为订阅主题的待发送消息发送给客户端。

实施例三：

本实施例与实施例1的最大不同是：本实施例没有代理队列，工作单元可以直接调用业务逻辑，但是也因此失去了将多个工作单元横向扩展的能力，不可以将多个客户端的相似请求分发到多个工作单元同时处理。

图7示出了本发明实施例三提供的金融系统的开发方法的实现流程，详述如下：

在S701中，建立工作单元以及业务逻辑。

为了更好的解决金融领域需要处理海量交易数据的问题，本发明实施例开发出了一个金融交易系统，为分布式环境下解决大型复杂的集群化应用提供灵活和易用的平台。本系统最主要的两个概念，一个是工作单元，另一个是业务逻辑。

业务逻辑是开发人员为实现某些金融交易功能开发的应用程序，开发人员可以调用一些业务系统中已经存在的API函数(应用程序编程接口函数)作为业务逻辑，来实现业务功能。也可以自己编写一些可装载的业务逻辑模块来作为业务逻辑，来实现业务功能。这里提到的可装载的业务逻辑模块是用户编写的，可以在不中断系统运行的情况下动态加载或卸载业务处理模块。

工作单元封装了网络层、数据库、内部数据库以及日志等一些底层功能，为业务逻辑提供了运行环境、系统资源和调用接口。这样金融业务的开发者可以把精力放在业务逻辑的开发上，而不需要关心网络和数据处理等系统功能细节。

业务逻辑和工作单元开发完成以后，可以像搭积木一样，通过配置文件任一组合不同的业务逻辑以及工作单元，从而实现不同的业务需求。

图2示出了本发明实施例三提供的金融系统的层次结构图。

图中的IB-kernel是整个系统的最底层，用于支撑整个系统的运行，这一层不是本发明实施例的创新点，因此其运行方式和原理不在此详述。

图中的IB-Engine分为若干个中间引擎如队列引擎、数据库引擎、内存数据库引擎以及日志引擎，这一层就相当于上文提到的工作单元。指的注意的是整个系统有多个工作单元，每个工作单元支持的应用程序可能存在不同，每个工作单元自身的系统程序以及封装的接口也可能存在不同。

图中的脚本引擎，可以为业务逻辑提供执行环境。

图中的业务脚本即上文提到的业务逻辑，用于处理具体的金融交易问题。

图3示出了本发明实施例三提供的金融系统的逻辑结构图。本金融系统支持在Linux及Windows上运行。本发明实施例的交易平台,都是以一个个工作单元的形式存在,每个工作单元是一个独立的线程,每个工作单元上有多个业务逻辑来执行任务,每个业务逻辑都是由事件驱动的。每个工作单元有一个Listener端点和若干个Connector端点。Listener用于接收客户端的请求，并根据请求的业务逻辑名把请求分派到内部的工作单元上。每个工作单元可以通过Connector连接到其他工作上，业务逻辑可以通过Connector请求其他工作单元上的业务逻辑。

图4示出了本发明实施例三提供的金融系统的开发方法S701的具体实现流程。详述如下：

在S401中，读取配置文件。

在本发明实施例中，配置文件是YAML格式的配置文件。YAML(另一种标记语言)是一种直观的能够被计算机识别的数据序列化格式，它的可读性强，容易被人阅读且容易和脚本语言交互，常用来表达资料序列。

在本发明实施例中，在系统启动时，读取YAML格式的配置文件。

在S402中，根据配置文件创建工作单元，工作单元为业务逻辑提供网络层、数据库以及日志接口。

在本发明实施例中，系统启动时，会首先读取当前目录下ison.yaml配置文件，根据配置文件的内容创建工作单元。配置文件格式如下：

在S403中，根据配置文件创建业务逻辑，创建业务逻辑包括：创建Javascript或C++脚本文件。

在本发明实施例中，处理金融业务的程序是由Javascript或C++脚本文件编写的。

在S702中，接收客户端发送的业务请求。

在本发明实施例中，系统接收来自客户端发送的金融交易业务请求，在后续的流程中，系统会根据这个业务请求选择合适的工作单元和业务逻辑。在本发明实施例中，工作单元在S501步骤中直接接收客户端的业务请求。每个工作单元有一个Listener端点和若干个Connector端点。Listener用于接收客户端的请求，并根据请求的业务逻辑名把请求分派到内部的工作单元上。每个工作单元可以通过Connector连接到其他工作上，业务逻辑可以通过Connector请求其他工作单元上的业务逻辑。

在S703中，调用业务逻辑，使业务逻辑运行在工作单元中，并对业务请求进行处理，生成处理结果。

客户端发送的业务请求中，包含需要调用的业务逻辑名。工作单元接收到业务请求后，会根据业务逻辑名，分析出需要调用哪些业务逻辑。上文介绍过工作单元作为底层系统为业务逻辑提供运行环境，业务逻辑运行在工作单元基础之上。

在本发明实施例中，有些业务请求通过工作单元调用一个业务逻辑就可以完成，然而也有很多业务请求需要调用多个业务逻辑才可以完成。因此对于那些调用多个业务逻辑才可以完成的业务请求，工作单元需要组合多个业务逻辑并生成一个完整的业务执行逻辑。

在S704中，通过完整业务执行逻辑，处理业务请求，生成处理结果。

在S705中，将处理结果发送给客户端。

实施例四：

本实施例与实施例二的区别在于，本实施例没有转运代理，因此本实施例的系统只能将一个工作单元上的与订阅主题相同的待发送消息推送给客户端。

图8示出了本发明实施例四提供的金融系统的开发方法的实现流程，详述如下：

在S801中，建立工作单元以及业务逻辑。

为了更好的解决金融领域需要处理海量交易数据的问题，本发明实施例开发出了一个金融交易系统，为分布式环境下解决大型复杂的集群化应用提供灵活和易用的平台。本系统最主要的两个概念，一个是工作单元，另一个是业务逻辑。

业务逻辑是开发人员为实现某些金融交易功能开发的应用程序，开发人员可以调用一些业务系统中已经存在的API函数(应用程序编程接口函数)作为业务逻辑，来实现业务功能。也可以自己编写一些可装载的业务逻辑模块来作为业务逻辑，来实现业务功能。这里提到的可装载的业务逻辑模块是用户编写的，可以在不中断系统运行的情况下动态加载或卸载业务处理模块。

工作单元封装了网络层、数据库、内部数据库以及日志等一些底层功能，为业务逻辑提供了运行环境、系统资源和调用接口。这样金融业务的开发者可以把精力放在业务逻辑的开发上，而不需要关心网络和数据处理等系统功能细节。

业务逻辑和工作单元开发完成以后，可以像搭积木一样，通过配置文件任一组合不同的业务逻辑以及工作单元，从而实现不同的业务需求。

图2示出了本发明实施例四提供的金融系统的层次结构图。

图中的IB-kernel是整个系统的最底层，用于支撑整个系统的运行，这一层不是本发明实施例的创新点，因此其运行方式和原理不在此详述。

图中的IB-Engine分为若干个中间引擎如队列引擎、数据库引擎、内存数据库引擎以及日志引擎，这一层就相当于上文提到的工作单元。指的注意的是整个系统有多个工作单元，每个工作单元支持的应用程序可能存在不同，每个工作单元自身的系统程序以及封装的接口也可能存在不同。

图中的脚本引擎，可以为业务逻辑提供执行环境。

图中的业务脚本即上文提到的业务逻辑，用于处理具体的金融交易问题。

图3示出了本发明实施例四提供的金融系统的逻辑结构图。本金融系统支持在Linux及Windows上运行。本发明实施例的交易平台,都是以一个个工作单元的形式存在,每个工作单元是一个独立的线程,每个工作单元上有多个业务逻辑来执行任务,每个业务逻辑都是由事件驱动的。每个工作单元有一个Listener端点和若干个Connector端点。Listener用于接收客户端的请求，并根据请求的业务逻辑名把请求分派到内部的工作单元上。每个工作单元可以通过Connector连接到其他工作上，业务逻辑可以通过Connector请求其他工作单元上的业务逻辑。

图4示出了本发明实施例四提供的金融系统的开发方法S801的具体实现流程。详述如下：

在S401中，读取配置文件。

在本发明实施例中，配置文件是YAML格式的配置文件。YAML(另一种标记语言)是一种直观的能够被计算机识别的数据序列化格式，它的可读性强，容易被人阅读且容易和脚本语言交互，常用来表达资料序列。

在本发明实施例中，在系统启动时，读取YAML格式的配置文件。

在S402中，根据配置文件创建工作单元，工作单元为业务逻辑提供网络层、数据库以及日志接口。

在本发明实施例中，系统启动时，会首先读取当前目录下ison.yaml配置文件，根据配置文件的内容创建工作单元。配置文件格式如下：

在S403中，根据配置文件创建业务逻辑，创建业务逻辑包括：创建Javascript或C++脚本文件。

在本发明实施例中，处理金融业务的程序是由Javascript或C++脚本文件编写的。

在S802中，接收客户端的订阅主题。

在本发明实施例中，系统在接收到客户端发送的订阅主题之后，会把订阅主题发送到工作单元中。

在S803中，接收单一工作单元发布的消息作为待发送消息。

某一个工作单元会把发布的待发送的消息首先发送到工作单元中。

在S804中，将主题为订阅主题的待发送消息发送给客户端。

工作单元会比对接收到的订阅主题，以及接收到的待发送消息，接着将主题为订阅主题的待发送消息发送给客户端。

实施例五：

图9示出了本发明实施例一提供的金融系统的开发系统结构框图，该系统包括：

创建模块901，用于建立工作单元以及业务逻辑；

第一接收模块902，用于接收客户端发送的业务请求；

转发模块903，用于将业务请求发送到代理队列中；

代理队列模块904，用于按照公平队列方式将业务请求分发到一个以上的工作单元中；

处理模块905，用于调用业务逻辑，使业务逻辑运行在工作单元中，并对业务请求进行处理，生成处理结果；

发送模块906，用于将处理结果发送给客户端。

进一步地，创建单元包括：

读取子模块，用于读取配置文件；

工作单元创建模块，用于根据配置文件创建工作单元，工作单元为业务逻辑提供网络层、数据库以及日志接口；

业务逻辑创建模块，用于根据配置文件创建业务逻辑，创建业务逻辑包括：创建Javascript或C++脚本文件。

进一步地，处理模块包括：

获取子模块，用于获取业务请求；

调用子模块，用于根据业务请求中包含的业务逻辑名，调用业务逻辑，使业务逻辑运行在工作单元中；

组合子模块，用于组合业务逻辑，生成完整业务执行逻辑；

生成子模块，用于通过完整业务执行逻辑，处理业务请求，生成处理结果。

进一步地，调用子模块具体用于：

调用本工作单元的业务逻辑，以及调用其他工作单元的业务逻辑。

进一步地，系统还包括：

第二接收模块，用于接收客户端的订阅主题；

第三接收模块，用于接收各个工作单元发布的消息作为待发送消息；

推送模块，用于将主题为订阅主题的待发送消息发送给客户端。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将系统的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

在本发明所提供的实施例中，应该理解到，所揭露的系统和方法，可以通过其它的方式实现。例如，以上所描述的系统实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，系统或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来。

以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围，均应包含在本发明的保护范围之内。