CN116827929A - 一种基于mqtt协议的通信***及通信方法 - Google Patents

Abstract

本发明提供了一种基于MQTT协议的通信***及通信方法，所述通信***包括MQTT‑Broker集群以及分别连接所述MQTT‑Broker集群的应用模块集群，MQTT‑Broker集群包括多个MQTT‑Broker模块；所述应用模块集群包括但不限于：第一应用模块、第二应用模块，所述第一应用模块和所述第二应用模块通过任一所述的MQTT‑Broker模块进行通信；所述第一应用模块包括但不限于：第一实例、第二实例，所述第二应用模块包括但不限于：第三实例、第四实例。

Description

一种基于MQTT协议的通信***及通信方法

技术领域

本发明涉及互联网平台技术开发和应用领域，尤其是一种基于MQTT5.0协议的互联网微服务通信***及通信方法。

背景技术

当前的互联网SaaS(数据即服务)产品，基本都是集群化部署，开发多采用微服务架构，而微服务架构就需要各个应用模块之间能够以一定的方式实施通信，而通信模型作为整个集群式微服务架构的重要一部分，是各个开发服务商迫切需要解决的难题。

HTTP这种后端无状态连接请求的通信模型，对于后端服务的业务***很容易做到弹性扩展，但是这种点对点的通信模型只能满足主动发起请求的情况，也就是只能是前端显示（客户端）主动向后端服务（服务端）发送请求，而后端服务（服务端）无法主动向前端显示（客户端）发送消息，因此无法实现发布订阅模型及功能以及点对多点的通信。

MQTT（消息队列遥测传输）是一个基于客户端-服务器的消息发布/订阅传输协议。MQTT协议是轻量、简单、开放和易于实现的，这些特点使它适用范围非常广泛。在很多情况下，包括受限的环境中，如：机器与机器（M2M）通信和物联网（IoT）。MQTT虽然解决了基于客户端-服务器的消息发布/订阅传输的问题，但是还是无法同时完成点对点，点对多点通信的问题。

发明内容

为解决以上现有技术存在的技术缺点，本发明提供了一种基于MQTT5.0协议的通信***和基于MQTT5.0协议的微服务通信方法。

一方面，本发明提供了一种基于MQTT5.0协议的通信***，包括MQTT-Broker集群以及分别连接所述MQTT-Broker集群的应用模块集群，MQTT-Broker集群包括多个MQTT-Broker模块；所述应用模块集群包括但不限于：第一应用模块、第二应用模块，所述第一应用模块和所述第二应用模块通过任一所述的MQTT-Broker模块进行通信；所述第一应用模块包括但不限于：第一实例、第二实例，所述第二应用模块包括但不限于：第三实例、第四实例。

上述第一应用模块的第一实例通过所述MQTT-Broker模块发布请求，通过所述MQTT-Broker模块订阅消息的所述第二应用模块接收所述请求并随机指定所述第三实例和所述第四实例任一处理所述请求。

上述应用模块集群具有一个或多个分组，所述第一应用模块和所述第二应用模块在同一分组中。

上述第一应用模块和所述第二应用模块来回通信的消息主题包括但不限于：分组标识、消息类型。

上述第一应用模块、所述第二应用模块、所述第一实例、所述第二实例、所述第三实例、所述第四实例分别具有各自标识，所述标识通过读取消息头识别并生成所述消息主题的一部分，所述消息头为JSON格式。

第二方面，本发明还提供了一种基于MQTT5.0协议的微服务通信方法，包括：配置MQTT-Broker集群以及分别连接所述MQTT-Broker集群的应用模块集群； 为所述应用模块配置消息主题；配置消息头格式；所述应用模块集群包括第一应用模块和第二应用模块，所述第一应用模块和所述第二应用模块通过任一所述的MQTT-Broker模块进行通信；所述第一应用模块包括但不限于：第一实例、第二实例，所述第二应用模块包括但不限于：第三实例、第四实例。

上述为所述应用模块配置消息主题包括：配置所述第一应用模块向所述MQTT-Broker模块发布请求时的消息主题为第一主题；配置所述第二应用模块从所述MQTT-Broker模块接收订阅消息的消息主题为第二主题；配置所述第二应用模块向所述MQTT-Broker模块发布返回包的消息主题为第三主题；配置所述第一应用模块从所述MQTT-Broker模块接收订阅的返回包的消息主题为第四主题；为所述消息主题配置分组标识以及消息类型。

