一种基于消息中间件的数据处理方法、装置和系统与流程

本发明涉及计算机信息处理领域，具体而言，涉及一种基于消息中间件的数据处理方法、装置和系统。

背景技术：

伴随着近年来互联网技术的发展，使得人们通过网络进行消息交流以及获取消息的需求越来越大，同时，由于用户对网络消息通信需求的提高，保证海量消息的稳定、高效推送成为了网络服务供应商的首要任务。目前通常采用的方式是使用消息中间件传递消息。消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。

现有方式中，提供不同服务的服务器集群与客户端需要提前进行协商调试，确定对应的ip地址以及端口号。客户端使用对应的ip地址以及端口号访问服务器。但这种方式当服务器集群需要维护或扩容时，服务器都要跟客户端进行协商调试，操作繁琐可能会影响用户的使用，导致用户的体验不好，而且维护成本高。

技术实现要素：

本发明旨在解决服务器集群需要维护或扩容时，操作繁琐可能会影响用户的使用，导致用户的体验不好，而且维护成本高的问题。

为了解决上述技术问题，本发明第一方面提出一种基于消息中间件的数据处理方法，方法包括：

一个或多个第一服务器向第二服务器发送注册请求，第二服务器根据所述注册请求为第一服务器返回注册成功信息，并将所述注册成功信息发送至消息中间件服务器；

客户端向所述消息中间件服务器发送业务请求；

所述消息中间件服务器根据所述业务请求以及所述注册成功信息向所述客户端分配第一服务器，将所述业务请求转发至分配的第一服务器。

根据本发明的一种优选实施方式，所述注册请求中包含所述第一服务器的业务类型。

根据本发明的一种优选实施方式，第二服务器根据所述注册请求为第一服务器返回注册成功信息进一步包括：

所述第二服务器为所述第一服务器分配ip地址，端口号，所述第二服务器根据所述注册请求中包含的所述第一服务器的业务类型为所述第一服务器分配业务id。

根据本发明的一种优选实施方式，将所述注册成功信息发送至消息中间件服务器进一步包括：

将分配给所述第一服务器的ip地址，端口号，与业务类型对应的业务id上传到消息中间件服务器，所述消息中间件服务器为kafka服务器。

根据本发明的一种优选实施方式，所述业务请求中包含业务请求的业务类型。

根据本发明的一种优选实施方式，所述消息中间件服务器根据所述业务请求以及所述注册成功信息向所述客户端分配第一服务器进一步包括：

所述消息中间件服务器，接收客户端发送的业务请求，获取所述业务请求的业务类型；

根据所述业务类型与业务id的对应关系，确定对应的业务id；

根据所述业务id为所述业务请求分配第一服务器，将所述业务请求推送至分配的第一服务器。

根据本发明的一种优选实施方式，根据所述业务id为所述业务请求分配第一服务器，将所述业务请求推送至分配的第一服务器进一步包括：

所述第一服务器向所述第二服务器发送的注册请求中包含所述第一服务器的承载能力；

所述第二服务器将所述第一服务器的承载能力上传到所述消息中间件服务器；

所述消息中间件服务器根据所述第一服务器的承载能在以及负载情况进行负载均衡处理，推送所述业务请求。

本发明第二方面提出一种基于消息中间件的数据处理装置，装置包括：

注册上传模块，用于一个或多个第一服务器向第二服务器发送注册请求，第二服务器根据所述注册请求为第一服务器返回注册成功信息，并将所述注册成功信息发送至消息中间件服务器；

业务请求发送模块，用于客户端向所述消息中间件服务器发送业务请求；

业务请求推送模块，用于所述消息中间件服务器根据所述业务请求以及所述注册成功信息向所述客户端分配第一服务器，将所述业务请求转发至分配的第一服务器。

根据本发明的一种优选实施方式，所述注册请求中包含所述第一服务器的业务类型。

根据本发明的一种优选实施方式，第二服务器根据所述注册请求为第一服务器返回注册成功信息进一步包括：

所述第二服务器为所述第一服务器分配ip地址，端口号，所述第二服务器根据所述注册请求中包含的所述第一服务器的业务类型为所述第一服务器分配业务id。

