提供物联网服务的方法、设备、服务器及存储介质与流程

本申请涉及物联网技术领域，尤其涉及一种提供物联网服务的方法、设备、服务器及计算机可读存储介质。

背景技术：

在2g(第二代移动通信技术)、3g(第三代移动通信技术)、4g(第四代移动通信技术)、5g(第五代移动通信技术)、6g(第六代移动通信技术)或更下一代移动通信技术以及蓝牙、zigbee、wifi等短距离无线通信技术共同组成的网络环境下，无法保证网络通讯的持续连通和稳定通讯，必然会因位置移动、信号质量、自然环境等不可抗因素导致物联网(theinternetofthings，简称iot)终端出现高延迟、频繁断线上线、长期失联(离线)等情况。在共享经济相关产品以及商用电器如空调的监控等应用场景中通常需要面临多种网络通讯条件。

目前在物联网行业中处理通讯的链接机制还比较简单，大多为定时的上报数据或心跳，服务器下发配置或指令也多为直接下发，对于离线的设备大多是加入消息队列等待设备上线后消费或超时处理。

随着物联网相关技术的发展和应用场景的增加，我们面临的业务场景也变得愈发复杂，服务端与iot终端之间的通讯数据因种类繁多而变得越来越复杂，这导致因网络问题使得大量的功能变得难以控制或保持稳定，如果处理不及时则会导致相关业务整体的发展停摆，严重拖累企业的开发和运营。

尤其是，iot终端在与服务器通讯时存在如下技术问题：

通讯业务与系统业务存在严重的耦合，层次划分不清，通讯业务混在在其他系统业务中，导致存在侵入关系的业务面对需求时难以开发维护。通讯业务是与iot设备通讯的相关业务，需要直接与iot设备进行数据交互，例如从iot设备读取数据或向iot设备发送数据；系统业务为除去直接与iot设备交互的业务外的业务，即在服务端系统内部执行的全部业务，它们同样可以涉及iot设备数据的传递，只是不参与与iot设备的直接交互。

由于通讯业务与系统业务的严重耦合，业务逻辑需要同时对系统业务和通讯业务进行管理和维护，所有iot设备的状态和配置的维护和获取需要大量的额外逻辑处理，分散且不易管理，容易出现逻辑漏洞和设计缺陷。

此外，导致长期失联设备的状态难维护、难管理，最终出现设备数据的碎片化(如同一组批次的设备配置不一致的问题)，这种设备在后续的管理中很容易被遗漏，最终导致出现生产事故。

针对上述问题，目前尚未提出有效的解决方式。

技术实现要素：

有鉴于此，本申请提出一种提供物联网服务的方法、设备、服务器及计算机可读存储介质，通过为iot设备生成对应的设备影子，将与所述iot设备关联的至少部分通讯数据同步到对应的设备影子，当从业务服务和/或接入的iot设备接收到对通讯数据的使用请求时，从设备影子中获取通讯数据，以供业务服务和/或接入的iot设备使用。可见，通过提供设备影子使得将通讯业务从系统业务中分离出来，系统业务不再直接参与与iot设备终端的通讯，转而由设备影子维护iot设备的数据，从而系统业务中对iot设备数据的请求通过读取设备影子即可获得，与iot设备的直接通讯则交由影子服务和接入服务等专门负责，降低了多种业务通过系统获取iot终端相关数据的耗时，进而有效改善交互体验和响应速度。

据本申请的一个方面，提供一种提供物联网(iot)服务的方法，包括：

生成与iot设备对应的设备影子，将与所述iot设备关联的至少部分通讯数据同步到对应的所述设备影子；

当从业务服务和/或接入的iot设备接收到对所述通讯数据的使用请求时，从所述iot设备对应的所述设备影子中获取所述通讯数据，以供所述业务服务和/或接入的iot设备使用。

进一步地，所述至少部分通讯数据包括上行数据；

响应于从所述接入的iot设备接收到所述上行数据，将所述上行数据发布到消息队列对应的主题(topic)中；

通过对所述消息队列中主题进行订阅，从所述消息队列获取所述上行数据；

将与所述iot设备关联的至少部分通讯数据同步到对应的所述设备影子，包括：将所述获取的上行数据同步到与所述iot设备对应的设备影子中。

进一步地，所述至少部分通讯数据包括下行数据；

将与所述iot设备关联的至少部分通讯数据同步到对应的所述设备影子，包括：响应于从业务服务接收到所述下行数据，将所述下行数据同步到对应的设备影子；

从所述iot设备对应的所述设备影子中获取所述通讯数据，包括：

从所述iot设备对应的所述设备影子中获取所述下行数据；

响应于从所述设备影子中获取到所述下行数据，将所述下行数据发布到消息队列对应的主题中；

通过对所述消息队列中主题进行订阅，从所述消息队列获取所述下行数据，将所述下行数据发送给对应的iot设备。

进一步地，将所述上行数据发布到消息队列对应的主题，包括：

将所述上行数据携带标记信息发布到消息队列对应的主题中，和/或，

采用“前缀/协议”的方式定义发布到消息队列中的所述上行数据对应的主题；

和/或，

对所述消息队列中主题进行订阅，包括：对所述消息队列中自身支持的协议的主题进行订阅；

和/或，

从所述消息队列获取所述上行数据，包括：当单一解析服务实例适配多个协议时，根据协议类型及channelid获取目标iot设备的所述上行数据；和/或，

将所述上行数据发送给影子服务单元，包括：将所述上行数据解析后发送给所述影子服务单元；

