CN103577251A - 基于事件的互联网计算处理***及方法 - Google Patents

Abstract

本发明公开了一种基于事件的互联网计算处理***及方法。该***包括：事件收集模块，用于将接收到的预定格式的事件消息存储到消息队列中；与消息队列对应的处理模块，用于从消息队列中读取事件消息，根据规则引擎中相应的事件处理规则对事件消息进行处理，最终获取处理结果。借助于本发明的技术方案，能够实时快速地从互联网或物联网的大量事件中获取所需信息。

Description

基于事件的互联网计算处理***及方法

技术领域

本发明涉及计算机技术领域，特别是涉及一种基于事件的互联网计算处理***及方法。

背景技术

在现有技术中，随着互联网的快速发展，互联网上的事件越来越多，如何从这些信息中获取到有价值的信息，如果对这些事件进行处理成了一个专门研究课题。

在互联网上，用户访问一个页面，页面加载开始到页面加载结束，这两个事件，决定了用户的体验，页面加载时间短，那么用户体验就好，可以针对这两类时间再细化分析，具体哪些地区，哪些页面加载时间长，哪些地区哪些页面加载时间短，后续根据这些数据进行改进。再例如，某个新上线的页面，用户访问了多少次，用户在这个页面上停留了多长时间，这些数据都可以根据用户的访问事件来计算出来。

这些事件都有一个共同的特点：数据量非常大，并且时时刻刻都在产生事件，每个事件代表不同的含义，如果要从这些事件背后找到其隐藏的含义，是一个海量数据的处理，单机无法满足要求，需要分布式的架构来实现计算。

在现有技术中，针对上述问题传统的做法是把这些事件记录成话单文件，然后把话单文件存入数据库，然后在数据库的基础上进行统计计算。但是，上述方法具有滞后性，不能够快速地从互联网的大量事件中获取所需信息。

发明内容

本发明提供一种基于事件的互联网计算处理***及方法，以解决现有技术中不能够快速地从互联网或物联网的大量事件中获取所需信息的问题。

本发明提供一种基于事件的互联网计算处理***，包括：事件收集模块，用于将接收到的预定格式的事件消息存储到消息队列中；与消息队列对应的处理模块，用于从消息队列中读取事件消息，根据规则引擎中相应的事件处理规则对事件消息进行处理，最终获取处理结果。

优选地，上述***还包括：与消息队列对应的预处理模块，用于从消息队列中读取事件消息，根据规则引擎中相应的事件预处理规则对事件消息进行整理，并将整理后的事件消息重新存储到消息队列中；处理模块具体用于：从消息队列中读取整理后的事件消息，根据规则引擎中相应的事件处理规则对整理后的事件消息进行再处理，最终获取处理结果。

优选地，上述***还包括：与处理模块对应的事件派发模块，用于将处理模块的处理结果派发到相应的应用中；处理模块还用于：对当前处理的事件消息的状态进行判断，如果事件消息已处理完成，则将事件消息的状态标识为已完成，并触发事件派发模块，如果事件消息还需要进行继续处理，则将事件消息设置为相应状态，并将事件消息继续保存在消息队列中等待下一次处理。

优选地，上述***还包括：管理模块，用于向用户提供界面接口，根据用户的操作对规则引擎中的规则进行配置，并对***进行管理。

优选地，消息队列为分布在多个服务器上的分布式消息队列；预定格式包括：应用编号、事件号、以及一个或多个参数。

本发明还提供了一种基于事件的处理方法，包括：事件收集模块将接收到的预定格式的事件消息存储到消息队列中；与消息队列对应的处理模块从消息队列中读取事件消息，根据规则引擎中相应的事件处理规则对事件消息进行处理，最终获取处理结果。

优选地，处理模块从消息队列中读取事件消息之前，方法还包括：与消息队列对应的预处理模块从消息队列中读取事件消息，根据规则引擎中相应的事件预处理规则对事件消息进行整理，并将整理后的事件消息重新存储到消息队列中；

