CN102025652B - 服务总线以及消息处理方法 - Google Patents

Abstract

一种服务总线以及消息处理方法，所述消息处理方法包括：接收消息，每一消息包括至少一个服务请求；按预定规则对所述接收的消息进行排序；处理预定数量的已排序的消息中的服务请求；若消息中服务请求在预定的处理时间内均能得到处理结果，则将请求处理结果打包反馈，若消息中服务请求在预定的处理时间内无法全部得到处理结果，则放弃该消息的处理。本发明提供的服务总线应用于电子交易平台时，系统不必完全处理所有消息，当系统繁忙导致处理时间拉长时，有选择的放弃已超时的消息。以避免系统处理效率以及速度的下降，甚至造成崩溃当机。

Description

服务总线以及消息处理方法

技术领域

本发明涉及电子商务交易技术领域，尤其涉及一种应用于电子商务交易平台的服务总线消息处理方法。 

背景技术

目前，大型企业网之间的应用集成服务日益复杂，传统的点对点式的系统集成显得捉襟见肘。为了解决这一问题，人们提出了企业服务总线(enterprise service bus，简称ESB)的概念，即组成企业网的各个子系统以类似于接插件的方式接入一个公共的信息平台，彼此之间相对独立，由调度引擎进行统一的数据调度，以高效整合数据和业务流程。按照著名的IT研究与顾问咨询机构Gartner公司所给的定义，企业服务总线是一种体系结构，利用企业的Web服务、消息中间件、智能路由和转换技术实现，是传统中间技术与XML、Web服务等技术结合的产物，ESB提供了网络中最基本的连接中枢。企业服务总线技术的目标是以标准化的方式实现企业应用集成，完成企业间应用系统的互联、互通和互操作，其中的标准化工作包括连接器标准化、管理标准化、业务消息标准化和消息标准化等。 

ESB的出现改变了传统的软件架构，可以提供比传统中间软件产品更为廉价的解决方案，同时它还可以消除不同应用服务之间的技术差异，让不同的应用服务协调运作，实现了不同服务之间的通信与整合。从功能上看，ESB提供了事件驱动和文档导向的处理模式，以及分布式的管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并提供一系列的标准接口。例如，申请号为“200810227316.9”的中国专利申请公开了一种企业服务总线的实现方法。 

现有的电子商务交易平台，服务总线对服务使用者所提起的消息请求，采用的是兼容并包的处理方式，即无论服务使用者提请多少类别、数量的消息请求，总是进行排队处理。在交易平台尚处于系统压力承受能力之内时，服务总线还能够在有限的处理时间内，返回请求的处理结果。但一旦交易平台由于巨大的访问量以及繁琐的后台处理流程，超出其系统压力承受能力时，服务总线则可能崩溃当机，或者长时间无法返回处理结果。导致系统崩溃当机的直接因素是，消息请求的数量过多，或者消息请求的处理流程过于复杂，而服务总线缺乏必要的自清理能力。例如某一个消息请求，涉及的后台处理流程较繁琐，在系统正常时，尚能较快处理；但系统繁忙时，其处理时间必然被拉长，如果长期不能返回处理结果，该消息请求将总是占据服务总线内部的处理线程，进一步造成系统的混乱以及拥堵。因此需要一种新的消息处理机制以避免上述问题。 

发明内容

本发明解决的问题是提供一种服务总线及其消息处理方法，将其应用于企业电子交易平台时，可以实现对消息处理的时间控制，减轻系统的处理压力，防止系统崩溃当机。 

本发明所述的服务总线，包括： 

消息收发单元，包括多个消息通道，每一消息通道用于接收包括至少一个服务请求的消息，并预定消息处理的时间，若在预定的处理时间内得到消息中所有服务请求的处理结果，则将所述请求处理结果打包反馈； 

消息队列单元，用于从所述多个消息通道接收消息，并按预定规则进行排序； 

处理线程组，用于从所述消息队列单元接收预定数量的已排序的消息； 

请求处理单元，用于从所述处理线程组中获取并处理所述消息中的服务请求，将请求处理结果反馈给消息通道。 

所述消息通道若在预定处理时间内无法得到所有服务请求的处理结果，则丢弃已得到的请求处理结果，并且还包括反馈超时信息的步骤。 

可选的，所述按预定规则进行排序是指按消息接收时间顺序或消息优先级进行排序。所述消息包括至少两个服务请求时；所述服务总线还包括：请求拆分单元，用于将所述消息队列单元接收的消息拆分成服务请求后发送给所述处理线程组。 

一种基于上述服务总线的消息处理方法，包括： 