和/或，

当所述上行数据同步到与所述iot设备对应的设备影子中，使用消息队列异步通知所述业务服务单元所述设备影子被更新；

和/或，

从所述iot设备对应的所述设备影子中获取所述通讯数据，包括：从所述iot设备对应的所述设备影子中获取所述上行数据，

接收从设备影子获取的上行数据以执行业务服务操作，当接收到的所述上行数据未解析，则进行解析。

进一步地，所述标记信息包括接入服务类型、channelid、接入服务实例id至少之一。

进一步地，将所述下行数据发布到消息队列对应的主题中，包括：采用“前缀/接入服务实例id”的方式定义发布到消息队列中的下行数据对应的主题；

和/或，

当将下行数据更新到设备影子后，业务服务通知所述下行数据的变更时间。

进一步地，不同的接入服务实例实现对不同协议设备的接入支持；

和/或，

当所述iot设备的数量为多个时，所述设备影子与所述多个iot设备中的每个相对应；

和/或，

将处于冷设备状态的iot设备的设备影子存放在冷数据区域，将处于热设备状态的iot设备的设备影子存放在热数据区域或同时存放在热数据区域或冷数据区域；和/或，

所述设备影子中的数据包括iot设备id，

从所述iot设备对应的所述设备影子中获取所述通讯数据，包括：通过所述iot设备id获取对应设备的设备影子，并从所述设备影子中获取所述通讯数据；

和/或，

所述至少部分通讯数据包括：基本数据。

进一步地，所述基本数据包括：状态数据、配置数据；

和/或，

所述至少部分通讯数据还包括部分扩展数据，所述扩展数据包括：事件数据和业务数据。

进一步地，设备影子对不同的数据采用不同的方式保存。

根据本申请的又一个方面，提供了一种提供物联网(iot)服务的设备，包括：

业务服务单元、接入服务单元和影子服务单元；

所述业务服务单元，提供业务服务；

所述接入服务单元，用于接入iot设备；

所述影子服务单元，生成与iot设备对应的设备影子，将与所述iot设备关联的至少部分通讯数据同步到对应的所述设备影子；

当从业务服务和/或接入的iot设备接收到对所述通讯数据的使用请求时，所述影子服务单元从所述iot设备对应的所述设备影子中获取所述通讯数据，以供所述业务服务和/或接入的iot设备使用。

进一步地，所述设备还包括解析服务单元，所述至少部分通讯数据包括上行数据；

所述接入服务单元，响应于从所述接入的iot设备接收到所述上行数据，将所述上行数据发布到消息队列对应的主题(topic)中；

所述解析服务单元，通过对所述消息队列中主题进行订阅，从所述消息队列获取所述上行数据，并将所述上行数据发送给影子服务单元；

将与所述iot设备关联的至少部分通讯数据同步到对应的所述设备影子，包括：将所述获取的上行数据同步到与所述iot设备对应的设备影子中。

进一步地，所述至少部分通讯数据包括下行数据；

将与所述iot设备关联的至少部分通讯数据同步到对应的所述设备影子，包括：响应于从业务服务接收到所述下行数据，将所述下行数据同步到对应的设备影子；

所述影子服务单元从所述iot设备对应的所述设备影子中获取所述通讯数据，包括：

所述影子服务单元从所述iot设备对应的所述设备影子中获取所述下行数据；

响应于从所述设备影子中获取到所述下行数据，所述解析服务单元将所述下行数据发布到消息队列对应的主题中；

所述接入服务单元，通过对所述消息队列中主题进行订阅，从所述消息队列获取所述下行数据，将所述下行数据发送给对应的iot设备。

进一步地，将所述上行数据发布到消息队列对应的主题，包括：

将所述上行数据携带标记信息发布到消息队列对应的主题中，和/或，

采用“前缀/协议”的方式定义发布到消息队列中的所述上行数据对应的主题；

和/或，

对所述消息队列中主题进行订阅，包括：对所述消息队列中自身支持的协议的主题进行订阅；

和/或，

从所述消息队列获取所述上行数据，包括：当单一解析服务实例适配多个协议时，根据协议类型及channelid获取目标iot设备的所述上行数据；和/或，

将所述上行数据发送给影子服务单元，包括：将所述上行数据解析后发送给所述影子服务单元；

和/或，

当所述上行数据同步到与所述iot设备对应的设备影子中，使用消息队列异步通知所述业务服务单元所述设备影子被更新；

和/或，

从所述iot设备对应的所述设备影子中获取所述通讯数据，包括：从所述iot设备对应的所述设备影子中获取所述上行数据，

接收从设备影子获取的上行数据以执行业务服务操作，当接收到的所述上行数据未解析，则进行解析。

进一步地，所述标记信息包括接入服务类型、channelid、接入服务实例id至少之一。

进一步地，将所述下行数据发布到消息队列对应的主题中，包括：采用“前缀/接入服务实例id”的方式定义发布到消息队列中的下行数据对应的主题；

和/或，

当所述业务服务单元将下行数据更新到设备影子后，所述业务服务单元通知所述解析服务单元所述下行数据的变更时间。

进一步地，所述接入服务单元中不同的接入服务实例实现对不同协议设备的接入支持；

和/或，

当所述iot设备的数量为多个时，所述设备影子与所述多个iot设备中的每个相对应；

和/或，

所述影子服务单元，将处于冷设备状态的iot设备的设备影子存放在冷数据区域，将处于热设备状态的iot设备的设备影子存放在热数据区域或同时存放在热数据区域或冷数据区域；和/或，