根据本发明的一种优选实施方式，将所述注册成功信息发送至消息中间件服务器进一步包括：

将分配给所述第一服务器的ip地址，端口号，与业务类型对应的业务id上传到消息中间件服务器，所述消息中间件服务器为kafka服务器。

根据本发明的一种优选实施方式，所述业务请求中包含业务请求的业务类型。

根据本发明的一种优选实施方式，所述消息中间件服务器根据所述业务请求以及所述注册成功信息向所述客户端分配第一服务器进一步包括：

所述消息中间件服务器，接收客户端发送的业务请求，获取所述业务请求的业务类型；

根据所述业务类型与业务id的对应关系，确定对应的业务id；

根据所述业务id为所述业务请求分配第一服务器，将所述业务请求推送至分配的第一服务器。

根据本发明的一种优选实施方式，根据所述业务id为所述业务请求分配第一服务器，将所述业务请求推送至分配的第一服务器进一步包括：

所述第一服务器向所述第二服务器发送的注册请求中包含所述第一服务器的承载能力；

所述第二服务器将所述第一服务器的承载能力上传到所述消息中间件服务器；

所述消息中间件服务器根据所述第一服务器的承载能在以及负载情况进行负载均衡处理，推送所述业务请求。

本发明第三方面提出一种第一服务器，包括：

第一发送单元，用于向第二服务器发送注册请求，还用于向消息中间件服务器返回业务结果消息；

第一接收单元，用于接收第二服务器返回的注册成功消息，还用于接收消息中间件服务器推送的客户端发送的业务请求；

第一处理单元，用于处理所述第一接收单元接收的所述业务请求生成业务结果消息，并将所述业务结果消息发送给所述第一发送单元。

根据本发明的一种优选实施方式，所述注册请求中包含所述第一服务器的业务类型。

根据本发明的一种优选实施方式，所述注册请求中还包括该第一服务器的承载能力。

本发明第四方面提出一种第二服务器，包括：

第二接收单元，用于接收第一服务器发送的注册请求；

第二发送单元，用于向第一服务器发送注册成功消息，并将所述注册成功消息上传到消息中间件服务器；

管理单元，用于为所述第一服务器分配ip地址，端口号以及业务id。

本发明第五方面提出一种消息中间件服务器，包括：

第三接收单元，用于接收消息中间件服务器上传的注册成功消息，并将所述注册成功消息中携带的第一服务器的ip地址，端口号，业务id以及承载成立发送到存储单元，还用于接收客户端发送的业务请求，第一服务器返回的业务结果消息；

推送单元，用于解析所述业务请求，获取业务请求中携带的业务类型，根据存储单元存储的业务类型与业务id的对应关系确定所述业务请求对应的第一服务器；

第三发送单元，用于将所述业务请求推送到对应的第一服务器，并将第一服务器返回的业务结果消息发送到对应的客户端。

本发明第六方面提出一种客户端，包括：

第四发送单元，用于向消息中间件服务器发送业务请求，所述业务请求中包含业务类型；

第四接收单元，用于接收所述消息中间件服务器返回的业务结果消息。

本发明第七方面提出一种基于消息中间件的数据处理系统，包括：

存储单元，用于存储计算机可执行程序；

处理单元，用于读取所述存储单元中的计算机可执行程序，以执行所述的基于消息中间件的数据处理方法。

本发明第八方面提出一种计算机可读介质，用于存储计算机可读程序，所述计算机可读程序用于执行所述的基于消息中间件的数据处理方法。

采用该技术方案，通过设置第二服务器对第一服务器进行管理，将第一服务器的注册信息上传到消息中间件，当第一服务器进行维护或扩容时无需再次与客户端进行协商，在用户无感知的情况下进行维护或扩容，提升了用户的使用感受。

附图说明

为了使本发明所解决的技术问题、采用的技术手段及取得的技术效果更加清楚，下面将参照附图详细描述本发明的具体实施例。但需声明的是，下面描述的附图仅仅是本发明的示例性实施例的附图，对于本领域的技术人员来讲，在不付出创造性劳动的前提下，可以根据这些附图获得其他实施例的附图。

图1是现有技术中消息中间件的网络结构示意图；

