物联网系统软件架构的系统性综述及向微服务架构演进的未来方向
摘要
基于物联网的系统和软件通过互连个人、网络、服务、计算机和人工制品,使得计算可以在任何时间、任何地点 进行,从而形成自治的数字化社区。作为软件密集型应用的蓝图,软件架构明确了网络规划、开发和变更阶段的 复杂性,以高效且有效地构建复杂的物联网驱动应用程序。然而,目前尚缺乏关于物联网系统采用微服务架构 (MSA)的研究现状的全面分析。本研究旨在探索用于设计和开发物联网软件的架构概念与实践,推动物联网领 域的前沿发展,并针对填补已识别的空白,提出关于物联网软件采用微服务架构的建议与推荐。本文开展了一项 系统性分析,涵盖了2005年至2020年1月期间发表的140篇经过定性筛选的文献,涉及现有的物联网解决方案。
共有140篇文章被纳入本次系统性文献综述(SLR)。本研究的发现展示了多种研究主题,包括用于构建物联网 软件的软件架构风格、模式和模型。本研究呈现了基于云的计算环境、自治系统、软件定义网络、响应式应用以 及由物联网驱动的基于代理的系统;(1)提出了用于物联网的十三种微服务架构(MSA)架构和设计模式及其 模式分类;(2)将用于物联网的软件架构划分为九个主要类别及其子类别;(3)列出了二十三项最受关注的物 联网挑战;(4)实现了物联网挑战与软件架构解决方案之间的映射。该研究揭示了在物联网软件架构方面的创 新工作和发展趋势,有助于实现物联网软件的可重用性、自动化和人类决策的创建与动态适应。本系统性文献综 述的成果在过去15年对微服务架构采用的研究基础上,为软件产业、软件工程界和计算机科学界提供了诸多有价 值的建议。本研究反映了对架构实践和原则的提炼认知,有助于研究人员和实践者促进信息共享,明确物联网软 件中的软件架构角色与职责。
关键词 物联网 · 物联网 · 软件架构 · 微服务架构 · 云计算 · 系统性研究
引言
当技术成为关键差异因素时,企业高管会持续与IT领 导者进行战略对话,以更好地理解他们所创建的技术 如何满足其业务需求。软件架构指的是将分布式系统 在逻辑上划分为软件组件。一个系统的软件架构代表 了该系统的组织或结构,并描述了其工作方式。设备 代表执行特定功能或一组功能的组件集合。
本文是专题系列“人工智能、图像处理、物联网和云应用中 的计算方法进展”的一部分,该专题由Bhanu Prakash K. N.和M. Shivakumar担任客座编辑。
* 阿卜杜勒·拉扎克 Dr.razzaq@zju.edu.cn; abdull.razzaq786@gmail.com 1海洋信息科学与工程,浙江大学,舟山 316000,中国
物联网微服务架构
软件架构是主要的工件,它能够实现复杂软件系统的 直接且可预测的开发[8]。微服务架构支持复杂系统应 用程序的开发,并将系统应用程序划分为多个部分或 进行分解[9]。微服务正成为物联网中独立服务提供者 的核心。不可否认的是,通信和组合风格的变革策略 呈现出周期性变化的趋势。在物联网中,应用程序需 要由一系列小型[10],独立服务组合而成。由于微服务 架构在物联网和分布式计算中的可行性,因此被广泛 采用。基于微服务的大规模编程平台,旨在增强分散 信息在物联网设备、边缘和中心云之间的引导与处理 能力[11]。
系统性研究的动机
在过去几年中,物联网软件架构的开发和已发表的研 究取得了显著进展。基于软件的架构解决方案有助于 开发先进的物联网应用、移动和云计算技术,这些技 术通过支持智慧城市的软件生态系统和边缘计算来支 撑软件。过去几年中,产品项目组织和软件组织已经 发现
微服务方法具有价值,因为它允许团队和软件组织提 高生产力[12]。它由于取得了更成功的结果而规避了当 前的软件架构,这也是全球各行业中微服务复兴的原 因。在某个时间点,它将成为适应其灵活环境的物联 网软件的最佳架构风格。目前还有很多研究需要解决。
本研究工作的贡献
本研究发现,关于物联网软件的软件架构解决方案以 及采用微服务架构用于物联网软件的系统性文献尚不 充分。有必要提供精确的系统性文献来填补这一空白。
本研究调查了当前关于物联网软件架构解决方案的认 识与重要性的文献。相关信息以不同形式存在,需要 进行整合以形成系统性文献。
•研究人员:现有研究的一个新假设影响了物联网软 件架构角色的最新进展和分析。
实践者:认识并理解将软件架构解决方案作为最佳实 践来应用,并扩展物联网软件。
用于物联网软件的微服务架构(MSA)架构和设计模式 及模式分类。
物联网软件的软件架构分类,分为主类别和子类别。
•软件架构解决方案与物联网挑战的映射。
最受关注的物联网挑战列表。
研究概述
本研究的其余部分组织如下。下一节介绍了相关研究 的文献,接着展示了针对研究问题(RQs)执行的系 统化过程。随后的部分呈现了该系统性研究的结果, 并关注已发表工作的量表、形式和分类。在最后一节 之前,阐述了物联网面临的问题及其设计方法,以及 出现的软件架构解决方案与物联网挑战,进一步讨论 了新兴研究趋势和未来研究方向,以采用微服务架构 (MSA)用于物联网软件,并给出了研究结果及对研 究人员的建议,同时指出了效度威胁。最后一节通过 总结完成本研究。
相关研究
本研究的分析阐明了设备设计对物联网应用的价值。
然而,这篇文献综述指出了一些基本问题,这些问题 需要针对物联网应用的软件架构解决方案。关于文献 的讨论回应了本文提出的问题,展示了与物联网应用 相关的所有问题。
物联网面临的最突出的问题包括互操作性、可扩 展性、数据量、移动性、安全与隐私、实施与能力 [13, 14]。其中,数据的安全与隐私是需要重点关注的 关键问题[15]。数据观测挑战在于制定标准与实践,通 过设备、领域和用户之间的传感器数据集成,推动服 务和新型应用的发展,从而实现更详尽的生态系统分 析与理解[16]。正如[17],大量多样的物联网应用、设 备和实施所表明的,可能导致信息数据形成高度异构 的集合,在信息数据的一致性、数据、频率与时序的 配置与解释方面存在差异。因此,互operability是物联网 解决方案中必须考虑的关键因素,以实现设备间的数 据共享与协作。
物联网架构和解决方案模型必须对接异构社区, 以实现协同工作和理解。物联网软件工程在考虑新应 用程序、服务和设备时面临诸多问题。以用户为中心 的开发、电子服务、移动性、智能设备、电子健康和 植入式设备对确定软件需求以及开发可靠的安全软件 提出了显著挑战[18]。物联网架构是碎片化的,无法协 调信息或集成来自各种存储库的数据,这是导致信息 数据共享、系统升级和技术复用中出现众多问题的主 要原因。这些架构需要将多种资源和功能集成到更大 系统中[19]。由于物联网系统的使用日益增加,迫切需 要一种明确定义的软件架构,该架构必须能够灵活适 应智能设备以及在不同环境下的数据集成[20]。
物联网与软件架构
物联网术语有时被称为物联之网 [3, 21]。物联网作为一个 概念,在统一的理解方面尚有不足,且由于物联网的不同 应用,其定义仍然模糊。IEEE 的一项工作旨在
整合物联网的总体概念、技术与架构及其应用[21]。物 联网的通用架构根据IEEE原则和可访问的参考模型展 示了分层结构。该分层结构包含三层:第一层为应用 层,第二层为通信层,第三层为传感器设备层(见图 1)。图1展示了物联网及其相应软件架构的高层概述。
使用架构模型,可以最大限度地减少物联网设备 设计与实施问题。此外,物联网材料及其互连也可以 与软件架构的连接器与组件相关联,以有效描述、构 建、扩展、管理和部署物联网软件[22]。可以从架构组 件及其连接器出发,采用模型驱动工程的方法实现代 码自动生成[23];同时,也可以从现有源代码中恢复架 构。我们旨在探讨软件架构在物联网系统开发、管理 和运维中的作用。风格与模式被视为兼容的概念,通 常用于指代软件架构中可互换的专业知识与实践指南 [23, 24]。
基于当前这项研究研究,我们更接近于得出物联 网架构的研究已显著增长的结论。我们发现,针对用 于物联网的软件架构及其未来方向的研究尚未得到充 分探索。
本研究旨在通过系统性方法对现有研究进行分类, 以帮助理解架构及挑战的解决方案。我们识别了微服 务的最有用模式,并将其与物联网进行映射(见表9)。
为了构建物联网软件,我们将现有模式确定为最佳实 践。从科学角度来看,本系统性研究在实践和设计原 则方面建立了物联网架构,[22],包括可重用性和设计 知识[23, 25],以分析其影响和未来方向。针对当前研 究,本研究聚焦于物联网挑战(见表7)以及通过软件 架构映射得出的解决方案(见表8、图10)。其余贡献 细节在论文中讨论。
第1层是架构用户界面层,允许用户通过其设备进 行交互,并通过第2层进行通信。第2层是与存储(数据 库)第3层通信的逻辑层。它可以读取状态并与所有连 接的事物进行通信。1展示了抽象级架构模型,显示了 物联网系统实现及其配置复杂性的降低。此外,物联网 事物可以映射到架构中的连接器与组件,从而有效维护、 开发和部署物联网系统[22]。
系统性研究的研究过程
使用目标‐问题‐度量方法表述的研究目标 [26, 27],是 分析软件架构,以及用于物联网软件的探索和分析, 关注物联网软件的架构解决方案和微服务架构的重要 性,进而研究架构和设计模式、物联网挑战、根据物 联网软件的架构分类,架构解决方案与物联网挑战之 间的映射,以及在理解物联网软件背景下对软件架构 的认知。我们的目标是将其分解为主要研究问题和子 研究问题(见表 1)。
系统性分析用于识别和映射当前研究,以解释其 影响、解决研究空白以及指明未来研究的方向[7, 23]。
在整个系统性研究过程中,根据开展系统性研究的规 则(表2),研究问题的相关性对于对可行主题进行无 偏见的调查至关重要。
研究搜索
时间段 时间设定在2005年至2019年之间,以及我们开始 此次系统性研究搜索的2020年初。
检索策略
在开始阶段,我们根据研究主题(用于物联网的软件 架构解决方案及未来微服务架构的采用)和研究问题 来区分检索词。我们遵循“Kitchenham和 Charters”的方法[28],并列出了当前文献研究中常用 的物联网系统软件架构、物联网挑战(见表 7)、物联 网挑战与软件架构解决方案的映射(见表 8,即物联网 挑战与软件架构解决方案的映射),以及微服务架构 的架构趋势和设计模式(见表 9)。干扰术语涉及架构 领域。最初,我们纳入了“软件架构”和“物联网” 作为初步检索中的检索词,这些术语与架构解决方案、 架构风格和设计模式相关联。在初始检索中,我们尝 试了几种不同的检索词组合,但无法使用完全相同的 组合,因为不恰当的检索会产生大量非必要的结果。
我们通过在各个数据库中使用初步查询来尝试找到一 种可行的方法。以下列出了研究对象和干预措施中的 检索词:
研究对象 架构,软件架构,物联网,物联网,微服 务架构,MSA,面向服务的架构。
选择标准
研究人员描述并逐步明确了在选择文章之前提到的考 虑和排除标准(见表 5)。研究人员还使用这些标准进 行了试点测试
替代方案
并利用这些标准进一步解决了与此相关的 任何矛盾和错误假设。图 3 展示了我们用来划分相关 文章组的头脑风暴过程。
第一轮研究筛选
我们使用查询技术对选定的文章进行分类。我们根据 名称遵循选定文章的分类标准。如果无法通过名称确 定,则保留这些选定的文章进入下一轮筛选。我们将 具有标题、关键词和摘要的文章分组,并收录于不同 的数字图书馆中,例如ISI科学网、IEEE Xplore和 Science Direct。其他在线图书馆包括ACM数字图书 馆、威立、SpringerLink(见表4)。由于数据库限 制,查询术语根据标题和摘要进行整理。
第二轮
我们根据选择标准(见表5)在第二轮中研究了选定的文 章的摘要。结果
表4 系统性研究中包含的数字数据库
| # | 数字数据库 | 检索词 | 网址 |
|---|---|---|---|
| D-Db1 | IEEE Xplore | 摘要、标题、关键词 | IEEE图书馆 |
| D-Db2 | Scopus | 关键词,标题 | Scopus图书馆 |
| D-Db3 | ISI科学网 | 摘要、标题、关键词 | ISI图书馆 |
| D-Db4 | ACM数字图书馆 | 摘要,标题 | ACM图书馆 |
| D-Db5 | SpringerLink | 关键词,标题 | 施普林格图书馆 |
| D-Db6 | Science Direct | 关键词,标题 | Science Direct图书馆 |
| D-Db7 | 威立 | 标题 | 威利图书馆 |
表5 系统性研究中的纳入和排除标准
纳入标准
- 同行评审
- 讨论软件架构与物联网
- 发表于期刊、会议和研讨会
- 2005年之后发表
排除标准
- 非英文撰写
- 若论文有扩展版本,则排除先前版本
- 如果是灰色文献(即技术报告、进行中的工作)则排除
- 进行中
- 社论、海报、教程、幻灯片、主题演讲
- 未通过电子方式获取
第三轮
在上一阶段,我们阅读了完整的文章以确定是否应包 含该文章。作者们经过讨论并最终就论文是否发表达 成一致。
数据提取
我们提取了每项所选研究中出现的重要信息(见表 6), 以回应本系统性研究及其四个主要研究问题和八个子 研究问题。为了进一步综合,这些独立的信息被存储 在一份MS Excel电子表格中。
数据综合
本节中我们回答研究问题,目标是将其分解为主要研 究问题和子研究问题(见表1)。研究问题的结果可直 接关联到本研究的目标:识别物联网系统中最受关注 的新兴挑战(RQ2.1,见表7);识别用于物联网的架 构解决方案(RQ2.2,见表8),并将这些架构解决方 案映射到缓解物联网挑战的方案上(见图10);对用 于物联网的架构进行分类(见图9);讨论软件架构用 于物联网的优势以及软件架构对物联网系统的影响; 探索物联网软件的微服务架构的架构模式和设计模式 (RQ2.3,见表9)。随后,我们将探讨并突出当前及 不断发展的研究趋势,以指明未来物联网系统架构的 发展方向。我们采用研究分类的分类法,并通过将已 发表的研究工作划分为不同阶段,系统地分析研究的 历史发展,识别未来研究的潜在方向。
研究结果
搜索与筛选结果
如图所示(见图 4),在第一轮之前应用检索词共获得 8984篇论文。根据第二轮筛选,保留了1660篇文章。
在第三轮之前,分别有168篇和146篇关于软件架构的 评论被保留。在此系统性文献综述中,最终选定了 140篇文章。
研究分类
本节描述了选定论文的人口统计学细节,例如按类别 划分的研究分类、出版地点和出版年份。我们还根据 这些信息对其主要出版物进行了分类和排列。在呈现 从本系统性研究中所包含研究的综合与综述得出的相 关数据的发现之前,我们报告了所包含研究的人口统 计学细节:出版地点和形式、引用状态以及时间顺序 视图。所有包含的研究均列于附录。一篇论文的引用 状态将部分
表6 从原始文献中提取的数据项(根据映射进行提取,并从Excel列与数据项列进行映射)
| ID数据项 | 简要 | 相关研究问题 |
|---|---|---|
| 1标题 | 论文的标题 | 人口统计学 |
| 2 Year | 论文发表年份 | 人口统计学 |
| 3作者类型 | 研究人员或从业者或两者兼具 | 人口统计学 |
| 4摘要 | 论文的主要内容 | 人口统计学 |
| 5出版物类型 | 研讨会、会议、期刊 | 人口统计学 |
| 6验证类型 | 案例研究、实验研究、调查及其他 | 人口统计学 |
| 7物联网挑战 | 研究了物联网研究中的单体式挑战 | R Q 2.1 |
| 8架构解决方案 | 物联网挑战与软件架构解决方案的映射 | RQ2.2 |
| 9设计模式 | 物联网软件设计模式 | R Q 2.3 |
RQ1.1:多年来软件架构和物联网软件出版物的频率 如何?
在出版年份期间发表的文章汇总了所有研究(见 表10)。最重要的发布集中在2017年和2019年。大多 数论文来源于会议(见图7)。在2005–2020年的综述 时间段内,每年选取了若干已发表的研究。这一趋势 自2005年以来持续上升,我们注意到在过去5年中,有 111项研究(占88%)发表于软件架构与物联网领域, 表明支持软件架构流程的软件架构正受到越来越多的 关注和重视(见图5)。
软件架构分类
表7 物联网挑战
| 挑战 | 简要 | Ref. |
|---|---|---|
| 集成 | 应用、数据和各种技术集成。集成‐ 由于多维度性,这是最具挑战性的挑战之一 性,它给企业带来的冲击。数据的集成 物联网是物联网采用的最大问题 商业世界中正在经历持续传播的 技术的采用 | A1、A26、A30、A31、A33、A2、A3、A36、A38、A42、A44 A5, A61, A12, A83 |
| 数据处理 | 处理非结构化数据的问题由于以下原因正在日益增加 不断增长的连接设备。然而,对于组织而言, 主要挑战是确定有价值的数据,即 可操作数据 | A27, A53, A8 |
| 数据共享 | API安全问题,以便将访问权限传递给他人。随着物联网 设备的发展,共享连接设备数据的能力 引起了越来越多的关注 | A28, A41, A78 |
| 数据互操作 | 数据互操作性是物联网面临的关键挑战之一。 数据格式和数据分发也是问题。快速集成 机器生成的数据与数据的处理和改进 来自Salesforce和Market等业务应用, 例如,以及其他数据存储库是困难的 | A32, A35, A37, A9, A2, A40, A56, A101 |
| 数据管理 | 大数据:数据管理是一个广泛的术语,指的是数据的管理 架构、流程和实践是特定情况下所需的 数据生命周期管理的框架 | A42、A62、A63、A64、A68、A72、A93、A98、A100、A104 |
| 互操作性 | 互操作性有助于行业创建和运营 软件和硬件之间的解决方案和服务。大多数 技术标准的各个领域仍然分散。需要 融合,这将有助于创建共享的物联网应用 架构和标准。标准化过程也 缺乏与传统物联网工具的互操作性。这必须被视为一个关键挑战 | A43, A5 |
| 数据存储 | 物联网需要大量存储,但也增加了通信的有效载荷 通信 | A5、A71、A75 |
| 可部署性 | 物联网部署是由于技术变化而引起的关键问题之一 技术。物联网解决方案在全球市场部署 需要单一平台以实现有效控制的 物联网用于多个市场之间的连接性。连接性 物联网设备及其管理是至关重要的 | A29 |
| 数据复杂性 | 数据、设备:其复杂性质是另一个挑战 物联网数据的准备。这种复杂性只会被放大 当考虑到这些数据生成的速率时。A 企业面临的常见挑战是复杂性 在物联网连接性方面与各方打交道 需要 | A6, A58, A83 |
| 可扩展性 | 由于单体架构导致的可扩展性差。数十亿互联网 设备连接到一个大型网络,并产生大数据 需要处理的卷。该系统中 来自物联网设备的数据存储和分析,它需要 可扩展 | A46、A6、A7、A51、A55、A56、A64、A87、A100 |
| 可靠性 | 可靠性是某种估计的特定能力 保持物联网应用的明确执行维度 条件和各种传感器设备。该集合‐ 信息可以反映地球信息的状态 并提供信息管理。可靠性 符合客户端执行明确需求的要求 物联网应用的分配 | A67、A72、A11、A15 |
| 高效 | 生产力商标标识了测试的能力 详细说明以在速度和资源方面提供令人满意的执行效果 利用率。时间和资产行为的有效性是 已识别 | A10、A80、A15 |
| 服务分布 | 物联网需要一种特殊的方法来解决该问题,以提供 足够的性能和可扩展性。它指的是在大量专业化且有限的 服务之间分配工作量 服务 | A51 |
| 相互依赖性 | 相互依赖性指的是不同服务之间如何相互关联 在物联网中可独立管理,但也相互依赖。 为访问服务和应用提供了巨大优势 任何地点、任何时间以及从任何设备 | A54,A59 |
| 数据连接 | 数据连接性已大幅改善,但仍存在一些漏洞 数据的连接性是物联网实施中的一项挑战。 它讲述了设备与网关之间的通信,以及 云 | A58, A64, A71, A75 |
| 标准化 | 物联网也存在标准化问题,因为不同的 对象可能具有不同的需求和各种组合 通信技术 | A68、A136、A107、A108 |
| Risk | 风险管理是一系列程序和流程的集合 用于定义可能的不利后果, 潜在威胁和局限性。特别是,物联网的快速增长 已显著增加了面临风险管理和安全性挑战的 面临风险管理和安全性挑战 | A65, A66, A134 |
| 安全性 | 最重要且可能无法解决的问题是 安全性,更准确地说是网络安全,应用于信息技术领域。 数据链路不仅容易受到攻击,而且任何连接到它的设备也存在风险 实际的硬件是脆弱的。由于大量的 未加密向网络发送数据的物联网设备, 不可靠通信。这是最大的威胁之一 存在的物联网安全问题 | A71, A13 |
| 数据容错 | 容错用于更好地适应构建过程 可信冗余和变化的环境 | A74, A11 |
| 互连性 | 物联网在其他情况下称为互连性,无论是无线的 或在物理层面的设备有线连接以及服务 将比特转化为价值 | A85 |
| 可移植性 | 可移动性是推进另一种状态框架的能力, 引入能力与替代能力(能力的 项目因类似原因被替换为另一个项目 过于具体 | A74, A89 |
| 可维护性 | 许多系统集成商目前在构建方面正面临困难 可维护性。在物联网中应考虑可维护性 设计阶段。它指的是智能系统的能力 持续且松散耦合,无需修改 在系统中引发原因。以评估物联网系统的 可维护性属性,系统必须灵活 在不影响其他组件的情况下更换故障组件 | A100,A36,A46 |
| 功能 | 有用性需要能够横向互操作 互联的物联网传感器设备,意味着互操作性 物联网设备芯片关联不同事物的能力。 在物联网应用的情况下,实际先决条件是 在物联网应用需求的属性中加以表征,以 确定物联网应用的具体后果 | [14] |
表8 物联网挑战与软件架构解决方案的映射
| 物联网挑战类型 | 架构的解决方案 | Ref. |
|---|---|---|
| 互操作性 | 解决方案:客户端架构,互操作性 表示各种系统的可用性 需要交换服务和数据。 不同的通信系统具有不同的特性 专用硬件需要软件架构 互操作。第一步是需求 工程(RE)以实现互操作性 系统的能力。它为 软件架构的高层设计 解决方案:支持Web的物联网架构,它能够促进 提供系统之间的互操作性 利用数据标准和已建立的 通信 | A10, A134, A96 |
| Risk | 解决方案:敏捷雾计算架构设计, 架构模式被构建用于在不同层次视角下进行分类和 从不同层次的角度管理风险。 架构设计是最好的设计 在进行风险分析之前,可以做出判断的 风险的有效性 | A65 |
| 可扩展性 | 解决方案:架构模式被称为最佳 实践并分析是否为行业规模 物联网软件和学术研究解决方案 可用于实际开发 | A66, A68, A108, A78, A12, A14, A81, A87 A89, A60, A128, A102, A136 |
| 安全性、可靠性、安全性、功能 | 解决方案:物联网测试架构 局隐限私性和安全法规与标准 分布式和异构系统 实时数据分析 预测性维护 | A134、A78、A12 |
| 大数据 | 解决方案:软件架构旨在构建 处理、摄取和 复杂或庞大的数据分析 单体数据库系统。大数据 软件架构的挑战可能涉及 安全性、量表、完整性、并发 性能、可靠性和平行性, 包括大数据处理在内的需求 重新思考架构解决方案以满足 需求 功能性和非功能性 | A68、A69、A72、A107、A81、A95、A98、A99 A104 |
| 标准化 | 解决方案:使用架构模型来处理 与物联网的标准化问题 | A68, A136, A107, A108 |
| 异构 | 解决方案:分布式灵活架构 异构风格可以结合在 一种设计。这也支持所需 物联网对象和设备特性。这 也可以解决众多技术问题 复杂性、可扩展性等问题 互操作性等等 局限性:需要开发设计指南 异构性容忍 | A69、A78、A12、A115、A119、A19 |
| 物联网系统的操作和制造问题 开发者 | 解决方案:软件架构设计 | A71 |
| 需求 | 解决方案:需求指南 | A71 |
| 可支持性 | A71 | |
| 设计挑战 | 解决方案:以内容为中心的架构 | A71, S80 |
| 数据容错 | 解决方案:容错架构 | A74 |
| 数据认证 | 解决方案:基于网络的架构是 软件架构的一个子领域,负责处理 具有概念 结构的网络上的软件系统 | A79 |
| 功能分离或分布, 集成 | 解决方案:设计了八层的网络架构, 该架构被使用并 嵌入到各个层中,依据 具有分离功能的技术, 特性。它使得物联网系统的分析, 可扩展性和简化模块化 并使其更高效且标准化 , 识别、阐明并组织关键的 物联网系统未来的一个组件 | A80, A115, A86 |
| 安全性、隐私、成本、性能 | 解决方案:基于软件定义网络的架构设计 | A13、A14、A15、A17、A113、A81、A115、A85 A124, A139, A19 |
| 数据共享 | 解决方案:软件定义网络(SDN), 软件定义网络将数据转发平面和 控制平面带来了物联网安全问题 一种新的解决方案 局限性:物联网的架构模型是com‐ plex 且数据传输量巨大,其 安全性防护较弱 | A113 |
| 部署,成本,数据处理 | 解决方案:参考架构,它可以被 设计用于实现设备参数的自动 化和控制器调试。 它提供了关于最近如何的指导 已发布的标准可以使即插即用成为可能 | A81,A82,A117 |
| 可行性 | 解决方案:基于SDN和Docker的架构,这 架构用于管理异构性 网络和设备的特性 | A116 |
| 连接性,轻量级服务 | 解决方案:REST架构风格,这 架构风格用于集成一个新的 应用并采用REST原则 定义用于构建的可扩展接口 综合性应用 | A16 |
| 维护和安全性 | 基于SDN的安全分布式解决方案 架构,用于互连多个 域并增强了每个 领域 | A137 |
Table 9 MSA architectural and design patterns for IoT
| Pattern type | Pattern name | Problem type | Description | Ref. |
|---|---|---|---|---|
| Decomposition | Decomposing application | How to decompose an application into services | The application is decomposed to manage new change without affecting other services. The new changes can be caused to make the development slow down because of the coordination across the multiple teams | A51, A54 |
| Decompose by subdomain | Service must be sufficiently smaller that can be devel-oped and tested by a small team. Domain-driven design refers to request problems as a domain. A domain which includes several subdomains | A75 | ||
| Self-contained service | What should a service work with several other services when it processes an asynchronous request | Design service because it can react to an asynchro-nous query without any other service waiting for the response. One approach to self-contain a service is to incorporate the necessary features as a service module rather than as a separate unit | A9 | |
| Deployment | Service deployment platform | How are services packaged and deployed | Using the automated infrastructure of deployment plat-form for deploying an application. It offers a services abstraction set of highly accessible that is also called load-balanced service instances | A55, A59 |
| Communication style | Remote Procedure Invocation | How do services in a microservices architecture com-municate | The client makes requests to a service using a request / reply-based protocol. They must use a protocol for communication between processes | A55, A59 |
| Messaging | How do services in a microservices architecture com-municate | Utilizing asynchronous messaging for communication of inter-service, services can communicate by exchanging message over channels | A106 | |
| Communication pattern | Service must be used to handle the coming requests from a client application | A106, A51 | ||
| External API | API gateway | How will microservices app consumers connect with the individual services | The single entry point for clients is the execution of an API gateway. API gateway deals the requests singly. Requests can be routed or proxied to appropriate services and deals with other requests by multiple ser-vices. Using API gateway security is also implemented to authorized the client | A106, A75, A56, A9 |
| REST design pattern | A7 | |||
| Service discovery | Client-side discovery | How does the application client-the API gateway or another tool find out where an application instance is located | A customer gets the location via requesting service by querying a service list that has all of the location’s service instances | A9 |
| Service registry | How do clients of service know about the available instances of service in the case of and/or routers | The service registry is a database service to dispatch the service instances. Service register is used to register the instance of service. Routers query and service client, the service registry is used to find the available service instances | A50 | |
| Reliability | Circuit breaker | How to prevent a network or service failure from cascad-ing to other services | Client service invokes a remote service via a proxy that operates an electrical circuit breaker in a similar man-ner. For all attempts to invoke the remote device, the number of consecutive faults over a threshold would instantly fail | A55, A59, A9 |
| Security | Access token | How to communicate the identity of the requestor to the services that handle the request | API gateway is used to authenticates the request and send the token in the form of JSON, which securely identify the requestor in each service of the request | A34, A51, A58 |
讨论
互联网是物联网的主要组成部分。物联网定义了嵌入软件、 传感器和REST技术的物理对象(事物)网络,这些对象 通过互联网在设备和系统之间通信并共享信息。物联网通 过使日常对象具备智能化功能,从而实现智能互联。
它们可以中继数据并自动执行任务,而无需手动输入。
物联网系统可能像可穿戴健康监测一样基础,也可能 像在所有区域都配备传感器的智慧城市一样复杂。
软件架构涉及软件系统的基本结构以及设计框架 和应用程序的过程。软件架构
描述了如何组织/组装软件系统的组件、它们之间如何 交互以及控制整个系统的约束条件。软件架构师负责企 业软件设计的决策。
物联网研究的领域之一是软件架构。软件架构有 助于设计复杂的物联网及其他应用程序。现实世界中 的物体逐渐与作为信息系统一部分的信息技术机制进 行交互。这一进展体现在数字化的一些关键术语中, 例如智能家居、智慧城市和智能车辆,这些均归属于 物联网范畴。对于希望利用软件架构连接这些智能对 象的组织而言,物联网带来了软件架构挑战。
本研究深入探讨了针对物联网软件挑战的软件架构 解决方案,旨在对当前各类研究进行分类。本部分展示 了本研究的一些最重要反思,包括该系统性研究的结果, 这些结果显示出显著的差异性。本研究适用于多种架构 的软件解决方案(见表8),用于映射物联网软件的挑 战。我们正在审查报告中多个研究问题的实证结果。
物联网软件的当前与未来架构研究
根据我们的选择标准,我们将研究范围定义为2005年至 2020年。关于软件架构和物联网软件开发的研究取得了大量进展。我们重点阐述了物联网架构的前瞻性 工作。研究与开发促进了对软件架构风格、模式以及需要 系统性识别的最新趋势的探索。通过架构语言,可以支持 物联网软件的架构风格与模式的实现。
物联网中的单体架构
由于大规模物联网系统和连接设备,企业在构建、部 署、实施和扩展方面面临困难。使用单体架构时,系统难以扩展;如果需要对代码进行修改,则可能影响 整个系统,并需重新部署整个系统(见图 11)。
物联网中的面向服务架构
SOA 由于物联网架构的异构性和分布性,成为物联网 中的自然选择。尽管通常应用于业务领域,但完整的 RESTful HTTP 实现通常对受限的设备和网络造成较 大负担。Web 服务的设备配置文件 [34] 支持网络对 象的即插即用以及受限应用协议 [35]。虽然 SOA 对此 类需求而言是一种可接受的解决方案,但 SOA 在服务 运作方面仍存在大量模糊之处。这正是生态系统和结 构的发展开始解释特定技术使用的地方。框架限制了 技术选择,从而促进了物联网或信息物理系统应用的 开发。在技术层面上,人们可以推测框架之间的互操 作性将增加。然而,服务的行为仍然取决于开发者, 因此互操作性的提升可以忽略不计,因为其 有许多可用的框架。因此,使用框架将促进各个服务的创 建。
未来方向:物联网系统采用微服务架构而非面向 服务的架构或单体式架构的重要性与必要性
由于使用了共享的硬件和软件,单体架构具有紧密耦 合的特点。分布式应用场景需要高度共享资源以实现 低依赖性(见图 11)。基于微服务的设计模型目前是 分布式应用设计的一种极具前景的方法。
基于物联网的面向服务的架构为用户提供更高效 和高速的信息。基于SOA的物联网系统中的主要问题 原因是异构系统必须相互交互,因为每个设备的功能 不同[S43], ,而系统的主要挑战之一是安全性方案, 需要高安全支持,因此需要轻量级通信、独立部署、 独立开发以及最少的集中化管理,这些都可以由微服 务架构提供。微服务架构是一种通过松耦合软件服务 快速且持续地构建和运行大型复杂系统的架构风格。
基于微服务架构,服务可以被编写
根据需求,每个传感器都可以与不同的数据库通信 (见图12)。研究人员展示了对作为物联网和云计算 构建模块的先进微服务进行全面分析的结果[12]。该系 统性研究的结果表明,模块化实现在支持物联网应用 中的微服务架构方面所起的作用。
微服务架构设计模式与物联网挑战的映射
- 随着物联网的持续扩展和发展,单体式实施变得越 来越庞大且复杂性显著增加,导致可扩展性、可维护 性和可扩展性(扩展能力)较弱。由于微服务架构具 有轻量级、灵活性和松散耦合的特点,因此被引入到 物联网应用领域以应对这些挑战。然而,现有的微服 务物联网框架主要集中在特定领域,这极大地限制了 其应用 [A6]
-
如今,数据与机器理解在物联网中变得越来越重要, 已成为关注的焦点,而非那些由于发明及其磨损而频 繁产生数据变化的人工制品。为了实现
机器需要理解和交换、共享信息与知识;这些对象 需要一种轻量级的新型架构,以提供潜在的物联网 服务[A50]。 - 应用程序必须从物联网中较小的集合、独立服务进 行编译。增值服务的开发将需要自发地组合来自不同 提供商的服务,以充分利用物联网异构性 [A48]。
- 物联网设备和物联网服务的云化、虚拟化以及软件 被广泛用于设计、开发和部署新的物联网端到端应用。 关于新物联网服务和平台的可扩展性、扩展能力(可 扩展性)和互操作性挑战如今已成为首要问题[A49]。
- 开发应用和服务在市场中带来了可扩展性、交付、 效率、可用性、互操作性和集成等方面的挑战。近期 研究表明,微服务已在包括物联网[A54]在内的多个领 域得到应用。
- 物联网的一个挑战涉及存储和测量设备连接所产生 的海量数据所需的资源。云计算解决了物联网的问题, 它提供了可按需快速访问的服务。作为一种最近设计 的范式,尽管其原则已经确立,但基于微服务的现有 研究解决方案仍难以见到 [A55]。
-
由于需要支持大量用户和高数据处理能力,物联网 需要一种特殊的方法来解决提供足够
可扩展性和效率的问题,这指向在大量专业化且较 小的服务之间分配工作[A44]。 - 当前的智能家居系统由工程师预先构建,可能无法 满足用户的个性化需求。提出了一种为普通终端用户 设计轻量级物联网业务流程的框架[A43]。
- 收集这些数据的价值在于其能够提供有用的信息, 使决策过程更智能、更快速。这使得企业能够迅速响 应流程中的变化,最大限度地减少停机时间,提高生 产能力和整体运营性能。然而,问题在于所有这些工 业物联网(IIoT)应用程序都可能受到其所引入的 RESTful API组成和微服务架构的显著影响。其次, 工业物联网(IIoT)的实施并未反映出基于服务环境 的动态性和弱点[A45]。
有效性威胁
这项研究存在主要的有效性威胁:样本选择中的偏见 以及数据提取中的偏见。由于样本选择和数据提取具 有很强的主观性,研究人员的偏见可能会影响本研究 的性能。为了尽可能消除样本选择中的潜在偏见,分 析协议通过以下方式制定并验证。本研究的发现可能 会受到未检索到的关键研究的影响。
为了降低此风险,我们研究了最受欢迎的软件工程在线资 源库,并收集了140篇文章。
数据和信息提取中的偏见可能导致信息数据收集 出现错误,并进一步影响数据综合的效果。三个协议 缓解了这种偏见:
1. 一项初步研究,用于提取数据并理解主题。
2. 已上传我们已提取的数据详细列表。
3. 头脑风暴会议是分类数据最重要的方法之一。
内部有效性
此有效性的重点是研究中的数据提取 [36]。由于本综合分析中的数据分析仅使用描述性统计, 因此对内部有效性的挑战极小。
外部有效性
选定的论文在本分析的整体目的方面 具有可推广性[36]。本研究综述考虑了关于软件架构解 决方案和物联网挑战的发现。虽然所呈现的选定论文 摘要和获得的发现仅在研究背景下具有重要意义。
结论
本系统性研究基于物联网软件的架构解决方案,涵盖 了研究与实践两个方面。近十年来,针对物联网软件 架构解决方案的研究取得了大量进展。我们从七个 数字数据库中筛选出2005年至2020年1月期间发表的研 究论文,从选定的140篇文章中收集数据。本系统性研 究提供了关于物联网软件架构解决方案及微服务架构 (MSA)采用现状的全面的研究概述和最新进展。本 研究的核心要点如下:
•随着时间的推移,选定的文章数量不断增加,并且 物联网软件的架构解决方案正受到越来越多的关注 (见图 6)。在过去的5年中,用于物联网软件研究的 软件架构日益受到重视(140篇文章中有123篇)。
•我们基于用于物联网的微服务架构确定了十三种架 构和设计模式(见表 9)。这些模式的识别有助于重 用关于物联网软件的微服务架构的知识、重要性和理 解。我们还根据物联网中的问题对这些模式进行了分 类。
•我们将物联网软件的软件架构分为九个主要类别及 其子类别(见图9)。
•关于最新进展,我们研究了物联网的二十三项挑战, 并进行了详细讨论(见表7)。这些挑战大多属于新兴 问题,亟需解决。我们将物联网的这些挑战与软件架 构解决方案进行了映射(见图10、表8)。
总结发现并提出在物联网软件中采用微服务架构 的建议,我们详细讨论了微服务架构对于物联网的重 要性及其特征。
提出该系统性分析的目的是整合相互的知识,以 提升研究性能、影响和局限性方面的认识: 研究人员理论上参与了以架构为中心的物联网软 件解决方案研究与开发的知识库的生成、学习和探索。
在研究分类法和架构解决方案的数据库方面,系统化 和结构化的知识可以帮助研究人员深入了解科学进步, 从而形成新思想并提出需要验证的新假设。全面的分 析将帮助研究人员识别:(1)研究进展的速度和证据; (2)近期研究中的挑战;(3)创建各种物联网解决 方案所涉及的技术困难。
实践者的兴趣可能在于理解和开发针对现有工程 研究及其影响的切实可行的解决方案。问题和架构解 决方案的可视化将展示未来工业解决方案的领域和方 法,其中可应用应用研究和技术。当前和新兴研究趋 势凸显了对能够利用模式和语言进行工业级物联网构 建的技术的需求。
遵守道德标准
Conflict of interest 作者们声明他们没有利益冲突。
38

被折叠的 条评论
为什么被折叠?