当上述消息为发布状态时，无论是消息发布方还是消息接收方，配置其消息主题的内容及其权限为一致。

配置上述第二主题还包括第一应用模块标识和/或第二应用模块标识；配置上述第四主题还包括实例标识及其所属的应用模块标识。

配置消息头格式为JSON格式；所述第一应用模块标识、所述第二应用模块标识、所述实例标识通过读取所述消息头识别并生成所述消息主题的一部分。

本发明通过配置有多个实例的应用模块集群分别与所述MQTT模块通信， 不仅实现了基于客户端-服务器的消息发布/订阅传输功能，而且消息接收端的应用模块因为具有多个实例因此具有了支持负载均衡的功能，而且在接收消息时可以随机指定任一实例接收并处理所述请求消息。通过对通信过程各消息主题的针对性配置，不仅可以实现点对点的通信，还实现了点对多点的通信。

因此本发明提供的通信***同时实现了以下3种通信模型的优势：（1）发布订阅模型。也就是点对多通信模型，即支持消息发布者在某个主题上发布消息，以及消息接收者在某个主题上订阅消息，消息接收者的数量不受限制，可以有多个消息接收者来订阅相同的主题。（2）请求/响应模型。也就是点对点通信模型，并且有消息回复，是两个端点之间进行可靠性通信的基础。（3）子弹射击模型，是一种特殊的请求/响应模型，指的是消息发射出去不在关注对端是否处理或者什么时候处理完毕。至于是否要保证对端必须受到，则由MQTT协议的QoS（服务质量）所决定。

同时本发明通过给消息配置分组标识，解决了多个产品，同一个组下的应用模块能够通过权限配置互通，而不同组之间的数据是隔离的问题，

本发明提供的通信模型及通信方法，实现了后端服务（服务端）主动向前端显示（客户端）发送消息，进而实现了发布订阅功能以及点对多点的通信。本发明不仅仅适用于互联网SaaS集群化部署的多个微服务之间的通信，更能应用于物联网设备之间的通信。一端可以是服务端，另一端可以是设备端，对于设备端的客户端标识可以认为为设备标识或设备序列号，从而完成物联网通信模型。

附图说明

图1为本发明提供的一种基于MQTT5.0协议的通信***实施例之一的示意图；

图2为本发明提供的基于MQTT5.0协议的通信***实施例之二的示意图。

具体实施方式

在实施例1

本发明的提供了一种基于MQTT5.0协议的通信***，MQTT5.0协议的特点是：支持消息发布者在某个主题上发布消息，以及消息接收者在某个主题上订阅消息，消息接收者的数量不受限制，可以有多个消息接收者来订阅相同的主题。

如图1所示，所述通信模型包括：MQTT-Broker集群1以及连接所述MQTT-Broker集群的应用模块集群。所述MQTT-Broker集群1包括有多个MQTT-Broker模块（11，12，……,1n），按照MQTT5.0协议的要求执行内部通信。所述应用模块集群包括有多个应用模块，包括但不限于：第一应用模块21，第二应用模块22，第三应用模块23，第N应用模块2n。使用MQTT-Broker集群的优点是可以保证中继的可靠性。应用模块集群中的任何一个应用模块向其他任一应用模块发送消息，均通过所述MQTT-Broker集群进行转发。这样的好处就是全面利用了MQTT5.0协议的优势，使得每个应用模块都具有在某个主题上发布消息以及订阅消息的功能。订阅消息的应用模块数量不受限制，可以订阅相同的主题。

所述第一应用模块21拥有多个实例，如图2所示，所述第一应用模块21包括有第一实例211、第二实例212，第三实例213，第四实例214，以及第N实例21n。当所述第一应用模块21的任一实例发送消息时，所述MQTT-Broker集群中的任一MQTT-Broker模块例如MQTT-Broker模块11对所述消息进行转发。因为第一应用模块21具有多实例，接收所述消息的应用模块也应具有多实例，例如所述第二应用模块22可以接收来自所述第一应用模块21的第一实例211的消息，所述第二应用模块22具有第一实例221，第二实例222，第三实例223，第四实例224，第N实例22n。接收所述消息的应用模块具有多实例的优点在于实现负载均衡的效果，因为所述第一应用模块可能部署了多个副本，全部实例同时发布消息时，所述第二应用模块具有足够的实例用于接收所述全部消息。第二应用模块具有多实例的另一个好处是允许随机命中或按照某一算法命中所述第二应用模型的任一实例接收其他应用模块的任一实例发来的消息，实现了通信模型中的子弹射击模型和/或请求响应模型，具有负载大且适用范围广泛的优点。

