基于微服务架构的开放物联网框架

一、引言

物联网（Internet of things）这一术语并不十分新近以来，出现了多个不同的名称，其中之一便是“无限事物互联网”，即万物皆可相互通信的梦想世界。如今，大量的物理实体相互连接并集成到信息空间中，通过通信技术交换所产生的数据。此前，许多研究工作 [3‐4] 集中于连接性挑战。然而，随着新开发的系统的出现，现有结构催生了若干新的研究难题。随着技术的发展，物联网应用 [5‐11] 开始关注如何整合现有网络设施以及系统设计的开放性和可扩展性。与现有的服务（如电信服务或互联网应用）相比，物联网服务面临着新的情况。

从感知层（涉及大量传感器）收集的海量信息，根据需求被进一步处理并传递给不同的应用，进而用于触发相应的协同业务系统。随着物联网技术在日常生活中的广泛应用，传感器和对象所产生的事件数量正变得极为庞大。任务极其艰巨，庞大的服务需要响应各类请求。物联网服务系统应协调人

摘要：随着物联网（IoT）的不断发展和演进，单体式应用的规模变得越来越大，结构也更加复杂。这导致其可扩展性、可扩展性和可维护性较差。为应对这些挑战，微服务架构因其灵活性、轻量级和松耦合特性被引入到物联网应用领域。然而，现有的物联网微服务框架主要集中在特定领域，因此极大地限制了其应用范围。本文提出了一种适用于物联网应用的通用微服务系统框架，该框架具有更好的可扩展性、可扩展性和可维护性。我们介绍了其系统设计及相关微服务，并重点阐述了从服务层到物理层的核心服务和设备通信。该框架具备更强的支持互操作性和容纳异构对象的能力。此外，该框架能够轻松实现更多应用集成，如自动化、智能化、地理服务和大数据。

关键词：物联网；物联网；微服务；软件架构

特别是，该框架集成了系列微服务，通过分层预处理大规模传感器数据，提供了强大的异构数据融合机制。

本文的结构如下：第2节介绍了关于物联网应用的单体式和微服务架构的相关研究。第3节讨论了建议的微服务物联网系统架构。第4节介绍了系统的实现方法，并对相关物联网系统进行了比较。最后，第5节总结了微服务物联网系统的优点与局限性，并展望了未来的工作。

II. 相关 WORK

物联网系统之前的研究主要包括两类：单体式架构和微服务架构。

2.1 单体架构

在单体架构中，[1]软件系统被部署为一个单一解决方案，其中功能上可区分的各个方面相互交织[2]。单体架构的天然优势在于模块独立性、统一标准和技术栈。许多研究从单体架构的角度提供了解决方案。

早期的物联网研究主要集中在硬件网络以及底层软件技术[3]。例如，无线传感器网络（WSN）[4]是物联网的主要实现方式之一，但其容量有限且可扩展性较弱。为解决这些问题，一些研究如ubiSOAP[5] WoT/SDN [6]专注于高层物联网应用编程，采用标准中间件实现分层通信。然而，这些系统的可重用性和可移植性较低。

TinySOA [7],塞尔维拉[8]以及一系列典型的面向服务架构（SOA）[9]已被应用于不同场景中。为了提高SOA的可扩展性，还提出了事件驱动的SOA（EDSOA）物联网技术[10] 。此外，OpenIoT [11]拓展了 SOA的概念，并实现了物联之网（WoT）。然而，随着系统功能的不断增加，物联网在分布式环境中的复杂性也日益提高。

单体架构存在一些不可避免的缺陷。首先，整个系统是一个统一的应用程序；只能通过多次部署来提升系统性能，而过载的功能会产生瓶颈，造成计算资源的浪费。其次，在系统变更和演进过程中，由于依赖关系较高，某个功能的修改可能会影响其他功能，这也给重新部署、维护和持续集成带来了复杂性。最后，整个系统使用单一的技术栈和开发标准，从而限制了解决物理异构性问题的方法。

2.2 微服务架构

为了克服单体架构的缺点，许多研究人员开始采用微服务架构 [12]。微服务架构是一种新的系统软件设计模式。它建议将一个庞大而复杂的应用程序划分为小型可管理的组，每组负责处理相关服务。根据其特定的业务职责，每个微服务专用于单一业务功能。因此，可以实现独立服务

程序员可以通过简化的集成享受编码的自由

