CN111917770B - 设备通信方法、装置、设备及存储介质 - Google Patents

Abstract

本公开实施例提供一种设备通信方法、装置、设备及存储介质。该方法包括：响应于用于指示发送消息的触发操作，获取所述消息对应的目标业务数据；获取预定义的通用消息体，根据所述目标业务数据，通过Protocol Buffers对所述通用消息体进行填充，得到目标业务消息体；将所述目标业务消息体通过Protocol Buffers填充至MQTT协议的报文体中，生成数据包；将所述数据包通过MQTT协议发送至消息接收方，以使所述消息接收方解析所述数据包并根据解析得到的所述目标业务数据执行相应的操作。本公开实施例能够解决现有技术无法有效地实现设备通信的问题。

Description

设备通信方法、装置、设备及存储介质

技术领域

本公开实施例涉及通信技术领域，尤其涉及一种设备通信方法、装置、设备及存储介质。

背景技术

在车上装上车载记录仪以后，远程控制车载记录仪进行信息上报，视频文件上传，看实时的视频直播等需求越来越多。因此，设备之间的通信尤为重要。

常见的，有一部分通信协议是基于自己定义的私有通信协议；还有一部分通信协议是基于消息队列遥测传输协议(Message Queuing Telemetry Transport，MQTT)，MQTT协议是一种基于发布/订阅(publish/subscribe)模式的“轻量级”通讯协议，该协议构建于TCP/IP协议上，MQTT最大优点在于，可以以极少的代码和有限的带宽，为连接远程设备提供实时可靠的消息服务。

但是，基于自己定义的私有通信协议，不透明，开发和维护成本都比较高；针对MQTT协议，数据的封装和解析比较复杂，封装和解析工作量大、容易出错，而且不容易扩展。因此，现有技术无法有效地实现设备通信。

发明内容

本公开实施例提供一种设备通信方法、装置、设备及存储介质，能够解决现有技术无法有效地实现设备通信的问题。

第一方面，本公开实施例提供一种设备通信方法，包括：响应于用于指示发送消息的触发操作，获取所述消息对应的目标业务数据；获取预定义的通用消息体，根据所述目标业务数据，通过Protocol Buffers对所述通用消息体进行填充，得到目标业务消息体；将所述目标业务消息体通过Protocol Buffers填充至MQTT协议的报文体中，生成数据包；将所述数据包通过MQTT协议发送至消息接收方，以使所述消息接收方解析所述数据包并根据解析得到的所述目标业务数据执行相应的操作。

第二方面，本公开实施例提供一种设备通信方法，包括：获取消息发送方通过MQTT协议发送的数据包；获取通过Protocol Buffers解析得到所述数据包的目标业务消息体；获取预定义的通用消息体，根据所述通用消息体以及所述目标业务消息体，确定目标业务数据。

第三方面，本公开实施例提供一种设备通信装置，包括：获取模块，用于响应于用于指示发送消息的触发操作，获取所述消息对应的目标业务数据；第一处理模块，用于获取预定义的通用消息体，根据所述目标业务数据，通过Protocol Buffers对所述通用消息体进行填充，得到目标业务消息体；所述第一处理模块，还用于将所述目标业务消息体通过Protocol Buffers填充至MQTT协议的报文体中，生成数据包；消息发送模块，用于将所述数据包通过MQTT协议发送至消息接收方，以使所述消息接收方解析所述数据包并根据解析得到的所述目标业务数据执行相应的操作。

第四方面，本公开实施例提供一种设备通信装置，包括：获取模块，用于获取发送方通过MQTT协议发送的数据包；第一处理模块，用于获取通过Protocol Buffers解析得到所述数据包的目标业务消息体；所述第一处理模块，还用于获取预定义的通用消息体，根据所述通用消息体以及所述目标业务消息体，确定目标业务数据。

第五方面，本公开实施例提供一种电子设备，包括：

存储器；

处理器；以及

计算机程序；

其中，所述计算机程序存储在所述存储器中，并被配置为由所述处理器执行以实现如第一方面、第二方面所述的方法。

第六方面，本公开实施例提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行以实现第一方面、第二方面所述的方法。

本公开实施例提供的设备通信方法、装置、设备及存储介质，响应于用于指示发送消息的触发操作，获取该消息对应的目标业务数据；获取预定义的通用消息体，结合目标业务数据，通过Protocol Buffers对所述通用消息体进行填充，得到目标业务消息体，因此通用消息体提供了便于扩展的框架，使用目标业务数据对通用消息体填充的方式能够扩展出不同的目标业务消息体，并且将所述目标业务消息体通过Protocol Buffers填充至MQTT协议的报文体中，生成数据包，将所述数据包通过MQTT协议发送至消息接收方，以使所述消息接收方解析所述数据包并根据解析得到的所述目标业务数据执行相应的操作，通过Protocol Buffers填充使得数据封装简单，相应的解析工作量也降低了，且针对设备的通信采用MQTT协议，能够为连接远程设备提供实时可靠的消息服务。因此，在网络传输协议上，使用MQTT协议，在数据封装协议上，使用Protocol Buffers，既方便了扩展，又提供实时可靠的消息服务，同时降低了数据封装、解析上的复杂性，有效地实现了设备的通信。

附图说明

图1为本公开实施例提供的设备通信方法的应用场景示意图；

图2为本公开实施例提供的设备通信方法的流程示意图；

图3为本公开另一实施例提供的设备通信方法的流程示意图；

图4为本公开又一实施例提供的设备通信方法的流程示意图；

图5为本公开实施例提供的设备通信装置的结构示意图；

