CN101964763B - 消息处理方法 - Google Patents

Abstract

本发明公开了一种消息处理方法，包括以下步骤：S1、客户端把要进行异步处理或离线处理的消息路由到对应的服务端；S2、服务端接收所述消息，然后分析其中的消息来源参数，生成可在控制反转IOC容器中提取的关系名称；S3、通过所述关系名称从所述IOC容器中提取与消息对应的消息处理器；S4、在各自的消息处理器中实现对消息的处理。本发明提供了一个通用的框架，对消息进行分流和异步处理，并且使服务端能够支持针对不同的消息动态地选择相应的插件分别进行处理。

Description

消息处理方法

技术领域

本发明涉及计算机技术领域，特别涉及一种消息分发及性能调优技术中的消息处理方法。

背景技术

在大访问量、高并发的大型网站中，Web服务器的线程消耗是非常严重的，线程资源十分保贵，如何提高线程利用率、提高请求的响应能力常常是网站性能优化的关键点。但在系统中又常常会有一些高并发、高耗时、低实时性的操作，这些操作的结果对于网站用户来说并不需要及时反馈，但是如果网页等待这些同步操作返回，则对线程占用和响应都有严重的影响，减少服务的吞吐量。这样，如何分流这些消息，进行异步处理就变得重要了。异步调用框架就提供了一个通用的模型来处理这样的调用。

现有方案一：使用线程池对耗时操作进行异步处理。把一个需要执行的操作交给线程池，线程池自己负责线程的创建、分配和销毁。通过使用线程池可以对高消耗的操作进行优化，从而提高系统的处理能力和吞吐量。其缺陷是：线程池仍然是消耗本机线程，在高并发的情况下对CPU和内存消耗非常严重，虽然可以通过修改配置提高线程数，但是对本机资源的消耗是无法有效解决的。

现有方案二：使用消息队列(MSMQ)异步处理高消耗的操作。通过使用消息队列可以把待处理的消息路由到本机或者别的机器上的另外一个进程进行处理。这种方式提供更好的资源扩展，通过把消息路由到别的机器进行处理，可以降低对本机资源的消耗，同时消息队列所提供的异步和离线机制可以更好的提高主程序的响应能力。消息队列的离线机制也有效保障了消息传递的可靠性。其缺陷是：消息队列本身没有合适的可编程机制，支持针对不同的消息处理应用相对应的插件进行处理的机制，以及针对不同消息的按需的灵活路由，需要在此基础上进行扩展。

发明内容

(一)要解决的技术问题

本发明要解决的技术问题是：如何提供一个通用的框架，对消息进行分流和异步处理，并且使服务端能够支持针对不同的消息动态地选择相应的插件分别进行处理。

(二)技术方案

为解决上述技术问题，本发明提供了一种消息处理方法，其特征在于，包括以下步骤：

S1：客户端把要进行异步处理或离线处理的消息路由到对应的服务端；

S2：服务端接收所述消息，然后分析其中的消息来源参数，生成可在反转控制IOC容器中提取的关系名称；

S3：通过所述关系名称从所述IOC容器中提取与消息对应的消息处理器；

S4：在各自的消息处理器中实现对消息的处理。

其中，步骤S1具体包括：

S11：客户端把要进行异步处理或离线处理的消息写入微软消息队列MSMQ；

S12：Windows操作系统根据服务端提供的服务地址，把消息自动路由到服务端。

其中，步骤S1中消息队列的写入操作应用Windows通信基础WCF来处理。

其中，步骤S2中生成可在反转控制IOC容器中提取的关系名称具体方式为：根据事先在IOC容器中注册的消息来源参数与消息处理器的对应关系提取关系名称。

其中，在步骤S2中，通过所述服务端提供的消息服务接口接收所述消息。

其中，消息接口中的参数包括：消息标识和消息来源标识，所述消息来源标识包括：客户端标识、服务标识及服务的版本ID。

其中，在步骤S2中，所述消息处理器通过统一的接口被调用。

其中，在步骤S4中，对消息的处理包括对外部服务的调用、对数据库的操作以及进行日志记录。

(三)有益效果

本发明通过综合应用MSMQ、WCF、IOC容器和巧妙的接口设计，我们开发出了一个可以支持异步处理消息、具有自动选择插件进行消息处理功能的通用的异步调用方法。通过应用此方法可以把消息的处理路由给别的进程或者别的服务器进行处理，能够指定不同的服务地址和部署更多的服务器进行处理，从而可以支持大量的消息处理任务，进而大大地优化网站或服务的性能，提高该网站或服务的吞吐量和降低响应时间，更有效地利用服务器资源。