所述设备影子中的数据包括iot设备id，

所述影子服务单元从所述iot设备对应的所述设备影子中获取所述通讯数据，包括：所述影子服务单元通过所述iot设备id获取对应设备的设备影子，并从所述设备影子中获取所述通讯数据；

和/或，

所述至少部分通讯数据包括：基本数据。

进一步地，所述基本数据包括：状态数据、配置数据；

和/或，

所述至少部分通讯数据还包括部分扩展数据，所述扩展数据包括：事件数据和业务数据。

进一步地，设备影子对不同的数据采用不同的方式保存。

根据本申请的又一个方面，提供了一种服务器，其特征在于，包括：一个或多个处理器；存储器；一个或多个程序，其中所述一个或多个程序被存储在所述存储器中并被配置为由所述一个或多个处理器执行，所述一个或多个程序配置用于执行前述的方法。

根据本申请的又一个方面，提供了一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有程序代码，所述程序代码可被处理器调用执行前述的方法。

根据本申请提出的一种提供物联网服务的方法、设备、服务器及计算机可读存储介质，通过为iot设备生成对应的设备影子，将与所述iot设备关联的至少部分通讯数据同步到对应的设备影子，当从业务服务和/或接入的iot设备接收到对通讯数据的使用请求时，从设备影子中获取通讯数据，以供业务服务和/或接入的iot设备使用，使得将与iot设备直接通讯的通讯业务从系统业务中分离出来，通讯业务与系统业务不再耦合，系统业务不再直接参与与iot设备的通讯，转而由设备影子和接入服务等专门负责，系统业务中对iot设备数据的请求通过读取设备影子即可获得，因此降低了多种业务通过系统获取iot设备相关数据的耗时，进而有效改善交互体验和响应速度。

此外，通过设备影子对iot设备的数据进行维护，有效的将每一个接入服务系统的iot终端设备的状态、配置以及业务数据等即时的保存到设备影子中，这样既保证了长期失联(离线)设备的状态、配置的可靠持久化，也能够避免设备配置的丢失和差异化(设备上线即可对设备影子中保存的设备配置进行同步下发，而不会因设备长期无法接收配置而直接丢弃配置数据)，进而解决设备管理困难的问题。

进一步地，移动网络的通讯稳定性是不确定的，存在无法通讯、通讯延迟长、通讯时间长等可能的问题。通过在服务器系统端为iot设备生成对应的设备影子，实现了指令下发的异步处理，改变业务设计思路，业务系统的逻辑仅向下触及到影子服务调用为止，可将数据发送状态、数据响应状态等作为标记放入设备影子的业务数据中进行维护，使数据的通讯状态变得更加清晰，进而简化系统业务的设计开发成本，减少了系统处理异常频率，提高交付效率，提高可靠性。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，并可依照说明书的内容予以实施，以下以本申请的较佳实施例并配合附图详细说明如后。

附图说明

构成本发明的一部分的附图用来提供对本发明的进一步理解，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1示出了本申请的一种物联网系统的一实施例的示意图；

图2示出了本申请的一种提供物联网iot服务的设备的一实施例的示意图；

图3示出了本申请的一种接入服务实例的一实施例的示意图；

图4示出了本申请的一种设备影子的一实施例的示意图；

图5示出了本申请的一种上行数据上报传递过程的一实施例的示意图；

图6示出了本申请的一种下行数据下发传递过程的一实施例的示意图；

图7示出了本申请的一种扩展数据类型通讯数据的传递过程的一实施例的示意图；

图8示出了本申请的提供物联网服务的方法的一实施例的示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

图1示出了本申请的一种物联网系统的一实施例的示意图。

现有技术中，用户利用远程设备3如手机等电子产品，通过服务设备10的对iot设备2进行管理和控制。服务设备10提供物联网服务平台，通过业务服务直接与iot设备2进行数据交互，例如状态查询、配置读写等。这样的交互设计方案，导致，通讯业务与系统业务存在严重的耦合，层次划分不清，通讯业务混在在其他系统业务中，导致存在侵入关系的业务面对需求时难以开发维护。此外，由于通讯业务与系统业务的严重耦合，业务逻辑需要同时对系统业务和通讯业务进行管理和维护，所有iot设备的状态和配置的维护和获取需要大量的额外逻辑处理，分散且不易管理，容易出现逻辑漏洞和设计缺陷。

如图所述，本申请提出了一个解决方案，在服务设备1中生成与iot设备对应的设备影子，将与所述iot设备关联的至少部分通讯数据同步到对应的所述设备影子；当从业务服务和/或接入的iot设备接收到对所述通讯数据的使用请求时，影子服务单元从所述iot设备对应的所述设备影子中获取所述通讯数据，以供所述业务服务和/或接入的iot设备使用。

通过设备影子作为中间模块，将从业务服务下发和/或从iot设备上传的通讯数据中，至少部分与所述iot设备关联的通讯数据同步到对应的设备影子中，从而，在业务服务和/或接入的iot设备请求使用与iot设备关联的通讯数据如状态数据、配置数据、注册数据等时，可以直接从设备影子获取数据，而不需要向iot设备请求，实现了通讯业务和系统业务的分离，iot设备与业务服务端的数据交互通过设备影子进行，业务服务端与iot设备之间的数据交互也通过设备影子进行，从而避免了系统业务直接参与与iot设备终端的通讯，降低了多种业务通过系统直接向iot设备获取相关数据的耗时，进而有效改善交互体验和响应速度。