接收消息，每一消息包括至少一个服务请求； 

按预定规则对所述接收的消息进行排序； 

处理预定数量的已排序的消息中的服务请求； 

若消息中服务请求在预定的处理时间内均能得到处理结果，则将请求处理结果打包反馈，若消息中服务请求在预定的处理时间内无法全部得到处理结果，则放弃该消息的处理。 

所述放弃消息的处理还包括丢弃已得到的请求处理结果以及反馈超时信息。可选的，所述按预定规则进行排序是指按消息接收时间顺序或消息优先级进行排序。若所述消息包括至少两个服务请求时，处理消息中的服务请求前还包括将消息拆分成服务请求。 

与现有技术相比，本发明具有以下优点： 

本发明提供的服务总线应用于电子交易平台时，系统不必完全处理所有消息，当系统繁忙导致处理时间拉长时，有选择的放弃已超时的消息。以避免消息因为无法获得所有请求的处理结果，而总是占用系统资源，导致整个系统处理效率以及速度的下降，甚至造成崩溃当机。 

附图说明

图1是本发明具体实施例的服务总线的内部架构示意图； 

图2是本发明具体实施例的服务总线应用于电子交易平台的示意图； 

图3是本发明具体实施例的消息处理方法流程示意图。 

具体实施方式

本发明具体实施方式的服务总线应用于电子交易平台时，服务使用者在向电子交易平台发起若干服务请求，所述多个服务请求打包成消息的方式输入系统。当服务总线接收到上述消息后，进行排序、请求处理、并反馈给服务使用者。如果在短时间内大量使用者发起服务请求，造成系统繁忙的情况时，服务总线根据超时机制，有选择的反馈处理较快的消息，而放弃处理较慢的消息，以减轻系统压力，防止系统崩溃当机。 

参考图1，本发明具体实施方式的服务总线100，包括： 

消息收发单元110，用于接收多个服务使用者发送的消息，并反馈处理结果，包括多个消息通道，分别为消息通道1、消息通道2……消息通道n；为了减少服务使用者对不同的服务请求分别进行操作，通常在同一次访问内，服务使用者可以提出多个服务请求，而这些服务请求打包形成一个消息的形式发送给服务总线。所述每一消息通道接收包括至少一个服务请求的消息，然后发送给后续单元处理，并预定消息处理的时间。 

消息队列单元120，用于从所述消息通道中接收消息，并且将来自于多个消息接收通道的多个消息，根据预定规则进行排队。所述预定规则可以是时间顺序，例如时间在前的消息比时间在后的消息先处理，所述时间顺序对应于服务使用者提出请求操作的先后顺序，也可以是消息队列单元120接收消息的先后顺序。还可以是优先级顺序，例如所述消息中包括优先级参数，优先级高的消息比优先级低的消息先处理，所述优先级参数可以是电子交易平台根据不同用户的权限制定，也可以结合消息提请时间、服务请求所需调用资源的难易度等信息制定。本实施例中，消息排序的规则以时间顺序为例。 

参考图1，排序后的消息队列分别为消息队列10、消息队列20……消息 队列n0。所述消息队列单元120可以在消息排序前，先将打包的消息拆分成服务请求，此服务请求的数量对应于服务使用者提出的服务请求数量，还可以在消息排序之后再进行上述拆分过程。参考附图1，消息队列10中的消息被拆分成服务请求11，服务请求12，服务请求13，消息队列20中的消息被拆分成服务请求21，服务请求22，服务请求23，……消息队列n0中的消息被拆分成服务请求n1，服务请求n2，服务请求n3，需要说明的是，此例中每一消息被拆分成三个服务请求，只是起示例性，而在具体情况中，每一消息中包括的服务请求数量根据发起此消息的用户端(即服务使用者的具体操作)而定。 

处理线程组130，包括预定数量的处理线程，分别为处理线程1、处理线程2……处理线程n，用于从所述消息队列单元120接收预定数量的已排序的消息；处理线程组130中的处理线程的数量为预定的数量，此数量根据电子交易平台的处理能力设定，例如，处理线程组130中的处理线程的数量为200个，则同一时间电子交易平台只能响应200个消息，对于第200个以后的消息，电子交易平台不响应，避免服务使用者过多造成电子交易平台当机的现象，从而可以确保电子交易平台的正常运行。其中，处理线程1储存消息队列10中的服务请求11、服务请求12、服务请求13，处理线程2储存消息队列20中的服务请求21、服务请求22、服务请求23，……处理线程n储存消息队列n0中的服务请求n1、服务请求n2、服务请求n3。 

