CN106059892A - 一种用于融合通信***的消息引擎 - Google Patents

Abstract

本发明涉及一种用于融合通信***的消息引擎。包括：消息队列与MQTT代理服务器，用于实现基于物联网标准协议的消息通信功能，根据消息的发布/订阅机制设计消息路由规则，实现消息的多终端同步机制；业务模块层，用于实现消息引擎的各个业务功能；数据存储层，用于为业务模块层提供数据支持。本发明的消息引擎服务器具有很好的抗压性和健壮性，能够处理多种异常情况，具有最高的鲁棒性；同时能够很好运用于移动互联网络，并且有很好的并发处理能力。

Description

一种用于融合通信***的消息引擎

技术领域

本发明涉及移动互联网络和物联网通信协议，是一种用于融合通信***的消息引擎。

背景技术

在继万维网、E-mail之后发展最为迅猛的互联网应用是即时消息通信，它是指互联网上用以进行实时通信的***服务，其允许多人使用即时通讯通信软件实时的传递文本、图片、文档、语音及视频等信息流。近年来，随着即时消息通信技术不断发展和即时通信工具的广泛应用，越来越多的企业部署了即时消息通信***，旨在提高工作效率，降低沟通成本。特别是近年来，随着移动互联网的兴起，无论是个人用户还是企业用户都将IM(insurant messaging，即时通信)作为有效的沟通途径，使得IM软件在个人消息通信与企业消息通信市场上得到了广泛的应用，同时也显示了它的巨大市场潜力。当前主流的消息通信软件有ICQ、Tencent QQ、WeChat、Weibo等，但这些消息通信软件的提供商出于各自利益的考虑，大部分即时消息通信***采用了私有通信协议，在一定程度上阻碍了使用不同即时消息通信***的个人或企业之间的沟通交流，也不利于企业即时通信***与公司内部重要***的互联互通。

本发明正是在此背景下，并在分析了SIMPLE、XMPP和MQTT协议的基础上，提出了一套面向企业的、基于物联网标准协议的消息引擎服务器的设计，并实现了消息引擎服务器的用户身份认证、消息接收和发送、状态信息监控和消息预订阅等功能。其中MQTT(MessageQueuing Telemetry Transport)协议是IBM开发的一个开放的即时通讯协议，并于2014年11月，MQTT v3.1.1成为OASIS(Organization for the Advancement of StructuresInformation Standard)标准协议。

发明内容

针对现有即时消息通信应用主要采用私有协议进行开发的弊端，本发明基于物联网标准协议(MQTT协议)提出了一种用于融合通信***的消息引擎。

本发明为实现上述目的所采用的技术方案是：一种用于融合通信***的消息引擎，

(定稿后拷贝权利要求)

本发明具有以下优点及有益效果：

1.本发明设计了一种用于融合通信***的消息引擎，本消息引擎服务器具有很好的抗压性和健壮性。

2.本发明设计了一种用于融合通信***的消息引擎，能够处理多种异常情况，具有最高的鲁棒性。

3.本发明设计了一种用于融合通信***的消息引擎，能够很好运用于移动互联网络，并且有很好的并发处理能力。

附图说明

图1是消息引擎***结构图；

图2是消息路由规则过程示例图；

图3是用户多终端IM模型图；

图4是Presence模块流程图；

图5是用户身份认证过程图；

图6是预订阅模块流程图；

图7是sub/unsub流程图；

图8是统一消息中心模块流程图；

图9是用户连接通信过程图。

具体实施方式

下面结合附图及实施例对本发明做进一步的详细说明。

如图1所示，给出了融合通信消息引擎服务器的结构设计，采用三层结构，主要包括MQTT broker，业务逻辑层和数据存储层。其中MQTT broker采用Mosquitto进行开发，并在其上运用插件的方式实现消息引擎所要实现完成的业务逻辑；业务逻辑层主要包括IM消息传输、presence消息传输、话题预订阅以及用户登录身份认证等；数据存储层主要是实现消息以及用户信息的存储。