整个通信过程实例如下：

所述第一应用模块21的第一实例211通过MQTT-Broker模块11发布了一个请求，所述第二应用模块22的第三实例223随机被命中处理所述请求，当所述第三实例223处理完所述请求后，将回应包通过MQTT-Broker模块11发回给所述第一应用模块21的第一实例211。

所述第一应用模块21和所述第二应用模块22的来回通信，每次来回通信都必须设有消息主题。所述消息主题都需要配置分组标识以及消息类型。所述消息类型包括请求和回应，以标识所述消息是请求（renquest）还是回应（response），以帮助***识别出一个完整的请求回应通信模型。所述分组标识是为了实现同一个分组下的应用模块应当能够互通，同一个应用模块集群内部，应当使用一个分组来建立通信。所述分组标识就是用于标记同一个应用模块集群的关系的，以便于快速建立通信联系。例如所述第一应用模块和所述第二应用模块分别在一个标识为e38的组中,因此分组标识为e38就将所述第一应用模块和所述第二应用模块分组隔离在一起，因为在同一个分组，因此第一应用模块和第二应用模块可以建立通信。并且保证了在同一个MQTT转发器上的共享订阅包根据分组标识实施分组隔离，非同一个分组的应用模块则不可以访问所述消息，按分组标识实现数据隔离。每个业务***都需要申请一个唯一的分组标识以保证数据的可读范围。

当所述消息为发布状态时，无论是消息发布方还是消息接收方，其消息主题的权限配置都是一样的。例如，当所述第一应用模块21的第一实例211发布请求消息，此时所述第一应用模块和所述第二应用模块的消息主题权限都是包括分组标识e38，其消息类型为请求。当所述第二应用模块22的第三实例223发布回应包时，此时所述第一应用模块和所述第二应用模块的消息主题权限都是包括分组标识e38，其消息类型为回应。

当所述消息为订阅状态时，消息发布方和消息接收方的消息主题权限配置略有不同。例如，当所述第二应用模块22的第三实例223被随机选中接收来自所述第一应用模块21的订阅消息时，所述第二应用模块22接收的消息主题还包括：第二应用模块22的标识。所述第一应用模块21接收的消息主题还包括第一应用模块的标识。当所述第一应用模块21的第一实例211接收来自所述第二应用模块22的第三实例223的回应包时，所述第一应用模块21接收的消息主题还包括第一应用模块21的标识和第一实例211的标识。同时，所述第二应用模块22接收的消息主题还包括第二应用模块22的标识和第三实例223的标识。这样做的好处就是消息主题就直接显示所述消息来自哪里去往哪里。

对于整个消息体，可以定义成JSON格式，也可以定义为其他格式。消息分为两部分：消息头和消息体。消息头我们定义成一个对象，而消息体可以是对象，也可以是数组，具体根据消息头中描述的实际业务。

其中各个通信过程中的各个应用模块标识和实例标识通过消息内容的消息头识别获取。

本发明弥补了MQTT协议只有发布/订阅功能，而无法完成点对点通信的问题，解决了***设计的难点。尤其是在互联网SaaS集群化部署多个微服务的背景下，解决了整个***通信设计的难点，增加了***的可靠性和稳定性，同时实现了点对多点通信的问题。

实施例2

本实施例提供了一种基于MQTT5.0协议的微服务通信方法，用于配置实现上述实施例1的通信***。所述方法包括：

S100, 配置MQTT-Broker集群1以及分别连接所述MQTT-Broker集群的应用模块集群。

所述MQTT-Broker集群1包括有多个MQTT-Broker模块（11，12，……,1n），按照MQTT5.0协议的要求执行内部通信。所述应用模块集群包括有多个应用模块，包括但不限于：第一应用模块21，第二应用模块22，第三应用模块23，第N应用模块2n。使用MQTT-Broker集群的优点是可以保证中继的可靠性。应用模块集群中的任何一个应用模块向其他任一应用模块发送消息，均通过所述MQTT-Broker集群进行转发。