图6为本公开另一实施例提供的设备通信装置的结构示意图；

图7为本公开实施例提供的电子设备的结构示意图。

通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

现有技术中，基于自己定义的私有通信协议，不透明，开发和维护成本都比较高；针对MQTT协议，数据的封装和解析比较复杂，封装和解析工作量大、容易出错，而且不容易扩展。因此，现有技术的通信协议不便于扩展，且数据封装、解析较为复杂，进而无法有效地实现通信。

为了解决上述技术问题，本公开的技术构思是在网络传输协议上，使用MQTT协议，在数据封装协议上，使用Protocol Buffers，能够降低数据封装、解析的复杂性，且在数据体传输时，定义一个通用的消息上行和下行的消息体，对要传输的消息内容进行二次封装，增加消息检验和加密，既方便了扩展，又保证了安全性。

图1是本公开实施例提供的设备通信方法的应用场景示意图。如图1所示，该场景包括：终端设备10和服务器20；其中，这里的终端设备可以是车载设备，用户可以通过车载设备上报或回应所在位置、心跳、心率等业务数据给服务器，服务器也可以向车载设备发送相应的回应消息或是具体业务。具体地，在车载设备上使用MQTT+Protocol Buffers的组合方案，对上行下行消息，定义外层的通用消息体，和具体业务分离，用来解决不同业务调用的问题以及加密，压缩，校验等问题，不仅方便扩展，还保证了安全性，同时针对ProtocolBuffers的使用，Protocol Buffers是一种语言无关、平台无关、可扩展的序列化结构数据的方法，它可用于(数据)通信协议、数据存储等，定义数据的结构，然后使用特殊生成的源代码轻松的在各种数据流中使用各种语言进行编写和读取结构数据，解决了基于MQTT协议的数据的封装和解析比较复杂，封装和解析工作量大容易出错的问题，有效地实现了设备的通信。

在一种场景下，新增一个功能：车载设备向服务器上报自己的GPS信息。

通过Protocol Buffers新定义一个和该业务相关的消息体即ReportGpsInfoRequest消息体，包括当前时间和位置信息分别对应的字段，车载设备创建这个ReportGpsInfoRequest消息体，对数据进行相应的填充，然后把这个对象，填充到外层的RpcMessage(即通用消息体)的data(即对应具体的业务对象)字段里，最后通过ProtocolBuffers把RpcMessage填充到MQTT的报文体里面，发送到服务器；服务器收到消息以后，取出报文体,转换成RpcMessage对象，根据RPC调用的方法名(method)，解析出ReportGpsInfoRequest，就得到了服务器要上报的具体数据。因此，服务器在配置里增加这个对象，不需要额外的开发工作。

上述MQTT+Protocol Buffers的组合方案，还可以对接到不同的服务器平台：对接到不同的服务器平台，只需要把定义的这些Protocol Buffers文件拿出来，在服务器上加上对这些Protocol Buffers的支持即可，开发工作量非常小。还可以迁移到不同的硬件设备：迁移到不同的硬件设备，只需要把定义的这些Protocol Buffers重新编译即可，工作量也非常小。

具体地，本公开实施例提供的设备通信方法，旨在解决现有技术的如上技术问题。

下面以具体地实施例对本公开的技术方案以及本公开的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本公开的实施例进行描述。

图2为本公开实施例提供的设备通信方法的流程示意图。本公开实施例针对现有技术的如上技术问题，提供了设备通信方法，该方法具体步骤如下：

S201、响应于用于指示发送消息的触发操作，获取所述消息对应的目标业务数据。

本公开实施例的执行主体可以为终端设备也可以为服务器，即终端设备或服务器既可以作为消息发送方也可以作为消息接收方，在此不做具体限定。

本公开实施例中，这个触发操作可以是主动上报信息的触发操作也可以是回应接收到的消息的触发操作，不同的触发操作的类型，在对通用消息体进行填充的具体数据不同。

具体地，无论是作用于终端设备上的触发操作还是作用于服务器上的触发操作，均可以根据该触发操作，来获取待发送出去的消息所对应的目标业务数据，这里的目标业务数据可以包括具体的业务，比如上报或获取GPS定位信息、心率、心跳等业务数据。该具体的业务可以作为待扩展的功能。

S202、获取预定义的通用消息体，根据所述目标业务数据，通过Protocol Buffers对所述通用消息体进行填充，得到目标业务消息体。

本公开实施例中，预定义一个通用消息体，便于业务扩展。基于获得到目标业务数据，通过Protocol Buffers对通用消息体进行填充，得到目标业务消息体，即扩展的与具体业务相关的消息体。这里的

S203、将所述目标业务消息体通过Protocol Buffers填充至MQTT协议的报文体中，生成数据包。

本公开实施例中，通过Protocol Buffers，将目标业务消息体填充至MQTT协议的报文体中，实现数据的封装，且对数据的解析工作量降低。该种方式不仅方便了扩展还降低了基于MQTT协议对数据封装解析的复杂度。

S204、将所述数据包通过MQTT协议发送至消息接收方，以使所述消息接收方解析所述数据包并根据解析得到的所述目标业务数据执行相应的操作。

本公开实施例中，在网络传输协议上，使用MQTT协议，可以以极少的代码和有限的带宽，为连接远程设备提供实时可靠的消息服务，因此，通过MQTT协议将所述数据包发送至消息接收方。其中，消息接收方消息接收方为终端设备或服务器，比如，消息发送方是终端设备，消息接收方是服务器；消息发送方是服务器，消息接收方是终端设备。这里终端设备至少包括车载设备。