请求处理单元140，用于从所述处理线程组130中获取并处理所述消息中的服务请求；在本发明实施例中，请求处理单元140包括多种请求处理管道，分别为请求处理管道1、请求处理管道2……请求处理管道n；每一个请求处理管道对应处理一种服务请求，且每个请求处理管道可以处理多个相同类型的服务请求。所述处理线程130从所述消息队列单元110获取消息，并根据已拆分成服务请求的消息，将各消息中的同类服务请求发送给对应的请求处 理管道进行处理。而请求处理单元140中，各请求处理管道调用相应的应用服务，对服务请求进行处理后，将请求处理结果反馈给消息收发单元110中相应的消息通道。 

需要说明的是，在前述将消息拆分成服务请求的过程中，服务请求自身仍然保留有相关的索引信息，以此可以区分服务请求的消息来源。因此请求处理管道在处理完服务请求后，可以根据上述索引信息，将请求处理结果反馈给对应的处于挂起等待状态的消息通道。 

此外作为另一种可选的方案，所述请求处理单元140并不是直接将请求处理结果反馈给消息通道，而是逆向先发送给处理线程组130中的处理线程，处理线程将接收到的请求处理结果的结果发送给对应的消息队列，之后再发送给对应的消息接收通道，这样就免去了在访问请求中设置索引信息的步骤。需要说明的是，上述使用“对应”一词的意思为，返回的消息、请求经由来时的路径返回。 

若在预定的处理时间内，当一个消息中所包括的所有服务请求的处理结果都返回对应的消息通道时，消息通道将上述请求处理结果打包反馈给发起消息的用户端，也即服务使用者。若超出了预定的处理时间，当一个消息中包括的所有服务请求的处理结果并未全部返回，消息通道判定该消息处理超时，将放弃该消息的处理，而接收下一个消息。 

作为可选的方案，消息通道判定消息处理超时后，可以丢弃之前已经得到的部分请求处理结果，让出消息通道资源以便接收下一个消息；进一步的还可以反馈一个超时信息给发起消息的用户端，即告知服务使用者本次访问超时。 

将上述服务总线应用于电子商务交易平台中，以钢材的电子商务交易为例，本发明中的所述消息可以为各种商品的交易消息，商品为钢材，交易消息包括发布钢材现货的交易消息(对应于钢材的出库、入库)，合约的交易信 息(对应于采购、销售的意向)，还包括注册消息(对应于注册成为电子交易平台的会员)，更新商品消息，注销消息(对应于注销电子交易平台的会员)，更新注册消息(对应于更新会员信息)，用户的积分查询、信用查询等。 

图2为本发明实施例所述服务总线应用于上述电子交易平台的示意图，而图3为该实施例中消息处理方法的流程示意图。以下结合具体的案例，并参考图2以及图3，对本发明进行说明。 

假设服务使用者需要查询积分和信用等与用户信息有关的信息，服务使用者首先通过用户端发送查询用户信息给服务总线。由于用户信息包括用户的积分、信用、历史交易记录等，因此在本次访问中，查询用户信息将包括积分服务查询请求、信用服务请求、历史交易记录查询请求等。上述服务请求均属于不同种类，而用户端会将上述服务请求打包成一个消息发送给服务总线的消息收发单元。 

服务总线100对上述消息进行处理的具体步骤如下： 

步骤101，消息收发单元110中，消息通道1接收所述服务使用者从用户端发起的消息。所述消息中包括积分服务查询请求、信用服务请求、历史交易记录查询请求等。消息通道1将上述消息发送给消息队列单元120，然后进入挂起等待状态，此时消息通道1将不会接收任何其他的消息。同时消息通道1根据预定的处理时间开始进行挂起等待倒计时。假设预定的处理时间为T。 

步骤102，消息队列单元120接收到上述消息后，首先将上述消息拆分成积分服务查询请求、信用服务请求、历史交易记录查询请求，各服务请求中均记录有索引信息，所述索引信息说明其消息来源为消息通道1，然后消息队列单元120根据接收到消息的时间进行消息排序。在排序过程中，由于同一消息中各服务请求的接收时间是相同的，因此各服务请求依然可以视为处于一种捆绑的状态参与消息排序。在其他实施例里，所述消息排序的方式可以 是根据优先级排序；还可以先进行消息排序，再对消息进行拆分，本实施例不再赘述。 