消息引擎对消息路由规则的设计。一条消息路由规则的基本组成包括4部分，即消息路由方向(Derection)，源地址(srcTopic)，消息路由动作(Action)，目的地址(destTopic)。

如图2所示，给出了消息传输的消息路由过程，以Tom与Jhone通信过程为例来详细描述消息路由的过程：

步骤1)Tom PC端向Jhone的IM topic发送一条消息；

步骤2)broker在收到该消息时，通过查询消息路由规则，判断是否有匹配的路由规则，若有则继续进行，否则跳过步骤3和5过程；

步骤3)按照消息路由规则中的Action进行消息路由，找到转发的目的topic，此处为Tom的IM topic；

步骤4)把消息pub给Jhone；

步骤5)Tom的手机端收到PC端发送的消息，并且在手机端呈现；

步骤6)Jhone的所有终端收到Tom发来的消息。

如图3所示，给出了多终端IM机制的模型，用户的IM功能主要有好友之间进行IM通信、用户多终端之间IM消息同步，离线终端IM消息同步以及IM消息支持多种类型。IM消息的类型包括文字、图片、文件、音频等多种媒体。本发明的IM模型与以前的IM模型比较，本模型支持用户的多终端，采用基于话题的发布/订阅，消息的交互通过MQTT代理完成。IM消息接收可根据用户在线状态来判断是实时发送还是在服务器端存储，在用户上线时再将消息推送到用户客户端，同时消息引擎服务器支持同一用户在多个不同终端上同时在线。根据所述消息路由规则实现多终端的消息同步功能。

每一个用户拥有一个IM的主题，每一个用户的每个终端都订阅这个IM主题，每个用户的每个终端都对应一个IM主题，对于每一个终端都要订阅与之相对应的主题。在进行IM的时候，如图2所示进行消息路由，发送方向接收方的IM主题上发送消息，这样就可以实现消息的收发，但是要实现消息的同步，还需要基于消息路由规则的消息同步策略。该消息路由规则是通过话题的模糊匹配，对于匹配成功的话题，将消息复制到目标主题上去。

消息路由规则是通过话题的模糊匹配，对于匹配成功的话题，将消息复制到目标主题上去。消息路由规则的一般格式为：

<direction>,<SourceTopic>,<action>,<DestinationTopic>

其中direction决定消息路由方向，SourceTopic决定收到的消息是否需要路由，action决定路由的动作，DestinationTopic决定消息的去向，且只有在action为复制或转发时才有效。

对于一条IM消息，需要包含消息的发送时间，类型，内容类型，消息内容，发送者信息等，IM消息的消息格式如表1所示。

表1

Name

TS

Type

Conlen

Con

Senderlen

Sender

Byte

4

1

3

c-len

1

s-len

服务器中还定义了一些***的通知，其消息格式类似于IM消息的消息格式，包括通知时间，通知类型，以及通知的内容。通知的类型主要包括***通知、企业***通知、个人***通知、群组通知、群管理员通知，如表2所示。

表2

***通知是指本***中***消息，用以推送到所有的用户；企业***通知是指单个企业的***消息，用以推送到某个企业的所有用户；个人***通知是指单个用户的通知消息，主要包括好友离线文件提醒、业务通知、日程提醒通知、邮件更新通知，被邀请加入群，群转让给自己等；群组通知是指对群组内成员的通知，主要包括群组公告更新、群组的基本信息修改、群组高级信息修改、群组解散通知、群组转让通知等；群管理员通知是指专门针对群组的管理员的一些通知。