通过MQTT协议实现终端设备和服务器之间的消息传输。其中，对报文体使用Protocol Buffers进行定义和填充等，便于数据封装和解析，因此，将数据包通过MQTT协议发送至消息接收方后，消息接收方接收到数据包后可以通过Protocol Buffers解析该数据包并根据解析得到的目标业务数据执行相应的操作，使用Protocol Buffers便于解析，降低了解析的工作量。

本公开实施例提供的设备通信方法，通过响应于用于指示发送消息的触发操作，获取该消息对应的目标业务数据；获取预定义的通用消息体，结合目标业务数据，通过Protocol Buffers对所述通用消息体进行填充，得到目标业务消息体，因此通用消息体提供了便于扩展的框架，使用目标业务数据对通用消息体填充的方式能够扩展出不同的目标业务消息体，并且将所述目标业务消息体通过Protocol Buffers填充至MQTT协议的报文体中，生成数据包，将所述数据包通过MQTT协议发送至消息接收方，以使所述消息接收方解析所述数据包并根据解析得到的所述目标业务数据执行相应的操作，通过Protocol Buffers填充使得数据封装简单，相应的解析工作量也降低了，且针对设备的通信采用MQTT协议，能够为连接远程设备提供实时可靠的消息服务。因此，在网络传输协议上，使用MQTT协议，在数据封装协议上，使用Protocol Buffers，既方便了扩展，又提供实时可靠的消息服务，同时降低了数据封装、解析上的复杂性。

如何基于通用消息体，扩展成目标业务消息体，可以参见图3，图3为本公开另一实施例提供的设备通信方法的流程示意图。本公开实施例在上述实施例的基础上，例如在图2所述的实施例的基础上，对步骤S202进行了详细说明。其中，通用消息体包括封装特征字段以及业务数据字段。所述根据所述目标业务数据，通过Protocol Buffers对所述通用消息体进行填充，得到目标业务消息体，可以包括：

S301、根据所述触发操作的类型和所述目标业务数据，通过Protocol Buffers对所述封装特征字段进行填充，根据所述目标业务数据，通过Protocol Buffers对所述业务数据字段进行填充，得到第一消息体。

本公开实施例中，触发操作的类型可以为通知操作类型或回应操作类型。这里的通知操作类型可以为主动上报信息的操作，回应操作类型可以为接收到消息后进行回应的操作。

具体地，结合触发操作的类型，基于目标业务数据，通过Protocol Buffers对封装特征字段进行填充，这里的封装特征字段至少包含消息ID字段、压缩方式字段、加密方式字段、调用的方法名称字段、消息发生时间字段、业务操作字段。同时，基于目标业务数据，通过Protocol Buffers对所述业务数据字段进行填充，将业务数据字段填充为具体业务。填充完以后，生成了第一消息体。为了便于扩展，预定义的通用消息体封装特征字段与所述业务数据字段分离，即消息本身的特征数据与具体业务分离。

S302、通过Protocol Buffers对所述第一消息体进行序列化，得到目标业务消息体。

本公开实施例中，序列化是将对象的状态信息转换为可以存储或传输的形式的过程。在序列化期间，对象将其当前状态写入到临时或持久性存储区。以后，可以通过从存储区中读取或反序列化对象的状态，重新创建该对象。因此，填充完以后为了便于存储或传输，可以通过Protocol Buffers对所述第一消息体进行序列化，序列化后的第一消息体即为目标业务消息体。

可选的，本公开实施例在上述实施例的基础上，对如何对业务数据字段进行填充进行了详细说明。所述根据所述目标业务数据，通过Protocol Buffers对所述业务数据字段进行填充，可以通过以下步骤实现：

步骤a1、通过Protocol Buffers，生成与所述目标业务数据相关联的目标消息体。

本公开实施例中，根据获取的目标业务数据，通过Protocol Buffers定义一个与该目标业务数据相关的目标消息体。比如，车载设备向服务器上报自身的GPS信息这一业务作为目标业务，目标业务数据包括GPS信息等，通过Protocol Buffers创建一个与该目标业务相关的消息体即ReportGpsInfoRequest消息体。该ReportGpsInfoRequest消息体中可以包含当前时间字段、具体业务字段。

可选的，如何生成与所述目标业务数据相关联的目标消息体，可以通过以下步骤实现：

步骤b1、通过Protocol Buffers，生成当前时间字段。

步骤b2、根据所述目标业务数据，通过Protocol Buffers，生成目标业务数据字段。

步骤b3、根据所述当前时间字段和所述目标业务数据字段，生成所述目标消息体。

本公开实施例中，可以使用Protocol Buffers定义当前时间字段，根据目标业务数据，使用Protocol Buffers定义目标业务数据字段，由当前时间字段和目标业务数据字段构成一个与该目标业务数据相关的消息体即目标消息体。

其中，这里的目标业务数据字段是与具体业务相关的字段，以上述ReportGpsInfoRequest消息体为例，目标业务数据字段即为位置信息字段。

具体地，根据获取的目标业务数据，通过Protocol Buffers定义一个与该目标业务数据相关的目标消息体。比如，车载设备向服务器上报自身的GPS信息这一业务作为目标业务，目标业务数据包括GPS信息等，通过Protocol Buffers创建一个与该目标业务相关的消息体即ReportGpsInfoRequest消息体，该ReportGpsInfoRequest消息体中至少可以包含当前时间字段和位置信息字段，然后对创建好的ReportGpsInfoRequest消息体进行数据填充。

步骤a2、根据所述目标业务数据和所述目标消息体，通过Protocol Buffers对所述业务数据字段进行填充。