步骤103，处理线程组130从所述消息队列单元120中接收预定数量的已排序的消息，其中一个处理线程中接收一个消息，然后处理线程将消息中的各服务请求根据种类，发送至请求处理单元140的相应请求处理管道中进行处理。本实施例中，上述消息所包括的积分服务查询请求、信用服务请求、历史交易记录查询请求，发送至相应请求处理管道。例如积分服务查询请求处理管道调用积分服务进行相关处理得到相应客户的积分信息，而信用服务查询请求处理管道调用信用服务进行相关处理得到相应客户的信用信息等。上述处理结果，均将根据服务请求里的索引信息被反馈回消息通道1。 

消息通道1接收请求处理单元140反馈的请求处理结果，当所有请求处理结果均返回后，假设消息通道1中针对该消息的挂起等待状态的倒计时尚未结束，即该消息的处理尚未超出预定的处理时间T，执行步骤104。 

步骤104，消息通道1将得到的请求处理结果包括客户的积分信息、信用信息、历史交易记录等打包，反馈给发起消息的用户端，并结束本次消息处理，接收下一消息。 

假设消息通道1中针对该消息的挂起等待状态的倒计时结束，而由于对用户的交易记录的查询处理较为复杂，消息通道1仅收到用户的积分信息以及信用信息的查询结果，即该消息的处理超出时间T，则执行步骤105。 

步骤105，消息通道1放弃该消息处理，丢弃已得到的包括用户的积分信息以及信用信息的查询处理结果，向发起消息的用户端发送超时信息，告知用户本次访问超时，然后结束本次消息处理，接收下一消息。而之后，即使再收到请求处理单元140所反馈的关于用户交易记录的查询处理结果，由于消息通道1已经进入其他消息的处理状态，因此将忽略上述请求处理结果。

以上所述的具体实施例，仅以一个包括三类查询请求的消息处理为例进 行说明。在具体实例中，可能会同时有多个不同的用户端发送消息，使得系统处于满负荷状态。上述超时丢弃的处理机制，可以排除超时的消息处理对消息通道的占用，解决消息收发单元的拥堵，并减轻系统压力，以防止系统崩溃当机。 

本发明虽然已以较佳实施例公开如上，但其并不是用来限定本发明，任何本领域技术人员在不脱离本发明的精神和范围内，都可以利用上述揭示的方法和技术内容对本发明技术方案做出可能的变动和修改，因此，凡是未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化及修饰，均属于本发明技术方案的保护范围。 

Claims (9)

1.一种服务总线，其特征在于，包括：

消息收发单元，包括多个消息通道，每一消息通道用于接收包括至少一个服务请求的消息，并预定消息处理的时间，若在预定的处理时间内得到消息中所有服务请求的处理结果，则将所述请求处理结果打包反馈，若一个消息中包括的所有服务请求的处理结果并未在预定的处理时间内全部返回，消息通道判定该消息处理超时，将放弃该消息的处理，而接收下一个消息；

消息队列单元，用于从所述多个消息通道接收消息，并按预定规则进行排序；

处理线程组，用于从所述消息队列单元接收预定数量的已排序的消息；

请求处理单元，用于从所述处理线程组中获取并处理所述消息中的服务请求，将请求处理结果反馈给消息通道。

2.如权利要求1所述的服务总线，其特征在于，所述消息通道丢弃已得到的请求处理结果，还包括反馈超时信息的步骤。

3.如权利要求1所述的服务总线，其特征在于，所述按预定规则进行排序是指按消息接收时间顺序或消息优先级进行排序。

4.如权利要求1所述的服务总线，其特征在于，所述消息包括至少两个服务请求；

所述服务总线还包括：请求拆分单元，用于将所述消息队列单元接收的消息拆分成服务请求后发送给所述处理线程组。

5.一种服务总线的消息处理方法，其特征在于，包括：

接收消息，每一消息包括至少一个服务请求；

按预定规则对所述接收的消息进行排序；

接收预定数量的已排序的消息，处理所述消息中的服务请求；

若一个消息中服务请求在预定的处理时间内均能得到处理结果，则将请求处理结果打包反馈，若一个消息中服务请求在预定的处理时间内无法全部得到处理结果，则放弃该消息的处理。

6.如权利要求5所述的服务总线的消息处理方法，其特征在于，所述放弃消息的处理还包括丢弃已得到的请求处理结果。

7.如权利要求5所述的服务总线的消息处理方法，其特征在于，所述放弃消息的处理还包括反馈超时信息。

8.如权利要求5所述的服务总线的消息处理方法，其特征在于，所述按预定规则进行排序是指按消息接收时间顺序或消息优先级进行排序。

9.如权利要求5所述的服务总线的消息处理方法，其特征在于，所述消息包括至少两个服务请求，处理消息中的服务请求前还包括将消息拆分成服务请求。

Images