附图说明

图1是本发明的一种消息处理方法流程图；

图2是实现本发明的消息处理方法的客户端服务端框架结构图；

图3是本发明实施例的消息处理时序图。

具体实施方式

为使本发明的目的、内容、和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

本发明的整体思路是：设计一个分布式调用框架，分为客户端调用和服务端处理。

如图1所示，本发明的步骤包括：

步骤S 1，客户端把要进行异步或离线处理的消息写入MSMQ(MicroSoft Message Queue，微软消息队列)，Windows操作系统根据服务端提供的服务地址，把消息自动路由到服务端。

步骤S2，服务端接收来自于消息队列的消息，然后分析其中的消息来源参数，生成可在IOC(Inversion of Control，反转控制)容器中提取的关系名称。

步骤S3，服务端通过所述关系名称从所述IOC容器中提取与消息对应的消息处理器。

步骤S4，在各自的消息处理器中实现对消息的处理，包括对外部服务的调用，数据库的操作，日志记录等。

其中，消息队列的写入和提取，以及服务端的并发控制等相关网络问题通过应用微软的WCF(Windows CommunicationFoundation，Windows通信基础)技术进行统一处理。

图2示出了实现本发明方法的框架结构示意图，图中示出了客户端1和客户端2分别通过各自的消息来源参数source和消息标识identity来调用服务，具体通过source中的serviceName在分组中获取要调用服务的地址address，调用服务采用上述的WCF技术将各自的消息放入消息队列中。服务端获取消息队列后，根据消息来源参数和消息标识从IOC容器中选择正确的处理器来处理消息。具体步骤结合时序图进行描述。

如图3所示，为消息处理时序图。

上述步骤S1具体包括：

步骤S 11，客户端通过WCF把需要处理的消息写入本地的消息队列MSMQ。因为应用了微软的WCF，客户端把消息写入队列，服务端获取队列中的消息均被表现为对服务接口的调用和服务接口的实现处理。所以这里所谓的把消息写入消息队列，实际上是对服务端提供的一个消息服务接口进行调用。本实施例中，消息服务接口IServiceInvoker定义如下表1所示：

表1服务端提供的服务接口定义

上述接口定义中，参数source表示消息来源的标识，用于对消息进行标记。其格式为：“clientName-serviceName-versionID”

clientName表示客户端调用方的一个标识，如客户端的某个服务或方法，可自定义。

serviceName表示调用了服务端的消息处理器接口的哪个具体实现。

versionID表示服务端消息处理接口的具体实现的哪个版本，它与serviceName联合决定使用的具体的消息处理器。

例如：若消息的格式为“Register-MailCallService-1.0”，则Registe可以表示在注册的过程中调用了异步服务；MailCallService-1.0表示调用了服务端消息处理器接口的1.0版本的MailCallService实现。

其中，参数identity表示需要处理的消息内容或者消息标识，是客户端和服务端约定的参数。

步骤S12，Windows操作系统根据服务端提供的服务地址，把消息自动路由到服务端。

因为消息队列的应用是通过WCF实现，WCF表现为服务端提供服务，客户端调用服务；而服务端提供的服务为所有调用方都提供了一个服务地址，客户端通过指定该服务地址，本地消息队列中的消息便可以自动地路由到服务地址所提供的服务的消息队列中。服务地址的例子如下：

net.msmq://192.168.200.13/private/ServiceInvokerProvider

该服务地址表明，处理消息的服务器为“192.168.200.13”；队列为私有队列“ServiceInvokerProvider”；net.msmq表明应用了WCF的NetMsmqBinding邦定来处理服务消息。

服务端从消息队列中获取消息是由WCF进行监听，服务端的消息队列中接收到消息后，WCF便会把消息提取出来并且路由给提供服务的接口，服务接口的实现便可以接收到该消息，以进行业务处理，例如对外部服务的调用，数据库的操作，日志记录等。

服务端如何并发提取消息或者其它事务问题，均由WCF内部管理实现，我们只需要进行相应的配置便可以控制消息队列中消息的处理频率等问题。

步骤S2采用了处理消息的插件机制实现。如上所述，在服务端的接口实现中已经能获取到从客户端传递过来的消息(source和identity)，但如何让服务端自动选择正确的消息处理器来处理对应的消息？在这里引入了IOC容器，同时指定一个专门用于处理消息的统一的消息处理接口，该接口定义如下表2所示：