优选地，处理模块从消息队列中读取事件消息，根据规则引擎中相应的事件处理规则对事件消息进行处理，最终获取处理结果具体包括：处理模块从消息队列中读取整理后的事件消息，根据规则引擎中相应的事件处理规则对整理后的事件消息进行再处理，最终获取处理结果。

优选地，上述方法还包括：处理模块对当前处理的事件消息的状态进行判断，如果事件消息已处理完成，则将事件消息的状态标识为已完成，并触发与处理模块对应的事件派发模块，如果事件消息还需要进行继续处理，则将事件消息设置为相应状态，并将事件消息继续保存在消息队列中等待下一次处理；事件派发模块将处理模块的处理结果派发到相应的应用中。

优选地，上述方法还包括：通过管理模块向用户提供界面接口，并通过管理模块根据用户的操作对规则引擎中的规则进行配置、以及对***进行管理。

优选地，消息队列为分布在多个服务器上的分布式消息队列；预定格式包括：应用编号、事件号、以及一个或多个参数。

本发明有益效果如下：

通过事件收集模块将接收到的事件消息存储到消息队列中，处理模块从消息队列中读取事件消息并根据规则引擎中相应的事件处理规则对事件消息进行处理，最终获取处理结果，解决了现有技术中不能够快速地从互联网的大量事件中获取所需信息的问题，能够实时快速地从互联网的大量事件中获取所需信息。

附图说明

图1是本发明实施例的基于事件的互联网计算处理***的结构示意图；

图2是本发明实施例的基于事件的互联网计算处理***的详细结构示意图；

图3是本发明实施例的基于事件的互联网计算处理***对事件消息进行处理的信令流程图；

图4是本发明实施例的基于事件的互联网计算处理方法的流程图。

具体实施方式

为了解决现有技术中不能够快速地从互联网的大量事件中获取所需信息的问题，本发明提供了一种基于事件的互联网计算处理***及方法，以下结合附图以及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不限定本发明。

***实施例

根据本发明的实施例，提供了一种基于事件的互联网计算处理***，图1是本发明实施例的基于事件的互联网计算处理***的结构示意图，如图1所示，根据本发明实施例的基于事件的互联网计算处理***包括：事件收集模块10、以及处理模块12以下对本发明实施例的各个模块进行详细的说明。

事件收集模块10，用于将接收到的预定格式的事件消息存储到消息队列中；其中，上述预定格式包括：应用编号、事件号、以及一个或多个参数。

与消息队列对应的处理模块12，用于从消息队列中读取事件消息，根据规则引擎中相应的事件处理规则对事件消息进行处理，最终获取处理结果。

优选地，在本发明实施例中，上述***还可以包括：与消息队列对应的预处理模块，用于从消息队列中读取事件消息，根据规则引擎中相应的事件预处理规则对事件消息进行整理，并将整理后的事件消息重新存储到消息队列中；在存在预处理模块的情况下，处理模块12具体用于：从消息队列中读取整理后的事件消息，根据规则引擎中相应的事件处理规则对整理后的事件消息进行再处理，最终获取处理结果。

优选地，在本发明实施例中，上述***还可以包括：

与处理模块12对应的事件派发模块，用于将处理模块12的处理结果派发到相应的应用中；

上述处理模块12还用于：对当前处理的事件消息的状态进行判断，如果事件消息已处理完成，则将事件消息的状态标识为已完成，并触发事件派发模块，如果事件消息还需要进行继续处理，则将事件消息设置为相应状态，并将事件消息继续保存在消息队列中等待下一次处理。

优选地，在本发明实施例中，上述***还可以包括：

管理模块，用于向用户提供界面接口，根据用户的操作对规则引擎中的规则进行配置，并对***进行管理。