图2是本发明实施例中基于消息中间件的网络拓扑结构示意图；

图3是本发明实施例中基于消息中间件的数据处理方法的流程示意图；

图4是本发明实施例中基于消息中间件的数据处理装置的结构示意图；

图5是本发明实施例中第一服务器的结构示意图；

图6是本发明实施例中第二服务器的结构示意图；

图7是本发明实施例中消息中间件服务器的结构示意图；

图8是本发明实施例中客户端的结构示意图；

图9是本发明实施例中基于消息中间件的数据处理系统的结构框架示意图；

图10是本发明实施例中计算机可读存储介质的结构示意图。

具体实施方式

现在将参考附图来更加全面地描述本发明的示例性实施例，虽然各示例性实施例能够以多种具体的方式实施，但不应理解为本发明仅限于在此阐述的实施例。相反，提供这些示例性实施例是为了使本发明的内容更加完整，更加便于将发明构思全面地传达给本领域的技术人员。

在符合本发明的技术构思的前提下，在某个特定的实施例中描述的结构、性能、效果或者其他特征可以以任何合适的方式结合到一个或更多其他的实施例中。

在对于具体实施例的介绍过程中，对结构、性能、效果或者其他特征的细节描述是为了使本领域的技术人员对实施例能够充分理解。但是，并不排除本领域技术人员可以在特定情况下，以不含有上述结构、性能、效果或者其他特征的技术方案来实施本发明。

附图中的流程图仅是一种示例性的流程演示，不代表本发明的方案中必须包括流程图中的所有的内容、操作和步骤，也不代表必须按照图中所显示的的顺序执行。例如，流程图中有的操作/步骤可以分解，有的操作/步骤可以合并或部分合并，等等，在不脱离本发明的发明主旨的情况下，流程图中显示的执行顺序可以根据实际情况改变。

附图中的框图一般表示的是功能实体，并不一定必然与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理单元装置和/或微控制器装置中实现这些功能实体。

各附图中相同的附图标记表示相同或类似的元件、组件或部分，因而下文中可能省略了对相同或类似的元件、组件或部分的重复描述。还应理解，虽然本文中可能使用第一、第二、第三等表示编号的定语来描述各种器件、元件、组件或部分，但是这些器件、元件、组件或部分不应受这些定语的限制。也就是说，这些定语仅是用来将一者与另一者区分。例如，第一器件亦可称为第二器件，但不偏离本发明实质的技术方案。此外，术语“和/或”、“及/或”是指包括所列出项目中的任一个或多个的所有组合。

图1是现有技术中消息中间件的网络结构示意图。

如图1所示，消息中间件位于生产者和消费者中间。在这个结构中三者的作用分别是：

生产者，负责进行消息信息的推送，推送给指定的服务器；

消费者，负责通过服务器获取消息的内容；

消息中间件，负责消息的存储，也就是当消费者来不及处理完全部消息的时候，可以在消息中间件之中进行消息内容的缓冲，所以消息中间件也往往被称为消息队列中间件。

生产者可以是各种设备，比如手机、台式计算机、笔记本电脑、pda等等电子设备，当各个设备发送的消息过多的时候，那么一定会引起数据量的暴涨，如果直接将这些消息交给消费者即各种服务器进行处理，那么由于服务器将无法正确处理，将导致消息数据的丢失。消息中间件最大的功能就是进行数据的缓冲操作。通过设置消息中间件，生产者与消费者之间的通信模式转换为异步通信。

但是在这种结构，消费者和生产者之间需要进行协商，确定好对应的ip地址以及端口号，否则消息不能准确的推送到指定的消费者，即服务器。当服务器需要维护或需要扩容时，进行维护的服务器和新增的服务器都需要与生产者进行协商，确保信息不会发送到下线的服务器，或者消息能够分配的新上线的服务器。

为了解决这个问题，本发明提供一种基于消息中间件的数据处理方法，其中网络拓扑结构示意图如图2所示，方法的流程示意图如图3所示，方法包括：

s301，一个或多个第一服务器向第二服务器发送注册请求，第二服务器根据所述注册请求为第一服务器返回注册成功信息，并将所述注册成功信息发送至消息中间件服务器。