本公开实施例中，通过具体的目标业务数据结合该目标消息体，使用ProtocolBuffers对通用消息体进行填充，这里可以具体对通用消息体中的业务数据字段进行填充。

可选的，在生成目标消息体后，进行数据填充，步骤a2可以通过下述步骤实现：

1)获取当前时间；2)将所述当前时间和所述目标业务数据通过Protocol Buffers填充至所述目标消息体中，得到第一对象；3)根据所述第一对象，通过Protocol Buffers对所述业务数据字段进行填充。

本公开实施例中，实时获取当前时间，将当前时间和所述目标业务数据通过Protocol Buffers填充至所述目标消息体中，得到第一对象，然后将第一对象使用Protocol Buffers填充至通用消息体中的业务数据字段中，同时对通用消息体的其他字段进行数据填充，然后将填充号的通用消息体使用Protocol Buffers填充至报文体中，生成数据包。对要传输的消息内容进行二次封装，增加消息检验和加密，既方便了扩展，又保证了安全性。

可选的，如何得到第一对象，可以包括：

根据所述当前时间和所述目标业务数据，通过Protocol Buffers对所述目标消息体中的当前时间字段和所述目标业务数据字段进行相应的填充，通过Protocol Buffers对填充后的目标消息体进行序列化，得到所述第一对象。

本公开实施例中，将获取到的当前时间使用Protocol Buffers填充至目标消息体的当前时间字段中，同时，将目标业务数据，比如位置信息、心跳数据、心率数据使用Protocol Buffers填充至目标消息体的目标业务数据字段，比如位置信息字段、心跳信息字段、心率信息字段。

将该当前时间和目标业务数据通过Protocol Buffers填充至目标消息体中之后，对填充后的目标消息体使用Protocol Buffers实现序列化，得到第一对象。然后以第一对象为具体业务对象，填充至通用消息体中的目标业务数据字段中，实现了协议上的扩展，可以增加任意新功能。

可选的，如何通过Protocol Buffers对所述封装特征字段进行填充，可以通过以下步骤实现：

步骤c1、获取所述触发操作的类型。

步骤c2、获取所述目标业务数据的关联信息，所述关联信息至少包括消息发送方ID、消息接收方ID、压缩方式、加密方式、调用的方法名称、消息发生时间、业务操作类型，所述业务操作类型与所述触发操作的类型一致。

步骤c3、根据所述关联信息和所述触发操作的类型，通过Protocol Buffers对所述封装特征字段进行填充。

本公开实施例中，预定义的通用消息体中包含封装特征字段和业务数据字段，且封装特征字段与所述业务数据字段分离，因此，可以任意扩展功能。其中，封装特征字段中至少包含消息ID字段、压缩方式字段、加密方式字段、调用的方法名称字段、消息发生时间字段、业务操作字段。为了能够实现通用消息体的数据填充，可以获取与目标业务数据相关联的关联信息，即待填充的封装特征数据：消息发送方ID、消息接收方ID、压缩方式、加密方式、调用的方法名称、消息发生时间、业务操作类型。其中，这里的业务操作类型与触发操作的类型是一致的，即触发操作的类型决定了封装特征字段中业务操作类型字段的具体数据。此外，消息ID字段中可以包括消息发送方ID字段和消息接收方ID字段。

可选的，本公开实施例在上述实施例的基础上，对步骤c3进行了详细说明。根据所述关联信息和所述触发操作的类型，通过Protocol Buffers对所述封装特征字段进行填充，可以包括：

将所述消息发送方ID、消息接收方ID、压缩方式、加密方式、调用的方法名称、消息发生时间、所述触发操作的类型通过Protocol Buffers对应填充至所述封装特征字段中。

具体地，使用Protocol Buffers将消息发送方ID和消息接收方ID对应填充至消息ID字段中，将压缩方式填充至压缩方式字段中，将加密方式填充至加密方式字段中，将调用的方法名称填充至调用的方法名称字段中，将消息发生时间填充至消息发生时间字段中，将触发操作的类型填充至业务操作字段中。再结合上述将第一对象填充至通用消息体中的业务数据字段中之后，对填充好的通用消息体即第一消息体使用Protocol Buffers进行序列化，得到目标业务消息体。然后将目标业务消息体填充至MQTT协议的报文体中，生成数据包，实现数据的多次封装，增加消息检验和加密，既方便了扩展，又保证了安全性。

在实际应用中，针对报文体的填充，现有技术可以通过两种方式实现：方式一、可以使用自定义的数据格式，需要按照固定的规则，按照byte顺序进行封装和解析，工作量大；方式二、可以使用json和xml进行填充，数据压缩率比较低，解析效率也比较低。因此，以上两种方式，只适合设备端简单的数据上报，无法做到设备端发送请求服务器回应，或者服务器请求设备端，设备端回应这样的机制。而本公开中预定义的通用消息体中包含业务操作字段，比如该消息的传输是属于通知操作类型还是回应操作类型，通过该业务操作字段，可以实现设备端、服务器的回应机制。

本公开是对报文体使用Protocol Buffers进行定义和填充，针对上行消息和下行消息两种场景均适用：定义一个外层的“消息盒子”，包含了消息ID，压缩，加密等字段，和具体的业务分离。具体的业务的消息内容，作为通用消息体的一部分。

具体地，通用的上行下行消息体定义如下：

针对上行消息，客户端(即设备终端)向Topic发送消息，客户端填充报文体：客户端序列ID；RPC调用的服务和方法(或RPC调用的方法名称)；对应具体的业务PB对象；data压缩方式，0表示没压缩，其他代表不同压缩方式；摘要算法，例如sha-1，用于校验data，防止被篡改；服务端(即服务器)序列ID；消息创建时的本地时间。这里消息创建时的本地时间可以与目标消息体创建的当时时间相同也可以不同，结合具体的场景确定。