所述第一应用模块21拥有多个实例，如图2所示，所述第一应用模块21包括有第一实例211、第二实例212，第三实例213，第四实例214，以及第N实例21n。当所述第一应用模块21的任一实例发送消息时，所述MQTT-Broker集群中的任一MQTT-Broker模块例如MQTT-Broker模块11对所述消息进行转发。因为第一应用模块21具有多实例，接收所述消息的应用模块也应具有多实例，例如所述第二应用模块22可以接收来自所述第一应用模块21的第一实例211的消息，所述第二应用模块22具有第一实例221，第二实例222，第三实例223，第四实例224，第N实例22n。接收所述消息的应用模块具有多个实例的优点在于实现负载均衡的效果，因为所述第一应用模块可能部署了多个副本，全部实例同时发布消息时，所述第二应用模块具有足够的实例用于接收所述全部消息。第二应用模块具有多实例的另一个好处是允许随机命中或按照某个算法命中所述第二应用模块的任一实例来实现负载均衡。实现了通信模型中的子弹射击模型或请求响应模型，具有负载大且适用范围广泛的优点。

当所述第一应用模块的任一实例发布请求时，所述第二应用模块的任一实例被随机选中处理所述请求并将回复包发回给发布所述请求的所述第一应用模块的实例。例如，所述第一应用模块21的第一实例211通过MQTT-Broker模块11发布了一个请求，所述第二应用模块22的第四实例224随机被命中处理所述请求，当所述第二实例22处理完所述请求后，将回应包通过MQTT-Broker模块11发回给所述第一应用模块21的第一实例211。

S200，为所述应用模块配置消息主题：

配置所述第一应用模块21向所述MQTT-Broker模块11发布请求时的消息主题为第一主题；

配置所述第二应用模块22从所述MQTT-Broker模块11接收订阅消息的消息主题为第二主题；

配置所述第二应用模块22向所述MQTT-Broker模块11发布返回包的消息主题为第三主题；

配置所述第一应用模块21从所述MQTT-Broker模块11接收订阅的返回包的消息主题为第四主题。

S210，为所述消息主题配置分组标识以及消息类型。

所述消息类型包括请求和回应，以标识所述消息是请求（renquest）还是回应（response），以帮助***识别出一个完整的请求回应通信模型。所述分组标识是为了实现同一个分组下的应用模块应当能够互通，同一个应用模块集群内部，应当使用一个分组来建立通信。所述分组标识就是用于标记同一个应用模块集群的关系的，以便于快速建立通信联系。例如所述第一应用模块和所述第二应用模块分别在一个标识为e38的组中,因此分组标识为e38就将所述第一应用模块和所述第二应用模块分组隔离在一起，因为在同一个分组，因此第一应用模块和第二应用模块可以建立通信。并且保证了在同一个MQTT转发器上的共享订阅包根据分组标识实施分组隔离，每个业务***都需要申请一个唯一的分组标识。

S220, 当所述消息为发布状态时，无论是消息发布方还是消息接收方，配置其消息主题的内容及其权限为一致。

例如，所述第一主题31的内容及其权限都包括包括分组标识e38，其消息类型为请求。所述第三主题33的权限包括分组标识e38，其消息类型为回应。

S230, 配置所述第二主题还包括发送方标识和/或接收方标识。

当所述第二应用模块接收发送来的订阅消息时，所述第二消息主题32包括分组标识e38和所述消息为“订阅”的消息类型，还包括一个包含随机选中的指令，用于指示接收方的配置应当能够支持负载均衡。还包括所述第一应用模块标识和/或第二应用模块标识。以便于对应的第一应用模块和/或第二应用模块根据所述第二消息主题32放置对应的地址进行处理。

S240,配置所述第四主题还包括发送方和/或接收方的实例标识及其所属的应用模块标识。

例如，当所述第一应用模块21的第一实例211接收来自所述第二应用模块22的第二实例222的回应包时，所述第一应用模块21接收的消息主题还包括第一应用模块21的标识和第一实例211的标识。同时，所述第二应用模块22接收的消息主题还包括第二应用模块22的标识和第四实例224的标识。这样做的好处就是消息主题就直接显示所述消息来自哪里去往哪里。