图2示出了本申请的一种提供物联网iot服务的设备的一实施例的示意图。

如图所示，所述服务设备1至少包括影子服务单元11、业务服务单元13和接入服务单元14，还可以包括解析服务单元12。

影子服务单元11，用于提供影子服务。

业务服务单元13，用于提供业务服务。

接入服务单元14提供接入服务，用于接入iot设备2，接收来自于iot设备2的连接请求和数据。

进一步地，影子服务单元11生成与iot设备对应的设备影子，将与所述iot设备关联的至少部分通讯数据同步(存储或更新)到对应的所述设备影子；当从业务服务和/或接入的iot设备接收到对所述通讯数据的使用请求时，所述影子服务单元从所述iot设备对应的所述设备影子中获取所述通讯数据，以供所述业务服务和/或接入的iot设备使用。

本申请所描述的iot设备可以为iot终端例如iot电器设备，但不限于此。同样，本申请的iot设备不限于具有2g、3g、4g、5g、6g或更下一代移动通信技术等网络的通讯模块(通讯模块与负载设备连接后可接入本申请的服务设备系统)或者为具备2g、3g、4g、5g、6g通讯能力的集成物联网终端(设备本身集成通讯功能单元)，且并不局限于无线网络(通过internet等公共网络亦可)。

本申请中的网络数据通讯可以依托于tcp和/或udp传输层协议。在影子服务单元11、业务服务单元13、接入服务单元14以及解析服务单元12之间的通讯方式不限于远程调用，也可以是通过消息队列传递数据及消息。采用消息队列传递数据及消息，能够实现异步通知，从而可以提高因季节变化场景引发的短时间接入大量iot终端导致的服务异常。因此，对于实时性要求不高的通讯数据如影子服务与接入服务之间传递的iot设备关联通讯数据，可以采用消息队列进行传递，实现异步机制的同步，从而扩大服务系统的吞吐量。下面的实施方式中，本申请即在影子服务与接入服务之间提供了可供主题订阅的消息队列以实现数据及消息的传递。

本申请所述的业务服务是一个泛指的服务，在实际的系统中是不同业务服务的实例，如共享洗衣机用户业务逻辑(订单、商户、设备调试等)、商用空调机组功能开发调试动态管理以及规则引擎等微服务程序的统称，例如，洗衣机下单并开机，空调机组的远程定时控制，这些操作即是通过服务设备的业务服务来完成。但不限于此。

作为一个实现方向，接入服务单元14中不同的接入服务实例实现对不同协议设备的接入支持。

图3示出了本申请的一种接入服务实例的一实施例的示意图。

接入服务105存在不同实现的接入服务实例(同样也存在多实例)，由图3所示接入服务104可拥有如第三方平台接入服务303，用于与第三方平台设备数据的对接支持，针对不同的第三方平台需要不同的接入服务实例支持；私有协议a接入服务304以及私有协议b接入服务305/308的多实例示范；coap(constrainedapplicationprotocol)接入服务306和mqtt((messagequeuingtelemetrytransport，消息队列遥测传输))接入服务307。接入服务必须自行维护连接与channelid(即通道标识，它是与iot设备建立的socket的可维护的全局唯一标识id，channelid可以看做是iot设备的连接的唯一标识，通过channelid可以找到对应连接，这个连接可能对应着在线的设备，也可能对应的设备已离线了，这个是可以由接入服务自己维护的连接的唯一标识)的对应关系，以便系统区分设备和发送数据。

设备影子(deviceshadow)也被称为设备孪生(devicetwin)。作为一种实现方式，当iot设备2的数量为多个时，影子服务单元11生成多个设备影子，以使多个设备影子与多个iot设备中的每一个对应，可选地，每个iot设备对应至少1个设备影子。例如，每个iot设备至少对应一个例如在数据库中的用于长期存储数据的设备影子，但还可以在其他位置如缓存中具有用于短期使用的设备影子。在本申请中影子服务即对设备影子直接进行更新、创建、查询和删除等管理服务，系统内的其他服务包括接入服务、解析服务和/或业务服务均通过影子服务获取或更新设备影子中的数据，影子服务单元11提供上述影子服务，用于管理所有的设备影子。

作为一个实现方式，影子服务单元11将处于冷设备状态的iot设备的设备影子存放在冷数据区域，将处于热设备状态的iot设备的设备影子存放在热数据区域或同时存放在热数据区域冷数据区域。

iot设备可以划分为2类：冷设备和热设备。由于我们面临的iot设备例如iot电器设备如空调、供暖器等存在季节性或周期性的被启用或上电，即一年中长达半年以上的时间是完全离线的。也存在用于开发/测试机型在使用一段时间后即被永久闲置。也存在正常的长期在线设备。当iot设备在线或在一定时间内在线的设备称之为热设备，这个时间范围可以任意设定例如72小时。当iot设备超过一定时间未连接到服务端时，我们将之定义为冷设备。即同一iot设备，因其在线情况会存在冷设备或热设备之间的类型变化。

因此，作为一种实现方式，针对冷设备和热设备，本申请分别在冷数据区域和热数据区域生成对应的设备影子。可选地，热设备的设备影子可以被同时存放在冷数据区域和热数据区域中，只是且以更新热数据区域中的数据为主，以更新冷数据区域中的数据为辅。热设备的数据会定期以及在变为冷设备时被更新到冷数据区域中。

图4示出了本申请的一种设备影子的一实施例的示意图。