在本实施方式中，如图2所示，设置第二服务器，一个或多个第一服务器向第二服务器发送注册请求，注册成功后，第二服务器向第一服务器返回注册成功信息，第一服务器收到注册成功信息后确定注册成功，否则每隔一个申请周期就向第二服务器发送一次注册请求直至收到注册成功信息。申请周期通常设置在50毫秒至500毫秒。

在第一服务器注册成功后，第二服务器还将注册成功信息发送至消息中间件服务器。

在上述技术方案的基础上，进一步地，所述注册请求中包含所述第一服务器的业务类型。

在本实施方式中，第一服务器的注册请求中包含第一服务器的业务类型，比如用于自然语言理解(nlu)，或者用于数据存储等等。

在上述技术方案的基础上，进一步地，将所述注册成功信息发送至消息中间件服务器进一步包括：

将分配给所述第一服务器的ip地址，端口号，与业务类型对应的业务id上传到消息中间件服务器，所述消息中间件服务器为kafka服务器。

在本实施方式中，第二服务器属于管理服务器，设置有ip池、端口号池以及业务id池，根据第一服务器发送的注册请求为第一服务器分配ip地址，端口号以及业务id，比如为nlu服务器分配业务id为1xxx，为数据存储服务器分配业务id为2xxx，其中第一位数对应具体的业务类型，后三位为服务器分配的序号。业务id的形式可以根据需要进行设置。在本实施方式，根据功能不同为服务器划分不同的组别，比如划分为售后组、销售组、咨询组等等。同一组的第一服务器的ip地址与端口号相同，通过业务id对具体服务器进行区分。不同组的第一服务器ip地址和/或端口号不同。

在本实施方式中，第二服务器分配业务id是按第一服务器的注册顺序进行分配，当已分配的第一服务器下线时回收该业务id，重新放入业务id池中，当有新的第一服务器上线时，再该业务id分配给新的第一服务器。

消息中间件服务器的类型可以为activemq、rabbitmq、kafka、rocketmq、zeromq等，在本实施方式中采用kafka服务器。

s302，客户端向所述消息中间件服务器发送业务请求。

在上述技术方案的基础上，进一步地，所述业务请求中包含业务请求的业务类型。

在本实施方式中，客户端的业务请求中包含业务类型，比如业务请求中nlu。业务请求中携带有业务类型，消息中间件就可以将业务请求准确的推送到对应的服务器。

在本实施方式中，客户端的业务请求中还包含有客户端ip地址以及客户端id，当对应的第一服务器处理完客户端发送的业务请求后，通过客户端ip地址以及客户端id返回业务结果消息。

s303，所述消息中间件服务器根据所述业务请求以及所述注册成功信息向所述客户端分配第一服务器，将所述业务请求转发至分配的第一服务器。

在本实施方式中，消息中间件接收客户端发送的业务请求，将业务请求推送到对应的第一服务器进行处理。

在上述技术方案的基础上，进一步地，根据所述业务id为所述业务请求分配第一服务器，将所述业务请求推送至分配的第一服务器进一步包括：

所述第一服务器向所述第二服务器发送的注册请求中包含所述第一服务器的承载能力；

所述第二服务器将所述第一服务器的承载能力上传到所述消息中间件服务器；

所述消息中间件服务器根据所述第一服务器的承载能在以及负载情况进行负载均衡处理，推送所述业务请求。

在本实施方式中，不同的第一服务器承载能力不同，有的服务器承载能力强，有的服务器承载能力弱，如果进行平均分配则承载能力小的服务器可能已经超负荷运转，而承载能力大的服务器仅仅使用了很少的部分。

为此消息中间件要对第一服务器进行负载均衡。第一服务器在第二服务器注册时需要，注册请求中携带有该第一服务器的承载能力，第二服务器将第一服务器的ip地址，端口号，业务id以及承载能力都上传到消息中间件服务器。