简而言之，随着物联网技术的发展，传统架构已无法满足异构、互操作、可定制和可扩展系统的需求。为应对上述挑战，我们提出了一种开放物联网框架，通过将物联网系统分解为执行各类任务的微服务来实现。该框架在核心服务中采用消息驱动和注册/发现机制，能够轻松扩展、演进并集成第三方应用，以支持互操作性和可扩展性。此外，系统使用设备插件屏蔽硬件设施的差异，从而支持更多异构平台。

本文讨论了两种架构之间的通用比较。基于这些基础，作者提出了一面向物联网的微服务系统框架。

III. 系统架构

3.1 系统设计

新一代物联网框架的设计考虑了在开放可扩展平台设计中，现有信息服务系统在高内聚低耦合方面的集成与可重用性。该设计的核心思想是采用微服务架构的概念，基于对现有物联网系统的分析，通过将系统的所有业务功能解耦为独立且特定的服务来重构。该设计采用轻量级通信机制实现服务之间的交互。

通过连接在一起，提供一个完整的物联网平台。该设计由八个微服务和一个与所有微服务协调的核心服务组成，这些微服务分别是：地理服务、安全、租户、设备、大数据、自动化、人工智能和应用。该系统不仅限于这些服务；其设计灵活，可根据应用需求进行修改或扩展。

1. Geo Microservice ：该服务旨在通过空间关联来组织设备，从而将设备的事件以这种方式分组，例如支持位置感知的设备。地理信息服务提供GIS图层，用于实现地图API，以在其上渲染位置数据。该服务提供REST API，用于调用地图UI库，渲染图层或动态创建图层。

2. 安全微服务 ：该服务提供用户/组/角色管理、认证和授权、访问控制、单点登录和联合身份、身份治理与管理。同时还支持安全监控、报告和审计。访问 REST服务需要用户提供凭据。在对实体执行创建/更新操作时，会存储已认证用户的访问控制策略，以指明该用户可执行的操作。

3. 租户微服务 ：基于多租户设计，该服务通过一个核心服务实例为多个物联网应用提供支持。每个租户拥有独立的数据存储和处理管道，从而确保不同租户之间的数据和处理不会混杂。大多数组件也设计为支持多租户，以实现不同租户在处理逻辑和数据上的逻辑隔离。

4. 设备微服务 ：设备服务管理各种类型的设备插件，并实现与底层硬件的不同通信协议，用于从传感器收集数据并向执行器发送指令。该服务为核心服务提供调用设备插件回调的接口。它使用包含扩展上下文的元数据来对应特定的设备组件。

提出的架构设计使用一个名为核心服务的中心服务来控制和协调系统中的其他微服务；它还用于引导一个或多个租户引擎，这些引擎负责处理大部分其他业务逻辑。该系统采用REST设计模式，以方便对对象数据的访问，并支持与其他网络的互操作性。核心通信服务涵盖微服务与外部网络之间与对象节点的通信，由代理微服务提供，以实现异步通信。在通信服务的开发中，我们采用REST与客户端应用进行通信。

除了使用REST接口与微服务进行交互外，系统还实现了发布‐订阅模型，以向客户端通知其已订阅主题中的感兴趣事件，所有客户端的已订阅主题都会将即将到来的事件通知推送到客户端应用程序。客户端可以通过核心服务代理订阅多个感兴趣主题，以便接收来自多个服务的通知。

图1显示了提出的微服务物联网系统的架构。整个系统由不同的微服务组成，这些微服务

大数据	kairosDB	kairosDB	kairosDB	kairosDB	kairosDB
	kairosDB	kairosDB	kairosDB	kairosDB	kairosDB
	MongoDB	MongoDB
		Redis	Redis
		Redis	Redis
		Redis	Redis

自动化
	复杂事件处理引擎 工作流	复杂事件处理引擎 工作流

租户
资产 云

地理信息服务
地理服务器 地图服务器
开放图层

AI	数据挖掘	数据挖掘
	数据挖掘	数据挖掘
	图计算 语义网	图计算 语义网	图计算 语义网
## 3.2 核心微服务规范

核心微服务是该系统中一个非常重要的微服务，因为我们使用它来处理所有与设备及相关的微服务交互的功能。它的职责包括：（i）事件管理；（ii）插件管理；以及（iii）资源发现。事件管理器负责微服务与设备之间的通信。核心服务完全基于事件，任何微服务交互或环境变化都会生成事件。当事件在通道上发布时，触发器可以捕获这些事件。通过在自动化微服务中定义，每个触发器都关联一个或多个命令。从该架构可以看出，程序行为不是预先确定的，而是在运行时完全可以修改的，从而使其在楼宇自动化中的任何可能应用中都具有极高的灵活性和适应性。