如图所示，设备影子存储区域包括包括冷数据区域111和热数据区域112，其中，将处于冷设备状态的iot设备的设备影子存放在冷数据区域，将处于热设备状态的iot设备的设备影子存放在热数据区域，可选地，热设备的设备影子可以被同时存放在冷数据区域和热数据区域中。

冷数据区域111具有长期存储能力，用于长期存放处于冷设备状态的iot设备的数据，以便iot设备长期离线的情况下也能为其保存数据，进而在其重新上线时能够及时同步数据，以确保不会出现设备配置的版本差异，因此冷数据区域111需要采用稳定可靠的保存方式，例如为数据库。数据库例如为mysql(关系型数据库)或mongodb(文档型数据库)，不限于此。

热数据区域112具有快速读写能力，用于存放处于热设备状态的iot设备的数据，需要的是是读写速度快，因此，热数据区域112例如为缓存或内存型数据库。缓存可以为内存中的一部分存储区域，可以选择如redis(remotedictionaryserver，即远程字典服务)实例或redis集群实现，不限于此。

可选地，存储在设备影子中的数据包括iot设备id，所述影子服务单元从所述iot设备对应的所述设备影子中获取所述通讯数据，包括：所述影子服务单元通过设备id获取对应设备的设备影子，并从所述设备影子中获取所述通讯数据。

设备影子中存储的iot设备的数据可以包括设备id(identitydocument，身份标识)，设备id通常为唯一的，影子服务单元11能够通过设备id在设备影子中找到目标设备的设备影子，进而从目标设备的设备影子中获取所需的通讯数据。其中，设备id为由iot设备终端连接服务设备端时，服务设备端通过登录数据中携带的设备信息获取的如imei、产品id(identitydocument，身份标识)等。以此提高了查找效率和准确性。

同步到设备影子的通讯数据可以为与iot设备关联的部分通讯数据，也可以为与iot设备关联的全部通讯数据。通讯数据包括服务设备1从在iot设备2接收的数据或者服务设备1向iot设备2发送的数据，以及在服务设备1内部各个服务单元之间传递的数据。

作为一个实现方式，同步到设备影子的所述至少部分通讯数据包括：基本数据。进一步地，所述至少部分通讯数据还包括部分扩展数据，所述扩展数据包括：事件数据和业务数据。

本申请中可以将通讯数据划分为两大类：基本数据和扩展数据(可存在服务设备系统内的业务关联)，基本数据类型会严格的更新/保存到影子服务中，而扩展数据类型则不保存到影子服务或者只有部分数据如系统业务数据保存在影子服务中。

基本数据类型如：状态数据、配置数据等。

扩展数据类型包括事件数据和业务数据等，如：心跳数据、ping数据、时间同步数据、注册数据、登录数据、升级报告等。

由于扩展数据类型可能包含了通讯协议业务/系统业务，所以服务端对扩展数据类型的消费方式各有不同。对于扩展数据类型如事件数据或业务数据，对数据的实时性要求较高，且存在即时性的业务需求。常见的事件如：完成、失败、延迟计算等，常见的业务数据如：注册、秘钥更新和线上调试等。若因不可抗力因素(网络差或无网络)导致事件类型的内容无法在限定时间内被传输则允许直接丢弃，从而无需更新或保存到设备影子。

可选地，设备影子对不同的数据采用不同的方式保存。对不同的数据，不是只能使用json作为数据存储的格式，还可以使用如protobuf、msgpack以及纯粹二进制数据等格式保存。

作为一种实现方式，被同步到设备影子上的至少部分的通讯数据包括上行数据和下行数据。上行为从iot设备2传递到服务设备1方向，上行数据为从iot设备2传递到服务设备1方向的通讯数据，在图中表现为从接入服务到解析服务方向为上行，例如，从iot设备2上传到服务设备1的通讯数据如状态数据，以供同步(存储或更新)到对应的设备影子，或者从设备影子传递到业务服务的数据，被业务服务调用以执行业务服务。下行数据与上行数据的方向相反，下行为从服务设备1传递到iot设备2的方向，下行数据为从服务设备1传递到iot设备2方向的通讯数据，在图中表现为从解析服务向接入服务方向为下行，例如，从服务设备1的业务服务下发到设备影子的通讯数据如配置数据，以供同步(存储或更新)到对应的设备影子，或者从设备影子传递到接入服务的数据，被接入服务发送给iot设备以同步到iot设备。

针对上行数据，

接入服务单元14，响应于从接入的iot设备2接收到上行数据，将所述上行数据发布到消息队列(未示出)对应的主题(topic)中；

解析服务单元12，通过对所述消息队列中主题进行订阅，从所述消息队列获取所述上行数据，并将所述上行数据发送给影子服务单元11；

影子服务单元11，将所述上行数据同步到与所述iot设备对应的设备影子中。

作为一种实现方式，将上行数据发布到消息队列对应的主题(topic)中，包括：将上行数据携带标记信息发布到消息队列对应的主题中，和/或，采用“前缀/协议”的方式定义发布到消息队列中的所述上行数据对应的主题，例如“acc/协议”，acc代表上行方向。

其中，标记信息例如包括接入服务类型、channelid(identitydocument，身份标识)、接入服务实例id至少之一。携带接入服务类型例如为基本协议标识、channelid例如为与iot设备建立的socket的可维护的全局唯一标识id。

接入服务将上行通讯数据连同相关的标记信息一同打包后，发往消息队列等待分发消费。