需要说明的是，本发明实施例的技术方案不需要使用数据库，仅通过将事件消息存储到消息队列后，由处理模块12或预处理模块对消息队列中的事件消息进行处理，最终获取处理结果。而在本发明实施例中，消息队列可以为分布在多个服务器上的分布式消息队列；而与消息队列相应的预处理模块、处理模块12、以及事件派发模块均设置有多个，分别设置于各个服务器上。也就是说，本发明实施例的处理***可以为基于事件的分布式处理***，其分布式体现在：消息队列采用分布式消息队列，所以针对事件a的处理模块12可以部署在机器1上，针对事件b的处理模块12可以部署在机器2上；不同类型的事件可以分布式部署在不同的机器上。针对不同类型的消息队列，可以通过预处理模块分别存放到不同类型的消息队列中。

以下结合附图，对本发明实施例的上述技术方案进行详细说明。

图2是本发明实施例的基于事件的互联网计算处理***的详细结构示意图，如图2所示，在本发明实施例中，整个***逻辑上分为运行部分（运行服务器）和管理部分（管理服务器，即上述管理模块）。其中运行部分完成事件处理的业务功能，管理部分提供用户接入门户，在门户上可完成处理规则的配置。在实际应用中，管理部分主要为web门户，完成预处理规则的配置、处理规则的配置（即规则管理）和***管理（即服务器状态观察）、以及运行状态的监控（即事件状态观察）和预处理管理。

运行部分包括事件收集模块、预处理模块、处理模块、规则引擎、事件派发模块、以及消息队列，其中规则引擎和预处理或者处理模块融合运行。

图2中的左边的应用产生各种事件，经过处理***分析以和分布式计算以后把分析的结果提供给右边的应用。以下对图2中运行部分的各个模块进行详细说明。

事件收集模块：***对外开放的接口模块，通过事件收集模块可完成消息的收发、约定格式文件的读取、传输控制协议（TCP）消息的通讯。事件收集模块将接收到的事件消息存放到消息队列中进行待预处理。

预处理模块：从消息队列中获取事件消息，然后依据预处理规则完成对消息的补偿、剔除、和分发等处理，预处理完后消息放入消息队列中待正式处理。

规则引擎：规则引擎通过规则实现各种事件的计算逻辑，而不需要实际固定编程，规则引擎可以使用开源drools。

消息队列：完成事件处理过程中的过程数据的存储，***依靠消息队列完成和外部***的交互，并完成消息内部处理的传递。

事件派发模块：完成将事件消息主动推送到***内部或者***外部的功能。事件派发模块一般和管理模块统一部署，主要将计算到的统计数据发送到外部业务***中。

处理模块：是***的事件核心处理节点，完成***过程数据的处理，包括数据的转换、更改，以及将处理数据触发到事件派发模块。

图3是本发明实施例的基于事件的互联网计算处理***对事件消息进行处理的信令流程图，如图3所示，包括如下处理：

步骤1，应用1产生事件，把事件发送到事件收集模块；

步骤2，事件收集模块接收到事件消息后将消息保存到消息队列中；

步骤3，预处理模块先对消息队列监听，监听自己感兴趣的事件类型；

步骤4，因为预处理模块已经对队列做了监听，所以消息队列收到消息以后会通知预处理模块；

步骤5，预处理进程对消息进行格式化等预处理操作，处理完后继续保存到消息队列中；

步骤6，处理模块也对消息队列做了监听，监听符合自己要求的事件，经过预处理模块处理的事件消息会被处理模块监听到。

步骤7，当消息队列中有处理模块待处理消息时，消息队列以回调函数的方式主动推送到处理模块；

步骤8，处理模块从消息队列中取得消息，并协同规则引擎进行业务处理；

步骤9，处理模块进程对当前处理的消息状态进行判断，如果已经处理结束则由派发进程发送到应用，否则继续保存到消息队列中等待下一个状态的处理。

下面以计算网络页面平均加载时间来详细阐述本发明实施例上述技术方案的具体实施方式。