具体地，客户端对RpcMessage的字段进行填充序列化后，填充到MQTT协议的报文体里，data字段对应具体的业务PB/Request。服务端收到消息后，取出报文体，用RpcMessage对数据进行反序列化，根据method(即调用的方法名称)，调用服务器内部对应的业务，即data对应的具体的业务PB/Request。

针对下行消息，服务器填充报文体：场景1：客户端向Topic发送消息后收到服务器的Response；场景2：客户端订阅Topic以后收到下行消息。

服务器填充报文体：服务端序列ID；required int32 cmdType＝2；//1表示Response(回应操作，场景1)，2表示notify(通知操作，场景2)；调用的方法名称；对应具体的业务PB对象；data压缩方式，0表示没压缩，其他代表不同压缩方式；摘要算法，例如sha-1，用于校验data，防止被篡改；客户端序列ID；消息发送时间。这里消息发送时间可以与目标消息体创建的当时时间相同也可以不同，结合具体的场景确定。

具体地，服务端对MessageNotify的字段进行填充序列化后，填充到MQTT协议的报文体里，data字段对应来具体的业务PB。客户端收到MQTT的消息后，取出报文体的数据，用MessageNotify对数据进行反序列化，根据业务操作字段的具体数据和调用的方法名称来做对应的业务逻辑处理。

因此，通过上述通信方法可以适用的应用场景：例如拼车场景、运力调度场景等等。具体需求：在上述场景下，具体需要做什么事情。例如拼车场景下：拼车费用计算、拼车乘客的匹配、路线选择等需求。本公开在终端设备(比如，车载设备)上使用MQTT+ProtocolBuffers的组合方案，对上行下行消息，定义外层的通用消息体，和具体业务分离，用来解决不同业务调用的问题以及加密，压缩，校验等问题。

此外，现有技术移植到不同的硬件平台，例如andoid，linux，对数据的封装和解析需要重新开发。设备对接到不同的IOT(物联网)平台比较困难，平台侧适配的工作量大，但是该方法对数据的解析工作量降低，且对于客户端上来说，移植到不同的硬件平台只需要重新编译即可，对于服务端来说，只需要进行一些配置，不需要再去做复杂的数据解析。因此，便于扩展和使用，且数据的封装、解析复杂度降低了。

图4为本公开又一实施例提供的设备通信方法的流程示意图。上述图2、图3所述的实施例，是基于Protocol Buffers对数据进行封装，得到数据包，然后通过MQTT协议进行数据包传输，相应的，通过MQTT协议接收到数据包后，还可以通过Protocol Buffers对数据进行解析，得到对应的具体业务，解决了现有技术无法有效地实现通信的问题。具体地，设备通信方法，可以包括：

S401、获取消息发送方通过MQTT协议发送的数据包。

S402、获取通过Protocol Buffers解析得到所述数据包的目标业务消息体。

S403、获取预定义的通用消息体，根据所述通用消息体以及所述目标业务消息体，确定目标业务数据。

本公开实施例中，执行主体可以是终端设备或服务器，可以结合图2所述的实施例，实现数据包的逆序列化，解析到目标业务数据。

具体地，通过MQTT协议获取或接收消息发送方发送的数据包，数据包是通过Protocol Buffers填充序列化的，因此，可以通过Protocol Buffers对数据包进行逆序列化，得到目标业务消息体，由于目标业务消息体是填充了具体数据的通用消息体，因此，基于预定义的通用消息体，解析目标业务消息体，能够得到目标业务数据。使用ProtocolBuffers解析，工作量较低。

本公开实施例提供的设备通信方法，通过获取消息发送方使用MQTT协议发送的数据包，然后通过Protocol Buffers对传递的数据包的解析，解决了现有技术中基于某些固定的规则去解析字节码，很容易出错的问题。且在终端设备(比如，车载设备)上使用MQTT+Protocol Buffers的组合方案，对上行下行消息，定义外层的通用消息体，和具体业务分离，用来解决不同业务调用的问题以及加密，压缩，校验等问题。

可选的，本公开实施例在上述实施例的基础上，例如，在图4所述的实施例的基础上，对S403进行了详细说明。所述根据所述通用消息体以及所述目标业务消息体，确定目标业务数据，可以包括以下步骤：

步骤d1、通过Protocol Buffers对所述目标业务消息体进行反序列化，得到第一消息体。

步骤d2、根据所述第一消息体和所述通用消息体，确定目标业务数据。

本公开实施例中，在得到目标消息体后，通过Protocol Buffers对目标业务消息体进行反序列化，得到第一消息体，结合通用消息体，确定目标业务数据对应的字段即业务数据字段，由于上述数据封装时，对通过消息体进行数据填充后得到第一消息体，然后对第一消息体进行序列化得到目标消息体，因此，解析过程可以是解析出第一消息体后，结合通用消息体中各个字段的定义，基于业务数据字段在通用消息体的位置，确定目标业务数据，然后执行相应逻辑处理。该种Protocol Buffers解析方式结合数据包传输方式即MQTT协议传输，既保证了消息的实时性，也对数据的解析工作量降低。