消息队列(mq)104和302可采用成熟的消息队列实现方案如kafka、zeromq、rocketmq等。消息队列的选型主要在于其稳定性以及面对突发流量的表现，对于当前场景消息队列的持久化支持并不是必要的。采用消息队列传递数据及消息，能够实现数据的异步通知，使得指令下发能够异步处理，改变业务设计思路，从而可以提高因季节变化场景引发的短时间接入大量iot终端导致的服务异常，使系统的通讯服务能够更稳定的运行，降低因突发的大量设备接入、大量的指令下发(批量配置/批量控制)场景下出现不易维护的系统异常。

作为一个实现方式，与传统物联网相关的消息队列使用方式不同的是，本申请选择采用“acc/协议”的方式定义由接入服务104到解析服务102方向(上行方向)的topic，例如“acc/100216”表示某个接入服务实例发布的协议100216(协议id)的数据。采用“前缀/接入服务实例id”的方式定义有解析服务102到接入服务104方向(下行方向)的topic，例如“push/接入服务实例id”，push代表下行方向。当然不限于此，也可以采用每个iot设备一个topic的方案，这与消息队列的定位和使用方式的不同有关。

进一步地，针对所述解析服务单元，对消息队列中主题进行订阅，包括：对消息队列中自身支持的协议的主题进行订阅。

进一步地，所述解析服务单元提供适配一个或多个协议的单一解析服务实例。从所述消息队列获取所述上行数据，包括，当所述单一解析服务实例适配多个协议时，根据协议类型及channelid获取目标iot设备的所述上行数据。

解析服务单元12可以根据目标iot设备的类型、协议、接入服务的不同，进行对应协议的二进制数据或文本数据的解析(编码或解码)。对于编码或解码过程本质为对数据的转换、压缩、加密和解密，将传输的二进制数据反序列化为系统可用的数据对象。注意文本、json、protobuf、msgpack等序列化后的数据本质上均视为二进制数据。

解析服务订阅消息队列上对应协议的topic，负责对通讯数据进行相关协议的系统适配、编码和解码工作，解析服务实例包含对应的协议业务支持(仅系统内部设备管理相关业务)。作为一个实现方式，最初可以选择使用多协议支持的通用解析服务实例作为首选以降低系统开发维护成本，当某一类设备对解析服务占用资源较多后可将其单独抽离为一个专用的解析服务实例。在协议解析的过程中存在对通讯数据的加密、解密、终端注册、终端验证以及升级等业务的协议支持。

可选地，解析服务单元将所述上行数据发送给影子服务单元，包括：将所述上行数据解析后发送给影子服务单元。

同样可选地，当所述上行数据同步到与所述iot设备对应的设备影子中，所述解析服务使用消息队列异步通知所述业务服务单元所述设备影子被更新。

例如，解析服务在完成对数据的解析后，根据协议的功能码或数据包类型将设备的状态数据更新到影子服务中，可选的通过使用与前面所描述的同样的消息队列来异步通知业务服务设备影子被更新以便业务服务执行相关业务程序。

作为一个实现方式，影子服务单元从iot设备对应的设备影子中获取通讯数据，包括：影子服务单元从iot设备对应的设备影子中获取上行数据，进而，业务服务单元接收从设备影子获取的上行数据以执行业务服务操作，当接收到的上行数据未解析，则发送给解析服务单元进行解析。

下面以iot设备2向服务设备1上报状态数据为例对本申请的方案进行示例性说明。

图5示出了本申请的一种上行数据上报传递过程的一实施例的示意图。

如图所示，对于基本数据类型(如状态和/或配置数据)，影子服务使用设备影子机制存储设备最新的状态，由iot设备将状态数据发送到接入服务后，经由消息队列和解析服务的解析处理后，由解析服务同步到设备影子。通过设备影子机制服务端的服务可服务直接修改设备影子中的配置，由影子服务处理iot终端与服务端的配置同步。实现系统内业务服务于终端管理控制的功能解耦，不需关心设备的在线状态。

401～406为iot设备到服务设备端的状态数据上报过程，410～416为web或app通过api方式获取iot设备数据的过程。

在步骤401中，iot设备通过网络与目标接入服务器建立连接并完成身份认证后，iot设备发送设备状态数据到接入服务器。

在步骤402中，接入服务将收到的设备状态数据连同接入服务类型(基本协议标识)、channelid和接入服务实例id构建为一条消息发布到消息队列的特定topic中。

在步骤403中，解析服务通过订阅自身支持的协议的topic，并尝试拉取数据。

在步骤404中，解析服务对数据进行解析，如果通讯数据被加密则先进行解密。在这个过程中如果需要获取数据对应的设备相关数据，则可通过channelid作为关键词key进行获取。对于单一解析服务适配多协议的解析服务实例，则会根据实际的协议特点以及通过channelid从缓存中获取特定的设备信息。解析服务会额外使用缓存维护channelid、设备id、协议类型的关系，而不是在其他的位置。优选地，channelid的使用不会出现在业务服务中。

在步骤405中，解析服务将完成解析的数据更新到设备影子中。

在步骤406中，可选的，解析服务异步通知业务服务某设备状态更新了，此处同样选择使用消息队列实现由解析服务到业务服务的事件通知。如果业务服务需要数据则在影子服务中获取对应的数据。

自此iot终端完成上报自身状态数据的处理过程，这里不对业务服务收到状态更新通知后可能执行的动作做描述。

在步骤410中，用户或第三方通过api调用获取特定设备的状态数据等信息，这里不考虑对网关以及系统内部的其他调用部分。