当用户访问页面的时候，首先触发开始加载页面事件，页面加载结束以后触发加载结束事件，客户端上报的事件格式为：

http://www.xxx.com/abc？app＝a&event＝b&para1＝c&para2＝d&param3＝e，其中，app为应用编号，event为输入的事件号，para为参数名，后面跟参数值。

对原始处理事件转换后以json的格式保存。例如：

针对页面加载需求，Event的取值如下：event=01，页面开始加载；event=02，页面加载结束；event=03，页面加载时长；sessionid唯一表示一个用户；optime表示事件发生的时间；ip表示用户所在的ip地址；pageurl表示具体哪个页面的加载。

用户访问页面时，页面开始加载事件和页面加载结束两个事件都经过事件收集模块保存到消息队列，然后由预处理模块处理。

预处理模块收到页面开始加载事件以后，先保存不处理，等页面加载结束事件触发以后，预处理模块会查找同一个用户sessionid，同一个应用app，同一个页面pageurl，对应的页面开始加载时间，并把两个操作时间optime相减，得到该用户的访问该页面时的页面加载时间（上述处理过程即预处理模块对事件消息进行整理的过程）。

经过预先处理以后形成新的事件，事件类型变成event=03，页面加载时长事件，预处理模块把该事件保存到消息队列中。处理模块监听event=03的事件，当收到event=03的事件以后，处理模块该页面平均加载时间，具体计算步骤如下：

收到event=03的事件，放入到先进先出（FIFO）队列中，并记录队列中所有事件的加载时间总和以及事件总个数，***到队列尾部，该事件的加载时间加入到总加载时间上，并把队列的事件数目加1，该队列中只保留5分钟的时间（该5分钟可以配置），判断队首的时间是否超过***时间5分钟，如果超过5分钟的事件，则从队列首部去掉该事件，该被去掉的事件的加载时间从总加载时间中减去，并把队列的事件数目减1，再继续判断队首的事件时间是否超过5分钟，如果超过也从队首中去掉，该被去掉的事件的加载时间从总加载时间中减去，并把队列的事件数目减1，直到没有符合要求的事件。并根据实时动态变化的队列里面的总加载时间和总时间数，计算平均加载时间。实时计算的结果通过事件派发模块传递给需要的应用程序展示。

需要说明的是，这里只是举了个例子阐述详细的实现方法，如果不是计算平均加载时间，是计算其他的求和，计算事件先后顺序，这些都是可以通过规则引擎来配置这些逻辑。

综上所述，借助于本发明实施例的上述技术方案，通过事件收集模块将接收到的事件消息存储到消息队列中，处理模块从消息队列中读取事件消息并根据规则引擎中相应的事件处理规则对事件消息进行处理，最终获取处理结果，解决了现有技术中不能够快速地从互联网大量事件中获取所需信息的问题，能够实时快速地从互联网的大量事件中获取所需信息。

方法实施例

根据本发明的实施例，提供了一种基于事件的互联网计算处理方法，图4是本发明实施例的基于事件的互联网计算处理方法的流程图，如图4所示，根据本发明实施例的基于事件的互联网计算处理方法包括如下处理：

步骤401，事件收集模块将接收到的预定格式的事件消息存储到消息队列中；上述预定格式包括：应用编号、事件号、以及一个或多个参数。

步骤402，与消息队列对应的处理模块从消息队列中读取事件消息，根据规则引擎中相应的事件处理规则对事件消息进行处理，最终获取处理结果。

在步骤402中，处理模块从消息队列中读取事件消息之前，与消息队列对应的预处理模块从消息队列中读取事件消息，根据规则引擎中相应的事件预处理规则对事件消息进行整理，并将整理后的事件消息重新存储到消息队列中；

执行了上述步骤后，处理模块从消息队列中读取整理后的事件消息，根据规则引擎中相应的事件处理规则对整理后的事件消息进行再处理，最终获取处理结果。