图5为本公开实施例提供的设备通信装置的结构示意图。该设备通信装置具体可以是上述实施例中的终端设备或服务器。本公开实施例提供的设备通信装置可以执行设备通信方法实施例提供的处理流程，如图5所示，设备通信装置包括：第一获取模块501、第一处理模块502和消息发送模块503；其中，获取模块501，用于响应于用于指示发送消息的触发操作，获取所述消息对应的目标业务数据；第一处理模块502，用于获取预定义的通用消息体，根据所述目标业务数据，通过Protocol Buffers对所述通用消息体进行填充，得到目标业务消息体；所述第一处理模块502，还用于将所述目标业务消息体通过ProtocolBuffers填充至MQTT协议的报文体中，生成数据包；消息发送模块503，用于将所述数据包通过MQTT协议发送至消息接收方，以使所述消息接收方解析所述数据包并根据解析得到的所述目标业务数据执行相应的操作。

可选的，所述通用消息体包括封装特征字段以及业务数据字段。所述第一处理模块，具体用于：根据所述触发操作的类型和所述目标业务数据，通过Protocol Buffers对所述封装特征字段进行填充，根据所述目标业务数据，通过Protocol Buffers对所述业务数据字段进行填充，得到第一消息体；通过Protocol Buffers对所述第一消息体进行序列化，得到目标业务消息体。

可选的，所述第一处理模块，还具体用于：通过Protocol Buffers，生成与所述目标业务数据相关联的目标消息体；根据所述目标业务数据和所述目标消息体，通过Protocol Buffers对所述业务数据字段进行填充。

可选的，所述第一处理模块，还具体用于：通过Protocol Buffers，生成当前时间字段；根据所述目标业务数据，通过Protocol Buffers，生成目标业务数据字段；根据所述当前时间字段和所述目标业务数据字段，生成所述目标消息体。

可选的，所述第一处理模块，还具体用于：获取当前时间；将所述当前时间和所述目标业务数据通过Protocol Buffers填充至所述目标消息体中，得到第一对象；根据所述第一对象，通过Protocol Buffers对所述业务数据字段进行填充。

可选的，所述第一处理模块，还具体用于：根据所述当前时间和所述目标业务数据，通过Protocol Buffers对所述目标消息体中的当前时间字段和所述目标业务数据字段进行相应的填充；通过Protocol Buffers对填充后的目标消息体进行序列化，得到所述第一对象。

可选的，所述封装特征字段中至少包含消息ID字段、压缩方式字段、加密方式字段、调用的方法名称字段、消息发生时间字段、业务操作字段；所述封装特征字段与所述业务数据字段分离。

可选的，所述触发操作的类型包括通知操作类型或回应操作类型，所述第一处理模块，还具体用于：获取所述触发操作的类型；获取所述目标业务数据的关联信息，所述关联信息至少包括消息发送方ID、消息接收方ID、压缩方式、加密方式、调用的方法名称、消息发生时间、业务操作类型，所述业务操作类型与所述触发操作的类型一致；根据所述关联信息和所述触发操作的类型，通过Protocol Buffers对所述封装特征字段进行填充。

可选的，所述消息ID字段包括消息发送方ID字段和消息接收方ID字段；所述第一处理模块，还具体用于：将所述消息发送方ID、消息接收方ID、压缩方式、加密方式、调用的方法名称、消息发生时间、所述触发操作的类型通过Protocol Buffers对应填充至所述封装特征字段中。

可选的，所述消息接收方为终端设备或服务器，所述终端设备至少包括车载设备。

图5所示实施例的设备通信装置可用于执行上述第一方面所述的方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

本公开实施例通过配置的第一获取模块501、第一处理模块502和消息发送模块503，用于响应于用于指示发送消息的触发操作，获取该消息对应的目标业务数据；获取预定义的通用消息体，结合目标业务数据，通过Protocol Buffers对所述通用消息体进行填充，得到目标业务消息体，因此通用消息体提供了便于扩展的框架，使用目标业务数据对通用消息体填充的方式能够扩展出不同的目标业务消息体，并且将所述目标业务消息体通过Protocol Buffers填充至MQTT协议的报文体中，生成数据包，将所述数据包通过MQTT协议发送至消息接收方，以使所述消息接收方解析所述数据包并根据解析得到的所述目标业务数据执行相应的操作，通过Protocol Buffers填充使得数据封装简单，相应的解析工作量也降低了，且针对设备的通信采用MQTT协议，能够为连接远程设备提供实时可靠的消息服务。因此，在网络传输协议上，使用MQTT协议，在数据封装协议上，使用Protocol Buffers，既方便了扩展，又提供实时可靠的消息服务，同时降低了数据封装、解析上的复杂性，有效地实现了设备的通信。

图6为本公开另一实施例提供的设备通信装置的结构示意图。该设备通信装置具体可以是上述实施例中的终端设备或服务器。本公开实施例提供的设备通信装置可以执行设备通信方法实施例提供的处理流程，如图6所示，设备通信装置包括：第二获取模块601、第二处理模块602。第二获取模块601，用于获取发送方通过MQTT协议发送的数据包；第二处理模块，用于获取通过Protocol Buffers解析得到所述数据包的目标业务消息体；所述第二处理模块602，还用于获取预定义的通用消息体，根据所述通用消息体以及所述目标业务消息体，确定目标业务数据。

可选的，所述第二处理模块，具体用于：通过Protocol Buffers对所述目标业务消息体进行反序列化，得到第一消息体；根据所述第一消息体和所述通用消息体，确定目标业务数据。

图6所示实施例的设备通信装置可用于执行上述第二方面所述的方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

本公开实施例通过配置的第二获取模块601、第二处理模块602，用于通过获取消息发送方使用MQTT协议发送的数据包，然后通过Protocol Buffers对传递的数据包的解析，解决了现有技术中基于某些固定的规则去解析字节码，很容易出错的问题。且在终端设备(比如，车载设备)上使用MQTT+Protocol Buffers的组合方案，对上行下行消息，定义外层的通用消息体，和具体业务分离，用来解决不同业务调用的问题以及加密，压缩，校验等问题。