核心服务由以下组件提供，如图2所示：BusMsgListener 实现了一系列总线监听例程，用于接收来自对象的消息并将其发送到其 BusConsumer。
MessageSubscriber 用于订阅/取消订阅消息主题，并在通道上注册。
BusService 提供了在逻辑通道上发送或回复消息的便捷方法。触发器是一种事件过滤器，它通过通道监听所订阅的事件。如果事件满足触发器提供的条件，它将调用行为管理器，该管理器将一个通用请求或多个逻辑命令转换为一系列硬件命令，传递给对象动作（ObjAction）。然后这些命令将自动发送到相应的执行器。

class 核心服务
行为管理器
触发器
自动发现
对象动作
| 加入插件 | | |
| — | — | — |
| 加入插件 | | |
| 加入插件 | | |
| | | |
总线消息监听器
消息订阅者
总线代理 总线服务
消息生产者
插件仓库 插件

3.3 设备微服务

该系统可以通过可扩展插件管理大量异构设备。传感器和执行器插件是小型软件包，能够处理底层设备通信，并为微服务提供 API。每个插件由设备微服务管理，并在系统启动时自动加载和初始化。插件与核心微服务之间的通信通过消息中间件自动管理。设备微服务主要支持以下功能：

1. 设备注册
   设备可以通过 API 调用或自助注册的方式手动创建。硬件向设备服务提供一个唯一标识，然后创建一个新的设备记录。将相应地作为系统的一部分被创建，并开始接收新的传入事件。在此系统中，每个硬件设备都应具有唯一的标识，以便能够单独寻址。当设备首次启动时，它会连接到核心服务网络，在与核心服务建立连接时将触发一个注册事件。然后，设备微服务检索相应的插件并将其注册到核心服务，作为响应，核心服务会向设备服务发送一条消息，指示注册结果。

2. 设备事件处理
   成功注册后，设备可以向核心服务交换各种类型的事件。这些事件可能包括：位置更新、温度、湿度以及从传感器获取的其他数据，或警报。事件通过插件传递给核心服务，插件提供了一种模块化的方法，以支持处理传入数据的新功能。

3. 命令传递
   每个在设备服务中管理的硬件都有一个关联的硬件类型规范。该规范链接到与设备对应的可执行命令列表。这些命令和参数可以通过管理控制台或REST调用进行修改。当命令执行时，插件会将命令编码为预定义格式，并通过指定协议发送。图 3 说明了设备服务的工作流程：

符号和含义 DeviceId：硬件的唯一标识符。
URI：设备的互联网地址。
Metadata：包含硬件设备信息的元数据。
Data：设备提供和消耗的数据。
Topic：数据的主题。

工作流程

1. 初始化一个设备并注册
   a) 设备微服务向核心服务中的插件仓库注册（设备ID，URI）。
   b) 插件组件在插件仓库中通过（设备ID）搜索设备插件注册信息。
   c) PluginsRepository 返回配置的设备 (MetaData)。
   d) 根据设备元数据，插件组件使用（DeviceId, URI）挂载设备插件。
   e) 插件向应用程序返回设备（MetaData, URI）。

2. 查询设备
   a) 一个应用程序通过（设备ID）向插件组件发送查询。
   b) 插件组件在插件仓库中通过（设备ID）搜索设备插件注册信息。
   c) PluginsRepository 返回配置的设备 (MetaData)。
   d) 根据设备元数据，插件组件使用（DeviceId, URI）挂载设备插件。
   e) 插件向应用程序返回设备（MetaData, URI）。

3. 设备与微服务之间的通信
   a) 应用程序开始在事件代理上订阅一个（Topic）。
   b) 设备服务发布（Topic, Data）。
   c) 当数据符合特定主题时，应用程序获取（Topic, Data）。

sd 设备服务
插件仓库 插件仓库 插件 设备
微服务 微服务
a 应用程序
| 代理 | |
| — | — |
1.
2.
3.
发布 (主题, 数据)
订阅 (主题)
挂载 (设备ID, URI) (设备ID, URI)
发布 (主题, 数据)
配置 (元数据)
搜索 (设备ID)
注册 (设备ID, URI) (设备ID, URI)
返回 (URI, 元数据)
查询 (设备ID)

3.4 物理层