S300，配置消息头格式。

对于整个消息体，可以定义成JSON格式，也可以定义为其他格式。消息分为两部分：消息头和消息体。消息头我们定义成一个对象，而消息体可以是对象，也可以是数组，具体根据消息头中描述的实际业务。其中各个通信过程中的各个应用模块标识和实例标识通过消息内容的消息头识别获取。

S400，根据以上配置，执行通信流程及服务。

实施例3

本发明还提供了另一种基于实施例1和实施例2基础上的微服务通信方法实施例，所述方法包括：

当第一应用模块21的第一实例211需要发送请求包时，可以在消息主题中设置分组标识以及消息类型，所述消息类型为发送。还可以在消息主题中设置目标应用模块（如所述第二应用模块）的标识，和/或具体的实例标识。也可以不设置具体的实例标识，由目标应用模块（如所述第二应用模块）的任意实例随机命中并处理。所述消息主题还包括发送者标识，对端解析所述发送者标识，就可以把消息精确的回应给发送者。例如所述第一应用模块发送的消息主题还包括有第一应用模块标识21和/或第一实例标识211，所述第二应用模块22对所述第一应用模块标识21和/或所述第一实例标识211进行解析，当所述第二应用模块实例22处理完消息后，将回应包精准回应给所述第一应用模块的第一实例211。

当对端（如所述第二应用模块）接收发送的订阅信息，解析所述主题，看到所述目标应用模块标识（即第二应用模块标识），就知道是发给自己的消息，随机生成实例标识（例如所述第二应用模块的第四实例），根据所述目标应用模块标识和第四实例标识组合出回应包，并发布出去。也可以直接通过分组标识和消息主题（如回应）的形式发布所述回应包。因为所述第二应用模块和所述第一应用模块同处一个共享分组，因此共享分组标识就已经保证了在同一个MQTT转发器上的共享订阅数据包已被分组隔离，且组内消息可以实现通信分享。因此通过分组标识和回应就已经得知了回应包的目的地。由于第一应用模块可能会是部署多个副本，具有多个实例，因此回应包需要配置成共享订阅模式，以达到复杂均衡的效果，否则所述第一应用模块的多个副本或多个实例则同时会收到消息，从而引发逻辑错乱。

第二主题的发送端和接收端的主题权限各不相同，例如发送端的主题权限包括发送端标识，例如第一应用模块标识。接收端的主题权限包括接收端标识，例如第二应用模块标识。

第三主题还可以包括对端的应用模块标识（即第一应用模块标识）和对端应用模块实例标识（即第一应用模块的第一实例），这样对端（即第一应用模块的第一实例）直接接收回应包。

第四主题配置成订阅模式。用来接收所述第一应用模块请求的回应包，其中主题包括自己标识（即第一应用模块标识）和实例标识（即第一应用模块的第一实例）。

第四主题中，所述第一应用模块和第二应用模块的主题权限各不相同，例如第一应用模块的主题权限包括第一应用模块标识和第一应用模块的第一实例的标识。所述第二应用模块的主题权限包括第二应用模块标识和第二应用模块的第四实例的标识。

对于消息体，可以定义成JSON格式，也可以定义为其他格式。消息分为两部分：消息头和消息体。消息头我们定义成一个对象，而消息体可以是对象，也可以是数组，具体根据消息头中描述的实际业务。

其中各个步骤中的应用模块标识和实例标识通过消息内容的消息头识别获取。

本发明提供的通信模型，还解决了多个产品，同一个组下的应用能够通过权限配置互通，而不同组之间的数据是隔离的。

本发明提供的通信模型，同时实现了以下3种模型的优势：

（1）发布订阅模型。也就是点对多通信模型，即支持消息发布者在某个主题上发布消息，以及消息接收者在某个主题上订阅消息，消息接收者的数量不受限制，可以有多个消息接收者来订阅相同的主题。

（2）请求/响应模型。也就是点对点通信模型，并且有消息回复，是两个端点之间进行可靠性通信的基础。

（3）子弹射击模型，是一种特殊的请求/响应模型，指的是消息发射出去不在关注对端是否处理或者什么时候处理完毕。至于是否要保证对端必须受到，则由MQTT协议的QoS（服务质量）所决定。