在消息引擎服务器中，运用Presence模块来实现用户基本在线状态信息的发布。Presence消息包括呈现状态和可选的自定义状态两部分；通知消息包括通知的时间戳，通知类型和通知的消息内容。Presence消息主要包括两个字节，如表3所示，第一个字节表示详细呈现状态的代码，其中定义了6种Status，0x01表示在线，0x02表示离线，0x03表示隐身，0x04表示忙碌，0x05表示请勿打扰，0x06表示自定义，剩余的保留；第二个字节为可选部分，只有详细状态为0x06时，其中存储自定义的呈现状态。用户在线状态信息的发布主要分为两步，第一，MQTT代理接收到用户的connect和disconnect信息时，判断用户的基本在线信息，将信息封装交付给Presence模块；第二，Presence模块接收到封装信息，解封消息，构造话题，正式发布用户的状态信息。

表3

每一个用户均需要订阅自己用户名下的状态主题，同时还需要订阅好友的状态主题，该部分的订阅操作由预订阅功能模块来完成。由于Presence不会向离线的用户发送状态信息，而且在离线用户上线时，可以获取用户们的状态信息，可以通过标记RETAIN来实现对该状态消息的推送。规定终端的主题均是按照QoS＝0的方式订阅，对于状态消息的发布，QoS＝0，retain＝1，这样就保证了在新的状态消息到达代理服务器以后，所有旧的retain＝1的状态消息被代理服务器丢弃，只保留最新的状态消息。

presence模块的操作过程如图4所示：

步骤1)解析消息，得到clientid、uid和当前要发布的状态。

步骤2)遍历链表，查询是否存在节点数据为该clientid的节点，如果存在这样的节点且用户的状态为离线，则删除节点信息；如果不存在这样的节点且用户的状态为在线，则添加节点信息。其余情况不做处理。

步骤3)由前述机制设计可知，对于一个Presence话题由一个eid和一个uid就可以唯一确认。eid的获取可以通过webservice查询。

步骤4)记录用户的状态信息到数据库中。

步骤5)根据uid和获取的eid构造话题及对应的消息，发布用户的基本状态。

本发明的消息引擎服务器采用了基于发布/订阅模型的MQTT协议作为基础，其数据模型为话题，对于任何消息的推送都是通过话题的形式来组织完成。每个用户有很多好友，而每个好友关系都需要几个话题，所以为提高消息引擎服务器的用户体验，提出了预订阅模块，预订阅模块的基本过程如图6所示。通过对***的分析，预订阅的处理过程主要包括以下3种情况：

情况1)增加用户、删除用户或修改用户角色时，该用户的好友订阅关系会有变化；

情况2)用户在群创建、群成员加入、群成员删除时，该用户的订阅关系发生变化；

情况3)用户首次登录时，包括开户后首次登录和在***最大时间间隔没登录之后又登录两种情况，此时用户的订阅关系为空，需要为其预订阅相关话题。

对于所述情况1、情况2发生后，LDAP service根据情况发生所影响的用户，生成话题更新的列表，通过消息总线发送给预订阅模块。消息格式为：

<clientid>-<sub|unsub>-Qos-<topic_count>-<topic1>[,toipic2]

第一项clientid表示为该clientid进行预订阅；第二项为sub或unsub表示预订阅的动作是订阅还是取消订阅；topic_count决定了后面有几个话题。若情况3发生，代理会将用户登录的clientid通知预订阅模块为用户添加订阅关系，预订阅模块收到clientid后，通过webservice告知LDAP service，由LDAP service整理该用户需要订阅的话题，通过总线的再回传到预订阅模块。其中sub与unsub过程如图7所示。

预订阅功能是用于用户终端第一次连接MQTT代理服务器时帮助用户订阅话题。首先设计一个话题，服务器代理判断用户终端是否是第一次连接，如果是，则将该用户的clientid推送到设计好的话题上，再利用预订阅模块订阅话题，然后根据收到的clientid帮助用户整理订阅话题列表，再将话题列表提交到服务器代理完成话题订阅。

对于预订阅功能模块的实现主要分为两部分：