优选地，处理模块可以对当前处理的事件消息的状态进行判断，如果事件消息已处理完成，则将事件消息的状态标识为已完成，并触发与处理模块对应的事件派发模块，如果事件消息还需要进行继续处理，则将事件消息设置为相应状态，并将事件消息继续保存在消息队列中等待下一次处理；事件派发模块将处理模块的处理结果派发到相应的应用中。

优选地，在本发明实施例中，可以通过管理模块向用户提供界面接口，并通过管理模块根据用户的操作对规则引擎中的规则进行配置、以及对***进行管理。

需要说明的是，本发明实施例的技术方案不需要使用数据库，仅通过将事件消息存储到消息队列后，由处理模块或预处理模块对消息队列中的事件消息进行处理，最终获取处理结果。而在本发明实施例中，消息队列可以为分布在多个服务器上的分布式消息队列；而与消息队列相应的预处理模块、处理模块、以及事件派发模块均设置有多个，分别设置于各个服务器上。也就是说，本发明实施例的处理***可以为基于事件的分布式处理***，其分布式体现在：消息队列采用分布式消息队列，所以针对事件a的处理模块可以部署在机器1上，针对事件b的处理模块可以部署在机器2上；不能类型的事件可以分布式部署在不同的机器上。针对不同类型的消息队列，可以通过预处理模块分别存放到不同类型的消息队列中。

以下结合附图，对本发明实施例的上述技术方案进行详细说明。

图2是本发明实施例的基于事件的互联网计算处理***事件的互联网计算处理***的详细结构示意图，如图2所示，在本发明实施例中，整个***逻辑上分为运行部分（运行服务器）和管理部分（管理服务器，即上述管理模块）。其中运行部分完成事件处理的业务功能，管理部分提供用户接入门户，在门户上可完成处理规则的配置。在实际应用中，管理部分主要为web门户，完成预处理规则的配置、处理规则的配置（即规则管理）和***管理（即服务器状态观察）、以及运行状态的监控（即事件状态观察）和预处理管理。

运行部分包括事件收集模块、预处理模块、处理模块、规则引擎、事件派发模块、以及消息队列，其中规则引擎和预处理或者处理模块融合运行。

图2中的左边的应用产生各种事件，经过处理***分析以和分布式计算以后把分析的结果提供给右边的应用。以下对图2中运行部分的各个模块进行详细说明。

事件收集模块：***对外开放的接口模块，通过事件收集模块可完成消息的收发、约定格式文件的读取、传输控制协议（TCP）消息的通讯。事件收集模块将接收到的事件消息存放到消息队列中进行待预处理。

预处理模块：从消息队列中获取事件消息，然后依据预处理规则完成对消息的补偿、剔除、和分发等处理，预处理完后消息放入消息队列中待正式处理。

规则引擎：规则引擎通过规则实现各种事件的计算逻辑，而不需要实际固定编程，规则引擎可以使用开源drools。

消息队列：完成事件处理过程中的过程数据的存储，***依靠消息队列完成和外部***的交互，并完成消息内部处理的传递。

事件派发模块：完成将事件消息主动推送到***内部或者***外部的功能。事件派发模块一般和管理模块统一部署，主要将计算到的统计数据发送到外部业务***中。

处理模块：是***的事件核心处理节点，完成***过程数据的处理，包括数据的转换、更改，以及将处理数据触发到事件派发模块。

图3是本发明实施例的基于事件的互联网计算处理***对事件消息进行处理的信令流程图，如图3所示，包括如下处理：

步骤1，应用1产生事件，把事件发送到事件收集模块；

步骤2，事件收集模块接收到事件消息后将消息保存到消息队列中；

步骤3，预处理模块先对消息队列监听，监听自己感兴趣的事件类型；

步骤4，因为预处理模块已经对队列做了监听，所以消息队列收到消息以后会通知预处理模块；

步骤5，预处理进程对消息进行格式化等预处理操作，处理完后继续保存到消息队列中；