在步骤411中，业务服务向影子服务请求设备状态数据等信息。

在步骤412中，影子服务通过iot设备的id从缓存或数据库中获取对应设备的设备影子数据。

在步骤413中，影子服务将获取的设备状态数据等信息返回给业务服务

在这里，如果影子服务返回的设备状态中存在未解析的数据时，则先执行步骤414～417.如果影子服务返回的设备状态是完全可读的无需解析的数据时，则跳过步骤414～416，直接执行步骤417将设备状态数据返回到调用方。由于本实施例中接入的设备可能会包含数百项参数，采用传统的数据对象或json并不是一个适合的选择(同时考虑到业务场景)，所以根据设备数据的特点不同设备影子采用不同的方式保存设备的状态数据。

在步骤414中，当业务服务得到的设备状态数据包含未解析的字节数据时，调用解析服务对数据进行解析。

在步骤415中，解析服务对解析数据和对应设备的协议类型进行数据解析。这里所述的解析服务可以是对应协议的解析服务实例，也可以是多协议支持的通用解析服务实例(前面有提到过)，这里的具体实施方案选择取决于系统内部数据处理压力的集中位置。

在步骤416中，将解析后的设备状态数据返回给调用方。

在步骤417中，将得到的设备状态数据以及一些需要的数据一同打包并返回给api请求。

以上仅为一种示例，特征的增减和组合不限于上面的描述。

此外，作为一个实现方式，针对下行数据：

将与所述iot设备关联的至少部分通讯数据同步到对应的所述设备影子，包括：响应于从业务服务接收到所述下行数据，将所述下行数据同步到对应的设备影子；

所述影子服务单元从所述iot设备对应的所述设备影子中获取所述通讯数据，包括：所述影子服务单元从所述iot设备对应的所述设备影子中获取所述下行数据；

响应于从所述设备影子中获取到所述下行数据(为服务端发送给iot设备的)，所述解析服务单元将所述下行数据发布到消息队列对应的主题中；

所述接入服务单元，通过对所述消息队列中主题进行订阅，从所述消息队列获取所述下行数据，将所述下行数据发送给对应的iot设备。

进一步地，当所述业务服务单元将下行数据更新到设备影子后，所述业务服务单元通知所述解析服务单元所述下行数据的变更时间。以便解析服务单元获取所述下行数据以通过接入服务单元下发至iot设备进行同步。

下面以为服务设备1向iot设备2下发配置数据为例对本申请下行数据传递的方案进行示例性说明。

图6示出了本申请的一种下行数据下发传递过程的一实施例的示意图。

如图所示，以配置数据的下发过程、长期离线设备的配置下发过程为例进行介绍。由各种业务服务产生的需要下发的配置数据均直接写入影子服务，由影子服务维护iot设备影子对象的数据并在恰当的时刻通知解析服务编码数据并发送至消息队列，最后经由对应的接入服务消费并下发至iot设备终端。当iot设备离线时放弃下发,等待iot终端上线后跟进流程触发配置下发动作。

在步骤420中，操作通过api的调用体现，将新配置提交到业务服务。

在步骤421中，业务服务将配置保存到影子服务中。

在步骤422中，业务服务通知解析服务配置变更时间。

在步骤423中，解析服务收到配置变更的通知后，向影子服务请求最新的配置。

在步骤424中，影子服务将最新配置应答给解析服务。

在步骤425中，解析服务将配置进行编码处理后，连同目标设备的channelid一同打包发送到消息队列(mq)对应的topic上(如前文所述(push/接入服务实例id))。

在步骤426中，对应协议接入服务实例通过订阅的topic(“push/接入服务实例id”)获取到需要发送的配置。

在步骤427中，对应协议接入服务实例根据channelid找到当前持有的对应channel，并发送数据到iot终端。

自此完成配置下发的过程。在下发配置的过程中如果目标设备不在线则会因不同的情况分别在步骤424、步骤425、配置426或步骤427提前终止配置流程。

无论终端设备是否长期离线，当设备终端连接服务端后(登录)，必会存在主动或被动的配置同步流程。

在步骤430中，由iot终端向服务端(当前说连接的接入服务实例)发起同步配置请求。

在步骤431中，由接入服务将接收到的请求发布到消息队列中(mq)。

在步骤432中，解析服务通过订阅的方式得到同步配置请求(同步骤402)。

在步骤433中，解析服务解析出同步配置请求，执行对应的协议业务，向影子服务获取最新的配置数据。

在步骤434中，影子服务将缓存/保存的设备配置信息应答给解析服务。

在步骤435中，解析服务将配置进行编码处理后，连同目标设备的channelid一同打包发送到消息队列(mq)对应的topic上(如前文所述“push/接入服务实例id”)。

在步骤436中，对应协议接入服务实例通过订阅的topic(“push/接入服务实例id”)来持续获取需要发送的配置。

在步骤437中，对应协议接入服务实例根据channelid找到当前持有的对应channel，并发送数据到iot设备终端。

进一步地，通讯数据中扩展数据类型作为一种特殊的数据类型，通常对实时性要求很高，存在即时性的业务需求，因此，在本申请中扩展数据类型的通讯数据不保存到影子服务或者只有部分数据如系统业务数据保存在影子服务中，且在传递的过程中允许丢弃。

下面以为扩展数据类型通讯数据的传递为例对本申请的方案进行示例性说明。

图7示出了本申请的一种扩展数据类型通讯数据的传递过程的一实施例的示意图。