(1)MQTT broker检测到用户第一次连接，将用户终端的clientid推送到话题/e/presub/connection/new上。在Mosquitto中定义mqtt3_connect_state方法来实现对连接状态的检测；

(2)预订阅模块在接收到代理服务器发送到话题/e/presub/connection/new上的消息时，获取clientid，通过LDAP service从LDAP数据库中获取该clientid需要订阅的话题列表，然后将话题列表发送给代理服务器进行订阅。

sub与unsub的过程为：最上层传输的数据db是mosquitto的内部数据库，context是发送sub/unsub消息的mosquitto实体。因此，当预订阅模块向mosquitto发起subscribe/unsubscribe时，context指的是预订阅模块，此时，是给预订阅模型进行了话题的订阅和取消订阅而不是给用户订阅。因此，为了完成预订阅，这部分要做相应的逻辑处理，即要获取订阅用户的context，并进行替换。用户的context可以根据用户的clientid进行hash查找。将clientid的值通过subscribe消息的消息内容传递给mosquitto。subscribe的消息内容中本来存储的是topic/qos对，对于预订阅发送给mosquitto的subscribe消息，为了携带订阅用户的clientid，对消息的内容进行一定的修改，对于消息中的第一个topic/qos对，话题中存储用户的clientid，qos设置为5(合法的qos是0，1，2)。mosquitto解析消息，可以根据第一个qos的值来判别这个subscribe消息时一个普通的订阅消息，还是预订阅消息。如果是普通的subscribe消息，不做其他特殊处理。按原流程进行订阅操作。如果是预订阅的subscribe消息，根据用户的clientid，进行hash，查找到该clientid对应的context，然后利用该context进行订阅操作。最后的suback要回给预订阅模块。

业务模块层还包括统一消息中心模块。如图8所示，给出了统一消息中心模块的流程，该部分主要用于处理离线消息的转移。根据Mosquitto中对离线消息的处理，统一消息中心模块涉及的话题有以下三种：

1.点对点的IM：/e/+/imtran/u/+

2.群组的IM：/e/+/imtran/g/+/+

3.公共账号的IM：/e/+/imtran/p/+/+

通过通配符的方式，囊括了所有的情况。统一消息中心模块需要对这三类话题进行订阅。订阅成功后，每当离线用户收到消息后，代理将离线消息推送给本模块。本模接收到消息后，首先对话题进行初步解析，判断消息的类型，含有“/u/”的为点对点IM，含有“/g/”为群组IM，含有“/p/”的为公共账号IM。其次，进一步解析话题，获取消息发送者uid、gid、pid。然后根据解析到的uid调用webservice去查询LDAP获取用户通信地址及用户配置。最后按照格式构造短信或邮件内容，将其送到消息总线中。

如图5所示，给出了用户的认证流程。对于用户认证，Mosquitto中提供了插件的方式来扩展用户认证。插件可以通过配置文件、数据库等方式来完成校验。对于配合代理的核心模块采用配置文件的方式进行认证，普通终端用户通过校验存放在redis数据库中的认证信息完成。

如图9所示，给出了两个用户进行通信的过程，首先user1与user2对服务器发起连接请求，服务器给client返回ACK，建立连接；然后user1向服务器user2的话题上发布消息，服务器收到消息后返回puback；服务器将消息推送到user2，user2收到消息后返回puback。

Claims (10)

1.一种用于融合通信***的消息引擎，其特征在于，包括：

消息队列与MQTT代理服务器，用于实现MQTT协议功能，基于MQTT协议的发布/订阅机制实现消息路由规则；

业务模块层，用于实现消息引擎的各个业务功能；

数据存储层，用于为业务模块层提供数据支持。

2.根据权利要求1所述的一种用于融合通信***的消息引擎，其特征在于，所述业务模块层包括：

presence模块，用于呈现用户的各个终端的状态信息；

IM模块，用于用户好友之间的IM消息传递，在MQTT代理服务器的控制下，根据用户在线状态判断将IM消息实时发送还是存储在数据存储层中，在用户上线时再将IM消息推送到用户的客户端；

