一种用于融合通信系统的消息引擎的制作方法
【专利摘要】本发明涉及一种用于融合通信系统的消息引擎。包括：消息队列与MQTT代理服务器，用于实现基于物联网标准协议的消息通信功能，根据消息的发布/订阅机制设计消息路由规则，实现消息的多终端同步机制；业务模块层，用于实现消息引擎的各个业务功能；数据存储层，用于为业务模块层提供数据支持。本发明的消息引擎服务器具有很好的抗压性和健壮性，能够处理多种异常情况，具有最高的鲁棒性；同时能够很好运用于移动互联网络，并且有很好的并发处理能力。
【专利说明】
-种用于融合通信系统的消息引擎
技术领域
[0001] 本发明设及移动互联网络和物联网通信协议，是一种用于融合通信系统的消息引 擎。
【背景技术】
[0002] 在继万维网、E-mail之后发展最为迅猛的互联网应用是即时消息通信，它是指互 联网上用W进行实时通信的系统服务，其允许多人使用即时通讯通信软件实时的传递文 本、图片、文档、语音及视频等信息流。近年来，随着即时消息通信技术不断发展和即时通信 工具的广泛应用，越来越多的企业部署了即时消息通信系统，旨在提高工作效率，降低沟通 成本。特别是近年来，随着移动互联网的兴起，无论是个人用户还是企业用户都将IM (insurant messaging,即时通信）作为有效的沟通途径，使得IM软件在个人消息通信与企 业消息通信市场上得到了广泛的应用，同时也显示了它的巨大市场潜力。当前主流的消息 通信软件有ICQ、Tencent QQ、WeChat、Weibo等，但运些消息通信软件的提供商出于各自利 益的考虑，大部分即时消息通信系统采用了私有通信协议，在一定程度上阻碍了使用不同 即时消息通信系统的个人或企业之间的沟通交流，也不利于企业即时通信系统与公司内部 重要系统的互联互通。
[0003] 本发明正是在此背景下，并在分析了 SIMPLE、XMPP和MQTT协议的基础上，提出了一 套面向企业的、基于物联网标准协议的消息引擎服务器的设计，并实现了消息引擎服务器 的用户身份认证、消息接收和发送、状态信息监控和消息预订阅等功能。其中MQTT(Message Queuing Teleme化y化ansport)协议是IBM开发的一个开放的即时通讯协议，并于2014年 11 月，MQTT v3.1.1 成为0ASIS(0rganization for the Advancement of Structures Information Standard)标准协议。
【发明内容】
[0004] 针对现有即时消息通信应用主要采用私有协议进行开发的弊端，本发明基于物联 网标准协议(MQTT协议)提出了一种用于融合通信系统的消息引擎。
[0005] 本发明为实现上述目的所采用的技术方案是：一种用于融合通信系统的消息引 擎，
[0006] (定稿后拷贝权利要求）
[0007] 本发明具有W下优点及有益效果：
[000引1.本发明设计了一种用于融合通信系统的消息引擎，本消息引擎服务器具有很好 的抗压性和健壮性。
[0009] 2.本发明设计了一种用于融合通信系统的消息引擎，能够处理多种异常情况，具 有最高的鲁棒性。
[0010] 3.本发明设计了一种用于融合通信系统的消息引擎，能够很好运用于移动互联网 络，并且有很好的并发处理能力。
【附图说明】
[0011] 图1是消息引擎系统结构图；
[0012] 图2是消息路由规则过程示例图；
[0013] 图3是用户多终端IM模型图；
[0014] 图4是Presence模块流程图；
[0015] 图5是用户身份认证过程图；
[0016] 图6是预订阅模块流程图；
[0017]图 7是 sub/unsub 流程图；
[001引图8是统一消息中屯、模块流程图；
[0019] 图9是用户连接通信过程图。
【具体实施方式】
[0020] 下面结合附图及实施例对本发明做进一步的详细说明。
[0021] 如图1所示，给出了融合通信消息引擎服务器的结构设计，采用Ξ层结构，主要包 括MQTT broker,业务逻辑层和数据存储层。其中MQTT broker采用Mosquitto进行开发，并 在其上运用插件的方式实现消息引擎所要实现完成的业务逻辑;业务逻辑层主要包括IM消 息传输、presence消息传输、话题预订阅W及用户登录身份认证等;数据存储层主要是实现 消息W及用户信息的存储。
[0022] 消息引擎对消息路由规则的设计。一条消息路由规则的基本组成包括4部分，即消 息路由方向（Defection )，源地址（srcTopic )，消息路由动作（Act ion)，目的地址 (destTopic)。
[0023] 如图2所示，给出了消息传输的消息路由过程，WTom与Jhone通信过程为例来详细 描述消息路由的过程：
[0024] 步骤l)Tom PC端向Jlione的IM topic发送一条消息；
[002引步骤2)broker在收到该消息时，通过查询消息路由规则，判断是否有匹配的路由 规则，若有则继续进行，否则跳过步骤3和5过程；
[0026] 步骤3)按照消息路由规则中的Action进行消息路由，找到转发的目的topic,此处 为Tom的IM topic;
[0027] 步骤4)把消息pub给Jhone;
[002引步骤5)Tom的手机端收到PC端发送的消息，并且在手机端呈现；
[0029] 步骤6)Jhone的所有终端收到Tom发来的消息。
[0030] 如图3所示，给出了多终端IM机制的模型，用户的IM功能主要有好友之间进行IM通 信、用户多终端之间IM消息同步，离线终端IM消息同步W及IM消息支持多种类型。IM消息的 类型包括文字、图片、文件、音频等多种媒体。本发明的IM模型与W前的IM模型比较，本模型 支持用户的多终端，采用基于话题的发布/订阅，消息的交互通过MQTT代理完成。IM消息接 收可根据用户在线状态来判断是实时发送还是在服务器端存储，在用户上线时再将消息推 送到用户客户端，同时消息引擎服务器支持同一用户在多个不同终端上同时在线。根据所 述消息路由规则实现多终端的消息同步功能。
[0031] 每一个用户拥有一个IM的主题，每一个用户的每个终端都订阅运个IM主题，每个 用户的每个终端都对应一个IM主题，对于每一个终端都要订阅与之相对应的主题。在进行 IM的时候，如图2所示进行消息路由，发送方向接收方的IM主题上发送消息，运样就可W实 现消息的收发，但是要实现消息的同步，还需要基于消息路由规则的消息同步策略。该消息 路由规则是通过话题的模糊匹配，对于匹配成功的话题，将消息复制到目标主题上去。
[0032] 消息路由规则是通过话题的模糊匹配，对于匹配成功的话题，将消息复制到目标 主题上去。消息路由规则的一般格式为：
[0033] <direction>,<SourceTopic>,<action>,<DestinationTopic>
[0034] 其中direction决定消息路由方向，SourceTopic决定收到的消息是否需要路由， 曰。1：；[0]1决定路由的动作，〇631：；[]1曰1：；[0]11'(冲；[(3决定消息的去向，且只有在曰(31：；[0]1为复制或转 发时才有效。
[0035] 对于一条IM消息，需要包含消息的发送时间，类型，内容类型，消息内容，发送者信 息等，IM消息的消息格式如表1所示。
[0036] 表1
[0037]
[0038] 服务器中还定义了一些系统的通知，其消息格式类似于IM消息的消息格式，包括 通知时间，通知类型，W及通知的内容。通知的类型主要包括系统通知、企业系统通知、个人 系统通知、群组通知、群管理员通知，如表2所示。
[0039] 表 2
[0040]
[0041]
[0042] 系统通知是指本系统中系统消息，用W推送到所有的用户；企业系统通知是指单 个企业的系统消息，用W推送到某个企业的所有用户；个人系统通知是指单个用户的通知 消息，主要包括好友离线文件提醒、业务通知、日程提醒通知、邮件更新通知，被邀请加入 群，群转让给自己等;群组通知是指对群组内成员的通知，主要包括群组公告更新、群组的 基本信息修改、群组高级信息修改、群组解散通知、群组转让通知等;群管理员通知是指专 口针对群组的管理员的一些通知。
[0043] 在消息引擎服务器中，运用Presence模块来实现用户基本在线状态信息的发布。 Presence消息包括呈现状态和可选的自定义状态两部分;通知消息包括通知的时间戳，通 知类型和通知的消息内容。Presence消息主要包括两个字节，如表3所示，第一个字节表示 详细呈现状态的代码，其中定义了6种Status，0x01表示在线，0x02表示离线，0x03表示隐 身，0x04表示忙碌，0x05表示请勿打扰，0x06表示自定义，剩余的保留；第二个字节为可选部 分，只有详细状态为0x06时，其中存储自定义的呈现状态。用户在线状态信息的发布主要分 为两步，第一，MQTT代理接收到用户的connect和disconnect信息时，判断用户的基本在线 信息，将信息封装交付给Presence模块;第二，Presence模块接收到封装信息，解封消息，构 造话题，正式发布用户的状态信息。
[0044] 表 3
[0045]
[0046] 每一个用户均需要订阅自己用户名下的状态主题，同时还需要订阅好友的状态主 题，该部分的订阅操作由预订阅功能模块来完成。由于Presence不会向离线的用户发送状 态信息，而且在离线用户上线时，可W获取用户们的状态信息，可W通过标记RETAIN来实现 对该状态消息的推送。规定终端的主题均是按照Q〇S = 0的方式订阅，对于状态消息的发布， QoS = 0，retain=l，运样就保证了在新的状态消息到达代理服务器W后，所有旧的re化in =1的状态消息被代理服务器丢弃，只保留最新的状态消息。
[0047] presence模块的操作过程如图4所示：
[004引步骤1)解析消息，得到clienticUuid和当前要发布的状态。
[0049] 步骤2)遍历链表，查询是否存在节点数据为该clientid的节点，如果存在运样的 节点且用户的状态为离线，则删除节点信息;如果不存在运样的节点且用户的状态为在线， 则添加节点信息。其余情况不做处理。
[0050] 步骤3)由前述机制设计可知，对于一个Presence话题由一个eid和一个uid就可W 唯一确认。eid的获取可W通过webservice查询。
[0051 ]步骤4)记录用户的状态信息到数据库中。
[0052] 步骤5)根据uid和获取的eid构造话题及对应的消息，发布用户的基本状态。
[0053] 本发明的消息引擎服务器采用了基于发布/订阅模型的MQTT协议作为基础，其数 据模型为话题，对于任何消息的推送都是通过话题的形式来组织完成。每个用户有很多好 友，而每个好友关系都需要几个话题，所W为提高消息引擎服务器的用户体验，提出了预订 阅模块，预订阅模块的基本过程如图6所示。通过对系统的分析，预订阅的处理过程主要包 括W下巧巾情况：
[0054] 情况1)增加用户、删除用户或修改用户角色时，该用户的好友订阅关系会有变化；
[0055] 情况2)用户在群创建、群成员加入、群成员删除时，该用户的订阅关系发生变化；
[0056] 情况3)用户首次登录时，包括开户后首次登录和在系统最大时间间隔没登录之后 又登录两种情况，此时用户的订阅关系为空，需要为其预订阅相关话题。
[0化7] 对于所述情况1、情况2发生后，LDAP service根据情况发生所影响的用户，生成话 题更新的列表，通过消息总线发送给预订阅模块。消息格式为：
[0058] <clientid〉-<subIunsub〉-Qos-<topic_count〉-<topicl〉[,toipic2]
[0化9] 第一项clientid表示为该clientid进行预订阅；第二项为sub或unsub表示预订阅 的动作是订阅还是取消订阅；topic_count决定了后面有几个话题。若情况3发生，代理会将 用户登录的clientid通知预订阅模块为用户添加订阅关系，预订阅模块收到clientid后， 通过webservice告知LDAP service，由LDAP service整理该用户需要订阅的话题，通过总 线的再回传到预订阅模块。其中sub与unsub过程如图7所示。
[0060]预订阅功能是用于用户终端第一次连接MQTT代理服务器时帮助用户订阅话题。首 先设计一个话题，服务器代理判断用户终端是否是第一次连接，如果是，则将该用户的 clientid推送到设计好的话题上，再利用预订阅模块订阅话题，然后根据收到的clientid 帮助用户整理订阅话题列表，再将话题列表提交到服务器代理完成话题订阅。
[0061 ]对于预订阅功能模块的实现主要分为两部分：
[0062] (l)MQTT broker检测到用户第一次连接，将用户终端的clientid推送到话题/e/ presub/connection/newJl 〇iS：Mosquitt〇i=|=i^_^mqtt3_connect_state^'^5|t^JJ)iX^3i^ 状态的检测；
[0063] (2)预订阅模块在接收到代理服务器发送到话题/e/presub/connection/new上的 消息时，获取clientid,通过LDAP service从LDAP数据库中获取该client id需要订阅的话 题列表，然后将话题列表发送给代理服务器进行订阅。
[0064] sub与unsub的过程为：最上层传输的数据化是mosquitto的内部数据库，context 是发送sub/unsub消息的mosquitto实体。因此，当预订阅模块向mosquitto发起subsc;r;Lbe/ unsubscribe时，context指的是预订阅模块，此时，是给预订阅模型进行了话题的订阅和取 消订阅而不是给用户订阅。因此，为了完成预订阅，运部分要做相应的逻辑处理，即要获取 订阅用户的context,并进行替换。用户的context可W根据用户的clientid进行hash查找。 将clientid的值通过subscribe消息的消息内容传递给mosquitto 〇subsc;r;Lbe的消息内容 中本来存储的是topic/qos对，对于预订阅发送给mosquitto的subsc;r;Lbe消息，为了携带订 阅用户的C1 i ent id，对消息的内容进行一定的修改，对于消息中的第一个topi c/qos对，话 题中存储用户的clientid，qos设置为5(合法的qos是0,1，2) Dmosquitto解析消息，可W根 据第一个qos的值来判别运个subscribe消息时一个普通的订阅消息，还是预订阅消息。如 果是普通的subscribe消息，不做其他特殊处理。按原流程进行订阅操作。如果是预订阅的 subscribe消息，根据用户的client id,进行hash,查找到该client id对应的context，然后 利用该context进行订阅操作。最后的suback要回给预订阅模块。
[0065] 业务模块层还包括统一消息中屯、模块。如图8所示，给出了统一消息中屯、模块的流 程，该部分主要用于处理离线消息的转移。根据Mosquitto中对离线消息的处理，统一消息 中屯、模块设及的话题有W下Ξ种：
[0066] 1.点对点的 IM:/e/+/imtran/u/+
[0067] 2.群组的 IM: /e/+/imtran/g/+/+
[0068] 3.公共账号的 IM: /e/+/imtran/p/+/+
[0069] 通过通配符的方式，囊括了所有的情况。统一消息中屯、模块需要对运Ξ类话题进 行订阅。订阅成功后，每当离线用户收到消息后，代理将离线消息推送给本模块。本模接收 到消息后，首先对话题进行初步解析，判断消息的类型，含有7u/"的为点对点IM，含有7 g/"为群组IM，含有7ρΓ的为公共账号IM。其次，进一步解析话题，获取消息发送者uid、 gicUpid。然后根据解析到的uid调用webservice去查询LDAP获取用户通信地址及用户配 置。最后按照格式构造短信或邮件内容，将其送到消息总线中。
[0070] 如图5所示，给出了用户的认证流程。对于用户认证，Mosquitto中提供了插件的方 式来扩展用户认证。插件可W通过配置文件、数据库等方式来完成校验。对于配合代理的核 屯、模块采用配置文件的方式进行认证，普通终端用户通过校验存放在redis数据库中的认 证信息完成。
[0071] 如图9所示，给出了两个用户进行通信的过程，首先userl与user2对服务器发起连 接请求，服务器给client返回ACK，建立连接;然后userl向服务器user2的话题上发布消息， 服务器收到消息后返回puback;服务器将消息推送到user2，user2收到消息后返回puback。
【主权项】
1. 一种用于融合通信系统的消息引擎，其特征在于，包括： 消息队列与MQTT代理服务器，用于实现MQTT协议功能，基于MQTT协议的发布/订阅机制 实现消息路由规则； 业务模块层，用于实现消息引擎的各个业务功能； 数据存储层，用于为业务模块层提供数据支持。2. 根据权利要求1所述的一种用于融合通信系统的消息引擎，其特征在于，所述业务模 块层包括： presence模块，用于呈现用户的各个终端的状态信息； IM模块，用于用户好友之间的頂消息传递，在MQTT代理服务器的控制下，根据用户在线 状态判断将頂消息实时发送还是存储在数据存储层中，在用户上线时再将頂消息推送到用 户的客户端； presub模块，用于在用户终端第一次连接MQTT代理服务器时，为用户预订阅话题； 用户身份认证模块，用于用户登录时的身份验证。3. 根据权利要求1所述的一种用于融合通信系统的消息引擎，其特征在于，所述消息引 擎采用MQTT协议，其消息格式包括消息头部和承载消息的payload部分； 如果该消息为頂消息，则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所述的一种用于融合通信系统的消息引擎，其特征在于，所述頂模块 采用頂话题的订阅/发布机制，通过MQTT代理服务器进行消息的推送，具体为： 每一个用户拥有一个IM话题，每一个用户的每个终端都订阅这个IM话题，每个用户的 每个终端都对应一个頂话题，对于每一个终端都订阅与之相对应的话题;在进行頂通信时， 发送方向接收方的頂话题上发送消息，然后MQTT代理服务器根据消息路由规则进行消息推 送，以实现消息的收发。7. 根据权利要求1所述的一种用于融合通信系统的消息引擎，其特征在于，所述 presence模块通过标记MQTT协议中的RETAIN来实现对用户状态消息的推送，具体为：规定 用户所有终端的主题均是按照QoS = 0的方式订阅，对于状态消息的发布，QoS = 0，retain = 1，以保证在新的用户状态消息到达MQTT代理服务器以后，所有旧的retain = l的状态消息 被MQTT代理服务器丢弃，只保留最新的状态消息。数据存储层8. 根据权利要求1所述的一种用于融合通信系统的消息引擎，其特征在于，所述用户身 份认证模块通过校验存放在MQTT代理服务器中的Redis数据库中的认证信息完成用户身份 认证。9. 根据权利要求1所述的一种用于融合通信系统的消息引擎，其特征在于，所述MQTT代 理服务器通过插件的方式配合用户身份认证模块完成用户身份认证;所述插件能够通过配 置文件、数据库的方式完成用户身份认证。10. 根据权利要求1所述的一种用于融合通信系统的消息引擎，其特征在于，所述数据 存储层包括MySQL数据库、LDAP数据库和Redis数据库;所述MySQL数据库用于存储頂消息、 presence消息;所述LDAP数据库用于存储用户信息;所述Redis数据库用于调取LDAP数据库 中的用户信息以完成用户身份认证模块对用户身份的认证。
【文档编号】H04L12/58GK106059892SQ201610327831
【公开日】2016年10月26日
【申请日】2016年5月17日
【发明人】于金刚, 耿云飞, 杨海波, 贾正锋
【申请人】中国科学院沈阳计算技术研究所有限公司