消息中间件服务器存储有每一个第一服务器的ip地址，端口号，业务id以及承载能力，还存储有业务类型与业务id的对应关系。当消息中间件服务器接收到客户端发送的业务请求后，从中提取业务类型，根据业务类型查找对应的业务id，最终确定确定分配的第一服务器。比如客户端发送的业务请求中的业务类型为nlu，则对应的业务id为1001,1002,1003等等。消息中间件在进行分配时还记载第一服务器的负载率，根据负载率进行负载均衡，保证每一个第一服务器都不会超负荷运转。负载率的计算方式为：

每次为第一服务器分配一个业务请求则已负载的业务请求数量加1，每次第一服务器返回业务结果消息则已负载的业务请求数量减1。

通过这种方式，每一组的第一服务器的ip地址以及端口号都是固定的，不用再跟客户端进行协商，再进行维护时只需要将进行维护的第一服务器的业务id上传到消息中间件服务器，消息中间件服务器不再向该第一服务器分配业务请求即可。当新的第一服务器上线或者维护好的第一服务器重新上线时，仅需要在第二服务器中进行注册，将新的业务id上传到消息中间件服务器即可。采用本发明的方案第一服务器仅需与客户端进行一次协商，确定好ip地址以及端口号即可，后续的维护及新服务器上线均不用再次协商，做到用户无感知，不会对用户的使用造成影响，提升了用户的使用感受。

图4是本发明实施例中基于消息中间件的数据处理装置的结构示意图，如图4所示，本发明提供一种基于消息中间件的数据处理装置400，包括：

注册上传模块401，用于一个或多个第一服务器向第二服务器发送注册请求，第二服务器根据所述注册请求为第一服务器返回注册成功信息，并将所述注册成功信息发送至消息中间件服务器。

在本实施方式中，设置第二服务器，一个或多个第一服务器向第二服务器发送注册请求，注册成功后，第二服务器向第一服务器返回注册成功信息，第一服务器收到注册成功信息后确定注册成功，否则每隔一个申请周期就向第二服务器发送一次注册请求直至收到注册成功信息。申请周期通常设置在50毫秒至500毫秒。

在第一服务器注册成功后，第二服务器还将注册成功信息发送至消息中间件服务器。

在上述技术方案的基础上，进一步地，所述注册请求中包含所述第一服务器的业务类型。

在本实施方式中，第一服务器的注册请求中包含第一服务器的业务类型，比如用于自然语言理解(nlu)，或者用于数据存储等等。

在上述技术方案的基础上，进一步地，将所述注册成功信息发送至消息中间件服务器进一步包括：

将分配给所述第一服务器的ip地址，端口号，与业务类型对应的业务id上传到消息中间件服务器，所述消息中间件服务器为kafka服务器。

在本实施方式中，第二服务器属于管理服务器，设置有ip池、端口号池以及业务id池，根据第一服务器发送的注册请求为第一服务器分配ip地址，端口号以及业务id，比如为nlu服务器分配业务id为1xxx，为数据存储服务器分配业务id为2xxx，其中第一位数对应具体的业务类型，后三位为服务器分配的序号。在本实施方式，根据功能不同为服务器划分不同的组别，比如划分为售后组、销售组、咨询组等等。同一组的第一服务器的ip地址与端口号相同，通过业务id对具体服务器进行区分。不同组的第一服务器ip地址和/或端口号不同。

在本实施方式中，第二服务器分配业务id是按第一服务器的注册顺序进行分配，当已分配的第一服务器下线时回收该业务id，重新放入业务id池中，当有新的第一服务器上线时，再该业务id分配给新的第一服务器。

消息中间件服务器的类型可以为activemq、rabbitmq、kafka、rocketmq、zeromq等，在本实施方式中采用kafka服务器。

业务请求发送模块402，用于客户端向所述消息中间件服务器发送业务请求。

在上述技术方案的基础上，进一步地，所述业务请求中包含业务请求的业务类型。

在本实施方式中，客户端的业务请求中包含业务类型，比如业务请求中nlu。业务请求中携带有业务类型，消息中间件就可以将业务请求准确的推送到对应的服务器。

在本实施方式中，客户端的业务请求中还包含有客户端ip地址以及客户端id，当对应的第一服务器处理完客户端发送的业务请求后，通过客户端ip地址以及客户端id返回业务结果消息。