presub模块，用于在用户终端第一次连接MQTT代理服务器时，为用户预订阅话题；

用户身份认证模块，用于用户登录时的身份验证。

3.根据权利要求1所述的一种用于融合通信***的消息引擎，其特征在于，所述消息引擎采用MQTT协议，其消息格式包括消息头部和承载消息的payload部分；

如果该消息为IM消息，则payload部分包括消息的发送时间、消息类型、消息内容类型、消息内容和发送者信息；

如果该消息为presence消息，则payload部分包括呈现状态和可选的自定义状态信息；

如果该消息为通知消息，则payload部分包括通知的时间戳、通知类型和通知的内容消息。

4.根据权利要求1所述的一种用于融合通信***的消息引擎，其特征在于，所述消息路由规则的基本组成包括4部分：消息路由方向、源地址、消息路由动作、目的地址，其路由过程为：

步骤1)用户A的一个终端向用户B的IM话题发送一条消息；

步骤2)MQTT代理服务器在收到该消息时，通过查询消息路由规则，判断是否有匹配的路由规则，若有则继续进行，否则跳过步骤3和步骤5；

步骤3)按照消息路由规则中的消息路由动作进行消息路由，找到转发的目的地址，即用户A的IM话题；

步骤4)MQTT代理服务器把消息发布给用户B；

步骤5)用户A的其他在线终端收到由发送消息的终端发送的该消息，并且呈现；

步骤6)用户B的所有在线终端收到该消息。

5.根据权利要求2所述的一种用于融合通信***的消息引擎，其特征在于，所述presub模块通过以下方式为用户预订阅话题：

首先设计一个话题，MQTT代理服务器判断用户终端是否是第一次连接，如果是，则将该用户的用户终端ID推送到所述话题上，再订阅该话题；根据收到的用户终端ID为用户整理订阅话题列表，再将话题列表提交到MQTT代理服务器完成话题订阅。

6.根据权利要求1所述的一种用于融合通信***的消息引擎，其特征在于，所述IM模块采用IM话题的订阅/发布机制，通过MQTT代理服务器进行消息的推送，具体为：

每一个用户拥有一个IM话题，每一个用户的每个终端都订阅这个IM话题，每个用户的每个终端都对应一个IM话题，对于每一个终端都订阅与之相对应的话题；在进行IM通信时，发送方向接收方的IM话题上发送消息，然后MQTT代理服务器根据消息路由规则进行消息推送，以实现消息的收发。

7.根据权利要求1所述的一种用于融合通信***的消息引擎，其特征在于，所述presence模块通过标记MQTT协议中的RETAIN来实现对用户状态消息的推送，具体为：规定用户所有终端的主题均是按照QoS＝0的方式订阅，对于状态消息的发布，QoS＝0，retain＝1，以保证在新的用户状态消息到达MQTT代理服务器以后，所有旧的retain＝1的状态消息被MQTT代理服务器丢弃，只保留最新的状态消息。数据存储层

8.根据权利要求1所述的一种用于融合通信***的消息引擎，其特征在于，所述用户身份认证模块通过校验存放在MQTT代理服务器中的Redis数据库中的认证信息完成用户身份认证。

9.根据权利要求1所述的一种用于融合通信***的消息引擎，其特征在于，所述MQTT代理服务器通过插件的方式配合用户身份认证模块完成用户身份认证；所述插件能够通过配置文件、数据库的方式完成用户身份认证。

10.根据权利要求1所述的一种用于融合通信***的消息引擎，其特征在于，所述数据存储层包括MySQL数据库、LDAP数据库和Redis数据库；所述MySQL数据库用于存储IM消息、presence消息；所述LDAP数据库用于存储用户信息；所述Redis数据库用于调取LDAP数据库中的用户信息以完成用户身份认证模块对用户身份的认证。