本发明提供的通信模型及通信方法，实现了后端服务（服务端）主动向前端显示（客户端）发送消息，进而实现了发布订阅功能以及点对多点的通信。本发明不仅仅适用于互联网SaaS集群化部署的多个微服务之间的通信，更能应用于物联网设备之间的通信。一端可以是服务端，另一端可以是设备端，对于设备端的客户端标识可以认为为设备标识或设备序列号，从而完成物联网通信模型。

本发明弥补了MQTT协议只有发布/订阅功能，而无法完成点对点通信的问题，解决了***设计的难点。尤其是在互联网SaaS集群化部署多个微服务的背景下，解决了整个***通信设计的难点，增加了***的可靠性和稳定性，同时实现了点对多点通信的问题。

本领域普通技术人员可以理解以上实施例仅为本发明创造思想下之一部分，任何人在以上实施例基础上轻易就能联想到的技术方案都是本发明的一部分。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，所述的程序可以存储于一计算机可读取存储介质中，所述的存储介质，如：ROM/RAM、磁碟、光盘、云服务器等。

以上仅为本发明的优选实施例而已，并不限于本发明的文字描述，对于本领域的技术人员来说，本发明可以有各种更改和变化，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种基于MQTT协议的通信***，其特征在于，包括MQTT-Broker集群以及分别连接所述MQTT-Broker集群的应用模块集群，MQTT-Broker集群包括多个MQTT-Broker模块；

所述应用模块集群包括但不限于：第一应用模块、第二应用模块，所述第一应用模块和所述第二应用模块通过任一所述的MQTT-Broker模块进行通信；

所述第一应用模块包括但不限于：第一实例、第二实例，所述第二应用模块包括但不限于：第三实例、第四实例。

2.根据权利要求1所述的通信***，其特征在于，所述第一应用模块的第一实例通过所述MQTT-Broker模块发布请求，通过所述MQTT-Broker模块订阅消息的所述第二应用模块接收所述请求并随机指定所述第三实例和所述第四实例任一处理所述请求。

3.根据权利要求1所述的通信***，其特征在于，所述应用模块集群具有一个或多个分组，所述第一应用模块和所述第二应用模块在同一分组中。

4.根据权利要求1-3任一所述的通信***，其特征在于，所述第一应用模块和所述第二应用模块来回通信的消息主题包括但不限于：分组标识、消息类型。

5.根据权利要求4所述的通信***，其特征在于，所述第一应用模块、所述第二应用模块、所述第一实例、所述第二实例、所述第三实例、所述第四实例分别具有各自标识，所述标识通过读取消息头识别并生成所述消息主题的一部分，所述消息头为JSON格式。

6.一种基于MQTT协议的微服务通信方法，其特征在于，所述方法包括：

配置MQTT-Broker集群以及分别连接所述MQTT-Broker集群的应用模块集群；

为所述应用模块配置消息主题；

配置消息头格式；

所述应用模块集群包括第一应用模块和第二应用模块，所述第一应用模块和所述第二应用模块通过任一所述的MQTT-Broker模块进行通信；

所述第一应用模块包括但不限于：第一实例、第二实例，所述第二应用模块包括但不限于：第三实例、第四实例。

7.根据权利要求6所述的通信方法，其特征在于，所述为所述应用模块配置消息主题包括：

配置所述第一应用模块向所述MQTT-Broker模块发布请求时的消息主题为第一主题；

配置所述第二应用模块从所述MQTT-Broker模块接收订阅消息的消息主题为第二主题；

配置所述第二应用模块向所述MQTT-Broker模块发布返回包的消息主题为第三主题；

配置所述第一应用模块从所述MQTT-Broker模块接收订阅的返回包的消息主题为第四主题；

为所述消息主题配置分组标识以及消息类型。

8.根据权利要求7所述的通信方法，其特征在于，当所述消息为发布状态时，无论是消息发布方还是消息接收方，配置其消息主题的内容及其权限为一致。

9.根据权利要求7所述的通信方法，其特征在于，配置所述第二主题还包括第一应用模块标识和/或第二应用模块标识；

配置所述第四主题还包括实例标识及其所属的应用模块标识。

10.根据权利要求9所述的通信方法，其特征在于，配置消息头格式为JSON格式；所述第一应用模块标识、所述第二应用模块标识、所述实例标识通过读取所述消息头识别并生成所述消息主题的一部分。