业务请求推送模块403，用于所述消息中间件服务器根据所述业务请求以及所述注册成功信息向所述客户端分配第一服务器，将所述业务请求转发至分配的第一服务器。

在本实施方式中，消息中间件接收客户端发送的业务请求，将业务请求推送到对应的第一服务器进行处理。

在上述技术方案的基础上，进一步地，根据所述业务id为所述业务请求分配第一服务器，将所述业务请求推送至分配的第一服务器进一步包括：

所述第一服务器向所述第二服务器发送的注册请求中包含所述第一服务器的承载能力；

所述第二服务器将所述第一服务器的承载能力上传到所述消息中间件服务器；

所述消息中间件服务器根据所述第一服务器的承载能在以及负载情况进行负载均衡处理，推送所述业务请求。

在本实施方式中，不同的第一服务器承载能力不同，有的服务器承载能力强，有的服务器承载能力弱，如果进行平均分配则承载能力小的服务器可能已经超负荷运转，而承载能力大的服务器仅仅使用了很少的部分。

为此消息中间件要对第一服务器进行负载均衡。第一服务器在第二服务器注册时需要，注册请求中携带有该第一服务器的承载能力，第二服务器将第一服务器的ip地址，端口号，业务id以及承载能力都上传到消息中间件服务器。

消息中间件服务器存储有每一个第一服务器的ip地址，端口号，业务id以及承载能力，还存储有业务类型与业务id的对应关系。当消息中间件服务器接收到客户端发送的业务请求后，从中提取业务类型，根据业务类型查找对应的业务id，最终确定确定分配的第一服务器。比如客户端发送的业务请求中的业务类型为nlu，则对应的业务id为1001,1002,1003等等。消息中间件在进行分配时还记载第一服务器的负载率，根据负载率进行负载均衡，保证每一个第一服务器都不会超负荷运转。负载率的计算方式为：

每次为第一服务器分配一个业务请求则已负载的业务请求数量加1，每次第一服务器返回业务结果消息则已负载的业务请求数量减1。

通过这种方式，每一组的第一服务器的ip地址以及端口号都是固定的，不用再跟客户端进行协商，再进行维护时只需要将进行维护的第一服务器的业务id上传到消息中间件服务器，消息中间件服务器不再向该第一服务器分配业务请求即可。当新的第一服务器上线或者维护好的第一服务器重新上线时，仅需要在第二服务器中进行注册，将新的业务id上传到消息中间件服务器即可。采用本发明的方案第一服务器仅需与客户端进行一次协商，确定好ip地址以及端口号即可，后续的维护及新服务器上线均不用再次协商，做到用户无感知，不会对用户的使用造成影响，提升了用户的使用感受。

图5是本发明实施例中第一服务器的结构示意图，如图5所示，第一服务器，包括：

第一发送单元501，用于向第二服务器发送注册请求，还用于向消息中间件服务器返回业务结果消息；

第一接收单元502，用于接收第二服务器返回的注册成功消息，还用于接收消息中间件服务器推送的客户端发送的业务请求；

第一处理单元503，用于处理所述第一接收单元接收的所述业务请求生成业务结果消息，并将所述业务结果消息发送给所述第一发送单元。

在上述技术方案的基础上，进一步地，所述注册请求中包含所述第一服务器的业务类型。

在本实施中，由于同一组的第一服务器的ip地址和端口号都相同，是通过业务类型对应的业务id来区分具体的第一服务器，因此需要在注册请求中携带业务类型。

在上述技术方案的基础上，进一步地，所述注册请求中还包括该第一服务器的承载能力。

在本实施方式中，消息中间件服务器需要对第一服务器进行负载均衡，因此需要知道第一服务器的承载能力。

图6是本发明实施例中第二服务器的结构示意图，如图6所示，一种第二服务器，包括：

第二接收单元601，用于接收第一服务器发送的注册请求；

第二发送单元602，用于向第一服务器发送注册成功消息，并将所述注册成功消息上传到消息中间件服务器；

管理单元603，用于为所述第一服务器分配ip地址，端口号以及业务id。

图7是本发明实施例中消息中间件服务器的结构示意图，如图7所示，消息中间件服务器包括：