如前所述，设备服务使用插件来屏蔽硬件平台的差异，并为核心服务提供统一的接口，从而使系统能够支持各种硬件设备平台，例如Arduino、树莓派、Android以及一系列嵌入式操作系统。为了快速简便地集成这些流行平台，提出的系统提供了以下功能：设备识别、连接导向、注册新设备、事件处理和命令接口。这使得用户可以专注于构建应用，而不必为基础设施问题困扰。软件开发工具包（SDK）维护一个内部数据结构，用于表示环境、其中的对象及其状态。通过一种语言无关的方式（XML、JSON、POJOs等）将这些数据提供给外部客户端，就像他们可以看到用户所见的相同环境地图一样；作为开发者，您可以忽略硬件层面的因素及相关问题，专注于业务流程。由此，开发者可以用自己喜爱的语言开发应用，仅仅连接到框架并操作文本消息。

IV. 实现与比较

在本系统的开发中，我们使用 Docker 和 Kubernetes 作为微服务容器。核心服务基于 J2EE 平台开发，采用 JBoss 作为应用服务器，并使用 Resteasy 实现 REST 接口；异步通信通过 ActiveMQ 实现。安全服务基于 Jasig CAS 组件。自动化服务中的复杂事件处理（CEP）和事件序列分析采用 Esper 组件。人工智能服务中，采用 Apache Spark 进行数据挖掘和图计算。地理信息服务基于 GeoServer 和 OpenLayers 组件开发。搜索引擎优化应用使用 Apache Solr。大数据服务中，采用 Redis 用于图像数据存储，kairosDB 用于时序数据存储，MongoDB 用于文档存储。

如上所述，系统支持多种硬件平台，因此在硬件设备系统中开发目标软件以及在服务端系统中开发相关插件都较为容易。服务API实现该系统支持REST se一个服务，通过标准HTTP动词指示 CRUD 操作，如图8所示。

我们演示一些设备服务的 REST API 调用如下：

• 创建新设备 ：硬件需要一个唯一标识来进行系统内的寻址。
  请求 URI: POST /iotmicservice/设备/
  请求头部(简要):
  json { "设备名称": "温度传感器", "硬件ID": "57d99d89-caab-482a-a0e9-a0a803eed3ba", "插件": "com.plugins.devices.temperature" }

• 为设备添加触发器 ：测量例如温度、湿度或位置等可以作为设备触发器添加到请求中。
  Request URI: POST /iotmicservice/devices/{hardwareId}
  Request header (brief):
  json { "hardwareId": "57d99d89-caab-482a-a0e9-a0a803eed3ba", "temperature": [ { "eventDate": "2016-11-21", "value": 65.0 } ], "trigger": "alarm" }

• 列出设备的事件 ：根据给定条件，列出分配给该设备的所有事件。
  请求 URI: GET /物联网服务/设备/{硬件ID}/事件

表 I 微服务物联网框架 REST API
REST 动词
—
GET
GET
POST
POST
PUT
DELETE

为了展示微服务物联网系统的优势，我们在表2中对当前物联网系统进行了比较。

表 II 比较结果
功能
—
异构性
可扩展性
发现
CEP
开发运维

通过比较可以看出，该物联网系统具有更高的灵活性、可扩展性和可维护性，并且完全支持持续交付和开发技术。

V. 结论与 FUTURE WORK

本文中，我们提出了一种新的微服务物联网框架，相较于现有物联网系统（如单体式和微服务系统），该框架具有更优的功能。所提出的系统采用模块化方法，提供了一个更为通用的微服务物联网架构，在灵活性、可扩展性和平台独立性方面优于现有方法。此外，我们还介绍了关键组件的功能，并说明了其应用。在所提出的微服务物联网框架中，所有物联网设备和对象都被抽象为系统内的资源插件。

微服务在设备上的分配通过与核心服务交互实现动态工作，其中核心服务通过使用相关插件与设备进行交互，设备插件可以动态挂载或卸载，插件的升级也可以在不影响整个系统的情况下完成，甚至整个微服务模块都可以自由替换。因此，该系统不仅提供了最佳的物联网服务，还对物联之网具有良好的支持，并具备更强的适应性、可扩展性和互操作性。

对于微服务架构的实践，仍有许多问题需要研究，例如协同事务处理、网络延迟、网络故障、消息序列化等问题。此外，微服务物联网在机器上的应用、学习、搜索引擎优化以及其他分布式计算场景也需在未来持续探索和研究。