图7为本公开实施例提供的电子设备的结构示意图。该电子设备具体可以是上述实施例中的终端设备或服务器。本公开实施例提供的电子设备可以执行设备通信方法实施例提供的处理流程，如图7所示，本实施例提供的电子设备700包括：至少一个处理器701和存储器702。其中，处理器701、存储器702通过总线703连接。

在具体实现过程中，至少一个处理器701执行所述存储器702存储的计算机执行指令，使得至少一个处理器701执行上述方法实施例中的方法。

处理器701的具体实现过程可参见上述方法实施例，其实现原理和技术效果类似，本实施例此处不再赘述。

在上述的图7所示的实施例中，应理解，处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application SpecificIntegrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器。

总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component Interconnect，PCI)总线或扩展工业标准体系结构(Extended Industry Standard Architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本公开附图中的总线并不限定仅有一根总线或一种类型的总线。

另外，本公开实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行以实现上述实施例所述的设备通信方法。

上述的计算机可读存储介质，上述可读存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。可读存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的可读存储介质耦合至处理器，从而使处理器能够从该可读存储介质读取信息，且可向该可读存储介质写入信息。当然，可读存储介质也可以是处理器的组成部分。处理器和可读存储介质可以位于专用集成电路(Application Specific IntegratedCircuits，简称：ASIC)中。当然，处理器和可读存储介质也可以作为分立组件存在于设备中。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (26)

1.一种设备通信方法，其特征在于，包括：

响应于用于指示发送消息的触发操作，获取所述消息对应的目标业务数据；

获取预定义的通用消息体，根据所述目标业务数据，通过Protocol Buffers对所述通用消息体进行填充，得到目标业务消息体，所述通用消息体包括相互分离的封装特征字段和业务数据字段，所述通用消息体用于业务扩展；

将所述目标业务消息体通过Protocol Buffers填充至MQTT协议的报文体中，生成数据包；

将所述数据包通过MQTT协议发送至消息接收方，以使所述消息接收方解析所述数据包并根据解析得到的所述目标业务数据执行相应的操作。

2.根据权利要求1所述的方法，其特征在于，

所述根据所述目标业务数据，通过Protocol Buffers对所述通用消息体进行填充，得到目标业务消息体，包括：

根据所述触发操作的类型和所述目标业务数据，通过Protocol Buffers对所述封装特征字段进行填充，根据所述目标业务数据，通过Protocol Buffers对所述业务数据字段进行填充，得到第一消息体；

通过Protocol Buffers对所述第一消息体进行序列化，得到目标业务消息体。

3.根据权利要求2所述的方法，其特征在于，所述根据所述目标业务数据，通过Protocol Buffers对所述业务数据字段进行填充，包括：

通过Protocol Buffers，生成与所述目标业务数据相关联的目标消息体；

根据所述目标业务数据和所述目标消息体，通过Protocol Buffers对所述业务数据字段进行填充。

4.根据权利要求3所述的方法，其特征在于，所述通过Protocol Buffers，生成与所述目标业务数据相关联的目标消息体，包括：

通过Protocol Buffers，生成当前时间字段；

根据所述目标业务数据，通过Protocol Buffers，生成目标业务数据字段；

根据所述当前时间字段和所述目标业务数据字段，生成所述目标消息体。

5.根据权利要求4所述的方法，其特征在于，所述根据所述目标业务数据和所述目标消息体，通过Protocol Buffers对所述业务数据字段进行填充，包括：

获取当前时间；

将所述当前时间和所述目标业务数据通过Protocol Buffers填充至所述目标消息体中，得到第一对象；

根据所述第一对象，通过Protocol Buffers对所述业务数据字段进行填充。

6.根据权利要求5所述的方法，其特征在于，所述将所述当前时间和所述目标业务数据通过Protocol Buffers填充至所述目标消息体中，得到第一对象，包括：

根据所述当前时间和所述目标业务数据，通过Protocol Buffers对所述目标消息体中的当前时间字段和所述目标业务数据字段进行相应的填充；

通过Protocol Buffers对填充后的目标消息体进行序列化，得到所述第一对象。

7.根据权利要求2-6任一项所述的方法，其特征在于，所述封装特征字段中至少包含消息ID字段、压缩方式字段、加密方式字段、调用的方法名称字段、消息发生时间字段、业务操作字段；

所述封装特征字段与所述业务数据字段分离。

8.根据权利要求7所述的方法，其特征在于，所述触发操作的类型包括通知操作类型或回应操作类型，所述根据所述触发操作的类型和所述目标业务数据，通过ProtocolBuffers对所述封装特征字段进行填充，包括：

获取所述触发操作的类型；

获取所述目标业务数据的关联信息，所述关联信息至少包括消息发送方ID、消息接收方ID、压缩方式、加密方式、调用的方法名称、消息发生时间、业务操作类型，所述业务操作类型与所述触发操作的类型一致；

根据所述关联信息和所述触发操作的类型，通过Protocol Buffers对所述封装特征字段进行填充。

9.根据权利要求8所述的方法，其特征在于，所述消息ID字段包括消息发送方ID字段和消息接收方ID字段；

根据所述关联信息和所述触发操作的类型，通过Protocol Buffers对所述封装特征字段进行填充，包括：

将所述消息发送方ID、消息接收方ID、压缩方式、加密方式、调用的方法名称、消息发生时间、所述触发操作的类型通过Protocol Buffers对应填充至所述封装特征字段中。

10.根据权利要求1所述的方法，其特征在于，所述消息接收方为终端设备或服务器，所述终端设备至少包括车载设备。

11.一种设备通信方法，其特征在于，包括：

获取消息发送方通过MQTT协议发送的数据包；

获取通过Protocol Buffers解析得到所述数据包的目标业务消息体；

获取预定义的通用消息体，根据所述通用消息体以及所述目标业务消息体，确定目标业务数据，所述通用消息体包括相互分离的封装特征字段和业务数据字段，所述通用消息体用于业务扩展。

12.根据权利要求11所述的方法，其特征在于，所述根据所述通用消息体以及所述目标业务消息体，确定目标业务数据，包括：

通过Protocol Buffers对所述目标业务消息体进行反序列化，得到第一消息体；

根据所述第一消息体和所述通用消息体，确定目标业务数据。

13.一种设备通信装置，其特征在于，包括：

第一获取模块，用于响应于用于指示发送消息的触发操作，获取所述消息对应的目标业务数据；

第一处理模块，用于获取预定义的通用消息体，根据所述目标业务数据，通过ProtocolBuffers对所述通用消息体进行填充，得到目标业务消息体，所述通用消息体包括相互分离的封装特征字段和业务数据字段，所述通用消息体用于业务扩展；

所述第一处理模块，还用于将所述目标业务消息体通过Protocol Buffers填充至MQTT协议的报文体中，生成数据包；

消息发送模块，用于将所述数据包通过MQTT协议发送至消息接收方，以使所述消息接收方解析所述数据包并根据解析得到的所述目标业务数据执行相应的操作。

14.根据权利要求13所述的装置，其特征在于，所述通用消息体包括封装特征字段以及业务数据字段；

所述第一处理模块，具体用于：

根据所述触发操作的类型和所述目标业务数据，通过Protocol Buffers对所述封装特征字段进行填充，根据所述目标业务数据，通过Protocol Buffers对所述业务数据字段进行填充，得到第一消息体；

通过Protocol Buffers对所述第一消息体进行序列化，得到目标业务消息体。

15.根据权利要求14所述的装置，其特征在于，所述第一处理模块，还具体用于：

通过Protocol Buffers，生成与所述目标业务数据相关联的目标消息体；

根据所述目标业务数据和所述目标消息体，通过Protocol Buffers对所述业务数据字段进行填充。

16.根据权利要求15所述的装置，其特征在于，所述第一处理模块，还具体用于：

通过Protocol Buffers，生成当前时间字段；

根据所述目标业务数据，通过Protocol Buffers，生成目标业务数据字段；

根据所述当前时间字段和所述目标业务数据字段，生成所述目标消息体。

17.根据权利要求16所述的装置，其特征在于，所述第一处理模块，还具体用于：

获取当前时间；

将所述当前时间和所述目标业务数据通过Protocol Buffers填充至所述目标消息体中，得到第一对象；

根据所述第一对象，通过Protocol Buffers对所述业务数据字段进行填充。

18.根据权利要求17所述的装置，其特征在于，所述第一处理模块，还具体用于：

根据所述当前时间和所述目标业务数据，通过Protocol Buffers对所述目标消息体中的当前时间字段和所述目标业务数据字段进行相应的填充；

通过Protocol Buffers对填充后的目标消息体进行序列化，得到所述第一对象。

19.根据权利要求14-18任一项所述的装置，其特征在于，所述封装特征字段中至少包含消息ID字段、压缩方式字段、加密方式字段、调用的方法名称字段、消息发生时间字段、业务操作字段；

所述封装特征字段与所述业务数据字段分离。

20.根据权利要求19所述的装置，其特征在于，所述触发操作的类型包括通知操作类型或回应操作类型，所述第一处理模块，还具体用于：

获取所述触发操作的类型；

获取所述目标业务数据的关联信息，所述关联信息至少包括消息发送方ID、消息接收方ID、压缩方式、加密方式、调用的方法名称、消息发生时间、业务操作类型，所述业务操作类型与所述触发操作的类型一致；

根据所述关联信息和所述触发操作的类型，通过Protocol Buffers对所述封装特征字段进行填充。

21.根据权利要求20所述的装置，其特征在于，所述消息ID字段包括消息发送方ID字段和消息接收方ID字段；所述第一处理模块，还具体用于：

将所述消息发送方ID、消息接收方ID、压缩方式、加密方式、调用的方法名称、消息发生时间、所述触发操作的类型通过Protocol Buffers对应填充至所述封装特征字段中。

22.根据权利要求13所述的装置，其特征在于，所述消息接收方为终端设备或服务器，所述终端设备至少包括车载设备。

23.一种设备通信装置，其特征在于，包括：

第二获取模块，用于获取发送方通过MQTT协议发送的数据包；

第二处理模块，用于获取通过Protocol Buffers解析得到所述数据包的目标业务消息体；

所述第二处理模块，还用于获取预定义的通用消息体，根据所述通用消息体以及所述目标业务消息体，确定目标业务数据，所述通用消息体包括相互分离的封装特征字段和业务数据字段，所述通用消息体用于业务扩展。

24.根据权利要求23所述的装置，其特征在于，所述第二处理模块，具体用于：

通过Protocol Buffers对所述目标业务消息体进行反序列化，得到第一消息体；

根据所述第一消息体和所述通用消息体，确定目标业务数据。

25.一种电子设备，其特征在于，包括：

存储器；

处理器；以及

计算机程序；

其中，所述计算机程序存储在所述存储器中，并被配置为由所述处理器执行以实现如权利要求1-12任一所述的方法。

26.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-12任一项所述的方法。

Images