首先我们介绍上行扩展数据和下行扩展数据的时序图，然后通过时序图的拆解对部分具体的扩展数据类型进行简要的介绍。首先我们介绍的是扩展数据类型的数据上报过程以及过程中可能存在的服务端行为。

在步骤440中，在完成连接的建立后，当iot设备终端因状态变化则会产生扩展类型的数据并上传到接入服务。

在步骤441中，接入服务实例将相关的信息与收到的数据一同打包，发布到消息队列(mq)对应的topic中。

在步骤442中，解析服务通过消费消息队列中的数据，获取到扩展数据类型的数据，并进行解析。

在步骤443中，如果解析服务逻辑需要更新设备影子，则进行设备影子的更新动作。

在步骤444中，如果解析服务逻辑需要通知业务服务处理，则进行异步的数据通知。

在步骤445中，如果业务服务在收到异步的上行数据通知，且存在业务需要更新摄影影子时，则进行设备影子的更新动作。

在步骤446中，如果业务服务在收到异步的上行数据通知，且在业务需要通知用户或其他服务时，则进行相关服务的实例调用。

在步骤447中，如果业务服务在收到异步的上行数据通知，且在业务需要进行相关数据指令的下发动作，这通过调用解析服务进行下行数据的下发动作。

在步骤448中，在步骤447存在的前提下，解析服务在收到下发数据的请求后，将下发数据跟进设备协议转换为对应的协议内容，并发布到消息队列对应的topic中。

在步骤449中，在步骤448存在的前提下，对应协议接入服务实例通过订阅的topic(“push/接入服务实例id”)获取到需要发送的数据内容。

在步骤450中，在步骤449存在的前提下，对应协议接入服务实例根据channelid找到当前持有的对应channel，并发送数据到iot终端。

自此我们完成了对设备上报扩展数据类型的整个完整流程。在实际的情况中，根据业务要求的不同，消息会传递到不同的位置而终止。例如注册数据(属于扩展数据)的上报，此数据虽然并非iot终端状态，但因其重要性需在服务端的业务流程中完全的通过上述的顺序依次进行。又例如设备状态变化数据上报(非设备完整或部分状态数据上报，可以与系统业务的实时性体验相关)，此数据实际用于如共享洗衣机等项目在设备进入特定阶段时，通过消息的方式通知服务端洗衣机已完成/进入某个处理阶段，由于此类信息是可丢弃的，在上述步骤中，仅存在步骤440至步骤444即完成整个处理过程。当存在由系统检查、定时任务触发的扩展数据类型消息下发的，则由步骤445或者步骤446开始，至步骤450结束的过程。

当存在于用户交互的相关业务流程时，在步骤460中，用户/第三方操作行为通过api调用到业务服务对应实例。

在步骤461中，如果业务服务逻辑需要更新设备影子，则进行设备影子的更新动作。

在步骤462中，如果业务服务逻辑需要将相关扩展数据下发到iot终端，则调用解析服务进行数据的下发。

在步骤463中，当业务服务完成系统业务后立即返回告知调用方。

在步骤464中，在步骤462存在的前提下，解析服务在收到下发数据的请求后，将下发数据跟进设备协议转换为对应的协议内容，并发布到消息队列对应的topic中。

在步骤465中，在步骤464存在的前提下，对应协议接入服务实例通过订阅的topic(“push/接入服务实例id”)获取到需要发送的数据内容。

在步骤466中，在步骤465存在的前提下，对应协议接入服务实例根据channelid找到当前持有的对应channel，并发送数据到iot终端。

上述过程存在于如当需要探测特定iot设备终端的网络通讯延迟，当用户访问设备信息页面触发api，由服务端发起的通讯延迟的计算获取。此操作过程由步骤460开始到步骤465结束第一个阶段的执行(因系统业务需要包含步骤461)。在此之后iot终端的应答会触发步骤440到步骤445的执行过程。当业务过程需要通过多次通讯计算单位时间内的延迟均值时，则会在这部分反复触发执行步骤440至步骤450的全部步骤。在服务端发起通讯延迟的计算获取要求后，在用户界面上同样会不断的向服务端请求最新的延迟数据，此部分按照步骤410至步骤417中的部分内容执行即可。

虽然在本申请中记载的示例性实施例中，将服务设备划分为了多个服务单元，但可以理解的，这种划分不是限定性的，实质上，将多个单元的功能组合为一个单元完成，或者将一个单元的功能分开为多个单元分别完成，都是容易想到的变形，都在本申请的保护范围内。

本申请还包括对应上述服务设备的一种提供物联网服务的方法，如图8示出了本申请的提供物联网服务的方法的一实施例的示意图。

步骤s1，生成与iot设备对应的设备影子，将与所述iot设备关联的至少部分通讯数据同步到对应的所述设备影子；

步骤s2，当从业务服务和/或接入的iot设备接收到对所述通讯数据的使用请求时，从所述iot设备对应的所述设备影子中获取所述通讯数据，以供所述业务服务和/或接入的iot设备使用。

由于本实施例的方法所实现的处理及功能基本相应于前述设备的实施例、原理和实例，故本实施例的描述中未详尽之处，可以参见前述实施例中的相关说明，在此不做赘述。

本申请还包括一种服务器，包括至少一个处理器，以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述至少一个处理器通过执行所述存储器存储的指令执行本发明实施例所述的物联网服务的方法。

基于同一发明构思，本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行本发明实施例上述物联网服务的方法。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化与修饰，均仍属于本发明技术方案的范围内。