步骤6，处理模块也对消息队列做了监听，监听符合自己要求的事件，经过预处理模块处理的事件消息会被处理模块监听到。

步骤7，当消息队列中有处理模块待处理消息时，消息队列以回调函数的方式主动推送到处理模块；

步骤8，处理模块从消息队列中取得消息，并协同规则引擎进行业务处理；

步骤9，处理模块进程对当前处理的消息状态进行判断，如果已经处理结束则由派发进程发送到应用，否则继续保存到消息队列中等待下一个状态的处理。

下面以计算网络页面平均加载时间来详细阐述本发明实施例上述技术方案的具体实施方式。

当用户访问页面的时候，首先触发开始加载页面事件，页面加载结束以后触发加载结束事件，客户端上报的事件格式为：

http://www.xxx.com/abc?app=a&event=b&para1=c&para2=d&param3=e，其中，app为应用编号，event为输入的事件号，para为参数名，后面跟参数值。

对原始处理事件转换后以json的格式保存。例如：

针对页面加载需求，Event的取值如下：event=01，页面开始加载；event=02，页面加载结束；event=03，页面加载时长；sessionid唯一表示一个用户；optime表示事件发生的时间；ip表示用户所在的ip地址；pageurl表示具体哪个页面的加载。

用户访问页面时，页面开始加载事件和页面加载结束两个事件都经过事件收集模块保存到消息队列，然后由预处理模块处理。

预处理模块收到页面开始加载事件以后，先保存不处理，等页面加载结束事件触发以后，预处理模块会查找同一个用户sessionid，同一个应用app，同一个页面pageurl，对应的页面开始加载时间，并把两个操作时间optime相减，得到该用户的访问该页面时的页面加载时间（上述处理过程即预处理模块对事件消息进行整理的过程）。

经过预先处理以后形成新的事件，事件类型变成event=03，页面加载时长事件，预处理模块把该事件保存到消息队列中。处理模块监听event=03的事件，当收到event=03的事件以后，处理模块该页面平均加载时间，具体计算步骤如下：

收到event=03的事件，放入到先进先出（FIFO）队列中，并记录队列中所有事件的加载时间总和以及事件总个数，***到队列尾部，该事件的加载时间加入到总加载时间上，并把队列的事件数目加1，该队列中只保留5分钟的时间（该5分钟可以配置），判断队首的时间是否超过***时间5分钟，如果超过5分钟的事件，则从队列首部去掉该事件，该被去掉的事件的加载时间从总加载时间中减去，并把队列的事件数目减1，再继续判断队首的事件时间是否超过5分钟，如果超过也从队首中去掉，该被去掉的事件的加载时间从总加载时间中减去，并把队列的事件数目减1，直到没有符合要求的事件。并根据实时动态变化的队列里面的总加载时间和总时间数，计算平均加载时间。实时计算的结果通过事件派发模块传递给需要的应用程序展示。

需要说明的是，这里只是举了个例子阐述详细的实现方法，如果不是计算平均加载时间，是计算其他的求和，计算事件先后顺序，这些都是可以通过规则引擎来配置这些逻辑。

综上所述，借助于本发明实施例的上述技术方案，通过事件收集模块将接收到的事件消息存储到消息队列中，处理模块从消息队列中读取事件消息并根据规则引擎中相应的事件处理规则对事件消息进行处理，最终获取处理结果，解决了现有技术中不能够快速地从互联网的大量事件中获取所需信息的问题，能够实时快速地从互联网的大量事件中获取所需信息。

尽管为示例目的，已经公开了本发明的优选实施例，本领域的技术人员将意识到各种改进、增加和取代也是可能的，因此，本发明的范围应当不限于上述实施例。