表2消息处理接口定义

上述定义中，Call方法的两个参数实质上与IServiceInvoker对外服务接口的Invoke方法的两个对应参数相同。但IServiceInvoker.Invoke方法如何知道该把消息发送给哪个ICallService接口实现呢。在这里就引入的IOC容器，本实施例中，IOC容器使用了开源项目Castle的Windsor容器。

IOC容器的作用是：先为某个接口向容器中注册一些具体实现，本实施例中采用配置文件的方式实现注册，配置文件记录了处理接口、处理接口的具体实现以及它们之前的关系名称。这个关系名称定位了消息处理器。IOC容器在初始化的时候会读取配置文件，在运行时动态提取接口的具体实现时便可以通过该关系名称进行动态提取。比如下表3中向容器注册的具体实现为：

表3配置文件中的注册信息部分

这里向容器注册了两个具体的ICallService接口的实现，索引服务IndexCallService和邮件服务MailCallService，并且为这个关系定义了对应的关系名称，关系名称的命名规则为“ICallService.{serviceName}-{versionID}”，其中{serviceName}和{versionID}即为客户端调用IServiceInvoker.Call方法时所使用的source参数的serviceName和versionID。前面说过这个参数格式中的这两个部分决定了选择哪个具体的消息处理接口ICallService。

步骤S3中，通过IOC容器的选择功能，可以轻松实现待处理消息与消息处理器的对应关系，以IOC容器为基础可以实现一个插件机制，为不同的消息类型应用不同的消息处理器，不同的业务应用只需实现自已的ICallService接口并在IOC容器中通过命名进行注册，便可以实现服务在运行时的自动选择。

以下是一个简单的示例，如表4所示，说明了WCF的对外服务接口IServiceInvoker接收到消息后把消息通过IOC容器转发给对应的ICallService消息处理器。

表4从所述IOC容器中提取与消息对应的消息处理器的实现

表4中可看出在服务端提供的消息服务接口IServiceInvoker中统一调用了消息处理接口iCallService.Call，且参数都是消息来源参数source和消息标识identity，在iCallService.Call中，由上述的关系名称就能选择正确的消息处理器进行消息处理，具体根据source参数中的MailCallService-1.0部分(Register-MailCallService-1.0)和ICallService.{MailCallService}-{1.0}选择iCallService接口对应的处理器为MailCallService的1.0版本。选择处理器后即可执行步骤S4，步骤S4中包括对消息的处理包括对外部服务的调用、对数据库的操作以及进行日志记录等。

以上实施方式仅用于说明本发明，而并非对本发明的限制，有关技术领域的普通技术人员，在不脱离本发明的精神和范围的情况下，还可以做出各种变化和变型，因此所有等同的技术方案也属于本发明的范畴，本发明的专利保护范围应由权利要求限定。

Claims (5)

1.一种消息处理方法，其特征在于，包括以下步骤：

S1：客户端把要进行异步处理或离线处理的消息路由到对应的服务端，具体包括：客户端把要进行异步处理或离线处理的消息写入微软消息队列MSMQ；Windows操作系统根据服务端提供的服务地址，把消息自动路由到服务端，消息队列的写入操作应用Windows通信基础WCF来处理；

S2：服务端通过所述服务端提供的消息服务接口接收所述消息，然后分析其中的消息来源参数，生成可在反转控制IOC容器中提取的关系名称；

S3：通过所述关系名称从所述IOC容器中提取与消息对应的消息处理器；

S4：在各自的消息处理器中实现对消息的处理。

2.如权利要求1所述的消息处理方法，其特征在于，步骤S2中生成可在反转控制IOC容器中提取的关系名称具体方式为：根据事先在IOC容器中注册的消息来源参数与消息处理器的对应关系提取关系名称。

3.如权利要求1所述的消息处理方法，其特征在于，消息接口中的参数包括：消息标识和消息来源标识，所述消息来源标识包括：客户端标识、服务标识及服务的版本ID。

4.如权利要求1～3中任一项所述的消息处理方法，其特征在于，在步骤S2中，所述消息处理器通过统一的接口被调用。

5.如权利要求1～3中任一项所述的消息处理方法，其特征在于，在步骤S4中，对消息的处理包括对外部服务的调用、对数据库的操作以及进行日志记录。

Images