第三接收单元701，用于接收消息中间件服务器上传的注册成功消息，并将所述注册成功消息中携带的第一服务器的ip地址，端口号，业务id以及承载成立发送到存储单元，还用于接收客户端发送的业务请求，第一服务器返回的业务结果消息；

推送单元702，用于解析所述业务请求，获取业务请求中携带的业务类型，根据存储单元存储的业务类型与业务id的对应关系确定所述业务请求对应的第一服务器；

第三发送单元703，用于将所述业务请求推送到对应的第一服务器，并将第一服务器返回的业务结果消息发送到对应的客户端。

图8是本发明实施例中客户端的结构示意图，如图8所示，客户端包括：

第四发送单元801，用于向消息中间件服务器发送业务请求，所述业务请求中包含业务类型；

第四接收单元802，用于接收所述消息中间件服务器返回的业务结果消息。

如图9所示，本发明的一个实施例中还公开一种基于消息中间件的数据处理系统，图9显示的基于上下文指代的对话应答系统仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

基于消息中间件的数据处理系统900，包括存储单元920，用于存储计算机可执行程序；处理单元910，用于读取所述存储单元中的计算机可执行程序，以执行本发明各种实施方式的步骤。

在本实施方式中基于消息中间件的数据处理系统900还包括，连接不同系统组件(包括存储单元920和处理单元910)的总线930、显示单元940等。

其中，所述存储单元920存储有计算机可读程序，其可以是源程序或都只读程序的代码。所述程序可以被处理单元910执行，使得所述处理单元910执行本发明各种实施方式的步骤。例如，所述处理单元910可以执行如图3所示的步骤。

所述存储单元920可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(ram)9201和/或高速缓存存储单元9202，还可以进一步包括只读存储单元(rom)9203。所述存储单元920还可以包括具有一组(至少一个)程序模块9205的程序/实用工具9204，这样的程序模块9205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线930可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

基于消息中间件的数据处理系统900也可以与一个或多个外部设备970(例如键盘、显示器、网络设备、蓝牙设备等)通信，使得用户能经由这些外部设备970通过输入/输出(i/o)接口950进行与处理单元910进行交互，还可以通过网络适配器960与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)进行。网络适配器960可以通过总线930与基于消息中间件的数据处理系统900的其它模块通信。应当明白，尽管图中未示出，基于消息中间件的数据处理系统900中可使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。

图10是本发明的一个计算机可读介质实施例的示意图。如图10所示，所述计算机程序可以存储于一个或多个计算机可读介质上。计算机可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储单元(ram)、只读存储单元(rom)、可擦式可编程只读存储单元(eprom或闪存)、光纤、便携式紧凑盘只读存储单元(cd-rom)、光存储单元件、磁存储单元件、或者上述的任意合适的组合。当所述计算机程序被一个或多个数据处理设备执行时，使得该计算机可读介质能够实现本发明的上述方法，即：

s301，一个或多个第一服务器向第二服务器发送注册请求，第二服务器根据所述注册请求为第一服务器返回注册成功信息，并将所述注册成功信息发送至消息中间件服务器；

s302，客户端向所述消息中间件服务器发送业务请求；

s303，所述消息中间件服务器根据所述业务请求以及所述注册成功信息向所述客户端分配第一服务器，将所述业务请求转发至分配的第一服务器。

通过以上的实施方式的描述，本领域的技术人员易于理解，本发明描述的示例性实施例可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本发明实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个计算机可读的存储介质(可以是cd-rom，u盘，移动硬盘等)中或网络上，包括若干指令以使得一台数据处理设备(可以是个人计算机、服务器、或者网络设备等)执行根据本发明的上述方法。

所述计算机可读存储介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读存储介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。可读存储介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、rf等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、c++等，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

综上所述，本发明可以执行计算机程序的方法、装置、电子设备或计算机可读介质来实现。可以在实践中使用微处理单元或者数字信号处理单元(dsp)等通用数据处理设备来实现本发明的一些或者全部功能。

以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，应理解的是，本发明不与任何特定计算机、虚拟装置或者电子设备固有相关，各种通用装置也可以实现本发明。以上所述仅为本发明的具体实施例而已，并不用于限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。