应当注意的是，在本发明的控制器的各个部件中，根据其要实现的功能而对其中的部件进行了逻辑划分，但是，本发明不受限于此，可以根据需要对各个部件进行重新划分或者组合，例如，可以将一些部件组合为单个部件，或者可以将一些部件进一步分解为更多的子部件。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器（DSP）来实现根据本发明实施例的控制器中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序（例如，计算机程序和计算机程序产品）。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (10)

1.一种基于事件的互联网计算处理***，其特征在于，包括：

事件收集模块，用于将接收到的预定格式的事件消息存储到消息队列中；

与所述消息队列对应的处理模块，用于从所述消息队列中读取所述事件消息，根据规则引擎中相应的事件处理规则对所述事件消息进行处理，最终获取处理结果。

2.如权利要求1所述的***，其特征在于，所述***还包括：

与所述消息队列对应的预处理模块，用于从所述消息队列中读取所述事件消息，根据所述规则引擎中相应的事件预处理规则对所述事件消息进行整理，并将整理后的事件消息重新存储到所述消息队列中；

所述处理模块具体用于：从所述消息队列中读取所述整理后的事件消息，根据所述规则引擎中相应的事件处理规则对所述整理后的事件消息进行再处理，最终获取处理结果。

3.如权利要求1或2所述的***，其特征在于，所述***还包括：

与所述处理模块对应的事件派发模块，用于将所述处理模块的所述处理结果派发到相应的应用中；

所述处理模块还用于：对当前处理的事件消息的状态进行判断，如果所述事件消息已处理完成，则将所述事件消息的状态标识为已完成，并触发所述事件派发模块，如果所述事件消息还需要进行继续处理，则将所述事件消息设置为相应状态，并将所述事件消息继续保存在所述消息队列中等待下一次处理。

4.如权利要求1所述的***，其特征在于，所述***还包括：

管理模块，用于向用户提供界面接口，根据用户的操作对所述规则引擎中的规则进行配置，并对***进行管理。

5.如权利要求1所述的***，其特征在于，

所述消息队列为分布在多个服务器上的分布式消息队列；

所述预定格式包括：应用编号、事件号、以及一个或多个参数。

6.一种基于事件的互联网计算处理方法，其特征在于，包括：

事件收集模块将接收到的预定格式的事件消息存储到消息队列中；

与所述消息队列对应的处理模块从所述消息队列中读取所述事件消息，根据规则引擎中相应的事件处理规则对所述事件消息进行处理，最终获取处理结果。

7.如权利要求6所述的方法，其特征在于，

所述处理模块从所述消息队列中读取所述事件消息之前，所述方法还包括：与所述消息队列对应的预处理模块从所述消息队列中读取所述事件消息，根据所述规则引擎中相应的事件预处理规则对所述事件消息进行整理，并将整理后的事件消息重新存储到所述消息队列中；

所述处理模块从所述消息队列中读取所述事件消息，根据规则引擎中相应的事件处理规则对所述事件消息进行处理，最终获取处理结果具体包括：所述处理模块从所述消息队列中读取所述整理后的事件消息，根据所述规则引擎中相应的事件处理规则对所述整理后的事件消息进行再处理，最终获取处理结果。

8.如权利要求6或7所述的方法，其特征在于，所述方法还包括：

所述处理模块对当前处理的事件消息的状态进行判断，如果所述事件消息已处理完成，则将所述事件消息的状态标识为已完成，并触发与所述处理模块对应的事件派发模块，如果所述事件消息还需要进行继续处理，则将所述事件消息设置为相应状态，并将所述事件消息继续保存在所述消息队列中等待下一次处理；

所述事件派发模块将所述处理模块的所述处理结果派发到相应的应用中。

9.如权利要求6所述的方法，其特征在于，所述方法还包括：

通过管理模块向用户提供界面接口，并通过管理模块根据用户的操作对所述规则引擎中的规则进行配置、以及对***进行管理。

10.如权利要求6所述的方法，其特征在于，

所述消息队列为分布在多个服务器上的分布式消息队列；

所述预定格式包括：应用编号、事件号、以及一个或多个参数。

Images