新浪网站源代码,做暖漫画网站,网站如何跟域名绑定,万网域名注册接口物联网用例的独特要求
物联网用例往往在功耗、带宽、分析等方面具有非常独特的要求。此外#xff0c;物联网实施的固有复杂性#xff08;一端的现场设备在计算上受到挑战#xff0c;另一端的云容量几乎无限#xff09;迫使架构师做出艰难的架构决策和实施选择。可用实现技…物联网用例的独特要求
物联网用例往往在功耗、带宽、分析等方面具有非常独特的要求。此外物联网实施的固有复杂性一端的现场设备在计算上受到挑战另一端的云容量几乎无限迫使架构师做出艰难的架构决策和实施选择。可用实现技术的多样性和缺乏完善的标准是额外的挑战使体系结构决策变得困难。
本书试图通过识别可以支持这些用例的架构之间的共性来缓解与构建物联网用例相关的一些挑战。重要的是不要被用例的多样性所蒙蔽并认识到多样性存在于表层和底层。
本书旨在通过展示如何将不同物联网用例的实现追溯到少数架构模式弥合当前理解中的这一差距。 在介绍各种物联网模式之前值得一提的是物联网架构不同于非物联网架构的独特期望 感知事件和驱动命令具有广泛的延迟预期——从实时到激发和忘记 数据分析结果需要在各种消费设备上报告/可视化/消费——手机、台式机、平板电脑等。同样数据消费者有不同的背景、数据需求和应用程序角色人物角色。
人们经常被迫与传统以及尖端设备和/或外部系统集成——很少有琐碎的用例具有独立/独立的架构。从遗留系统和非遗留系统中提取数据的方式有很大的不同——遗留系统可能会在内部整理数据然后将其推送到外部端口文件传输而较新的系统可能会以连续的流时间序列数据推送数据。这种可变性是选择特定物联网架构模式时的关键考虑因素之一。 不同的部署需求—边缘、内部部署、混合、云等等。 遵守严格的监管规定尤其是在医疗和航空领域。 有人期望立即获得回报投资回报率ROI、业务成果和新的服务业务模式。 持续创新产生新的服务或产品尤其是云供应商迫使物联网架构与这些新产品或服务保持持续同步。 缺乏能够制定端到端物联网解决方案的熟练架构师——尽管可能有特定技能的人设备架构师、连接架构师和云架构师然而很少有端到端的物联网架构师。 设备、设备连接、物联网协议或消息传输层没有通用标准导致设备管理复杂。 通常物联网堆栈不会孤立运行任何非琐碎的部署物联网解决方案都需要与其他外部系统ERP、AMDB、MES等集成。即使在这里也没有关于如何无缝集成这些系统的标准。外部系统通常比物联网部署早几十年并且在没有考虑集成需求的情况下进行了大量定制。 从一个角度来看物联网实施是一项流程自动化举措。一般来说该过程是存在的但是手动执行的物联网有望部分或完全自动化该过程。
这些现有的工作流程没有记录在案并且是流程从业者部落知识的一部分这给物联网架构师带来了挑战因为他们对流程和工作流程不清楚。因此他们面临着一个两难的问题即哪些子流程应该自动化以最大限度地提高ROI——他们必须决定是否满足于微小的改进局部优化并放弃通过考虑全局优化可以积累的好处。
设备生命周期管理在有氧医疗设备等领域是一个挑战因为它们无法承受停机时间但仍需要及时的固件更新尤其是与安全修复相关的补丁不能推迟到某个时间点之后。 需要定期校准现场传感器是一个挑战。漂移速率因传感器而异也因环境而异。有一种趋势是通过在边缘或云中应用AI/ML模型来补偿这种漂移但这些步骤远非理想因为它们缺乏准确性并且可能没有充分考虑局部或环境条件。 依赖于位置信息的用例往往具有有限的可接受性因为所有的位置传感器室内或室外具有有限的精度。 大量边缘处理的历史数据几十年来积累的迁移到云是另一个关键的架构挑战在许多机器到机器M2M到物联网的转型计划中都看到了这一挑战。 所需的非功能性需求NFR可扩展性、可用性、安全性、数据驻留/隐私等值因用例而异并增加了另一层复杂性。 物联网数据的消费者有不同的背景例如家庭自动化用户的信息需求与想要监测工厂正常运行时间的工业用户有很大不同而工业用户的信息需要又与使用物联网进行自动化临床试验的辅助医疗人员的需求不同因此他们有不同的操作和利用物联网系统的方式。尽管这似乎对设备UI设计有更大的影响但它也会以微妙的方式影响解决方案架构。 在下一节中我们将列出有助于您解决实施物联网解决方案的独特需求的架构原则或注意事项。
建议的体系结构原则和注意事项
确保体系结构一旦实现即具有可扩展性、可修改性、鲁棒性和容错性的某些原则与物联网体系结构尤其相关。让我们来看看其中的一些 基于开放通信协议构建以支持不同的设备通信需求因为物联网是真实硬件和虚拟软件领域的融合每一个领域都以自己独立的速度发展。稳健的物联网架构应该足够灵活以支持这两个领域当前和未来可能的增强功能——例如一方面设备/硬件方面的连接/电源功能不断进步而另一方面中央服务器方面在分析和AI/ML能力方面取得了进步。 因此现实世界和虚拟世界之间存在固有的阻抗失配涉及这些增强的速率和性质。物联网架构师不仅应该意识到这种不匹配还应该纳入所需的考虑因素以在更长的时间内支持用例需求。这些要求部分是通过遵循分层架构来处理的通过分层架构特定层中的组件可以插入或插入对整体架构的影响最小。 专为“端到端”安全设计安全性是任何软件系统的重要考虑因素尤其是在数据或命令通过公共通信信道进行通信的情况下。然而就物联网而言安全需要更深入的考虑主要有两个原因与虚拟/软件世界中的行动不同在现实/物理世界中发起的行动是不能取消的在有人检测到异常并采取纠正行动之前一台灌溉泵被恶意指示开始在农田中抽水它会泵出相当多的水。这与软件世界中的场景形成了鲜明对比在软件世界中一条简单的更新指令就足以撤消/滚动回溯数据库的更改。在医疗保健等领域物联网系统通常控制人类生活例如由物联网系统控制的氧气呼吸机情况可能更具灾难性。 与纯软件系统相比攻击向量要广泛得多这是因为需要保护完整的数据管道终端设备网关通信通道中央服务器应用程序并且数据管道中的每个实体都有不同的适用安全要求——终端设备其固有的受限计算/存储能力无法支持中央服务器所能支持的严格安全性因此需要独立分析每个组件的安全漏洞和相关安全防护措施。 同样数据在传输过程中以及在任何时候都应受到保护。 通过“API-first”方法实现的企业集成任何生产级物联网系统通常都会与其他外部系统集成以提供全部价值。物联网系统整理的真实世界数据被输入数据推送到外部系统以实现更丰富的用例。类似地来自外部系统的数据数据拉取用于丰富整理后的数据。这种类型的集成是不可能的除非物联网系统已经使用API-first作为核心架构租户之一进行架构设计企业应用程序可以使用物联网数据。这些API还支持跨物联网和非物联网即外部系统的工作流。 满足不同的数据需求物联网系统由不同的用户使用每个用户都有不同的背景和信息需求。因此重要的是要捕捉所有当前和未来利益相关者的原始数据需求并以一种易于被不同利益相关者人物角色同化的方式呈现数据。 基于角色的访问控制RBAC是一种向利益相关者显示所需信息同时掩盖非相关信息的机制。此外一些利益相关者将有实时数据需求希望紧急警报实时通知的运营商而其他利益相关者则希望从合并数据中获得见解批量处理。将数据摄取与数据处理解耦是使我们能够满足这一需求的一个原则。以下列出了一些其他数据整理/操作要求来自制造执行系统MES和实验室信息管理系统LIMS等源的各种结构化、半结构化和非结构化操作数据应整合在边缘、云或两者的通用数据存储数据湖中。 出于可扩展性、效率和成本优化考虑分离流式、批处理和正确的时间数据管道。数据生产者与消费者的解耦确保了强健的体系结构以及技术和实现选择的灵活性。 提供部署灵活性的技术中立架构物联网系统可以部署在不同的配置中如内部部署、公有云、私有云和/或混合多云配置这取决于客户对安全的敏感性以及治理和监管需求。考虑到这一点体系结构应该足够通用可以满足不同的部署需求并可以由多个技术堆栈支持。这通常是通过创建物联网参考体系结构没有特定的技术选择然后过渡到技术体系结构其中通用体系结构组件被特定的技术组件取代来实现的。 高可用性设计尽管不同的物联网用例对高可用性的需求差异很大但一些用例被归类为任务关键型用例几乎没有停机预期而另一些用例可以适应相当长的停机时间。中央服务器体系结构应该模仿正常运行时间的预期因为通常情况下停机时间越少成本越高。在物联网的背景下必须从整体系统的角度考虑高可用性。例如在可以接受更长的中央服务器停机时间的情况下终端设备需要具有更高的数据缓冲能力即更大的存储空间以最大限度地减少数据丢失。 支持“无限可扩展性”物联网部署从少量终端设备开始但往往在短时间内扩展到大量。因此通常在物联网解决方案中水平可扩展性优先于垂直可扩展性 设备通信注意事项数据通过网关和中央服务器之间的双向通信信道进行通信。该信道可以由多种通信技术支持其中一些常见的技术是蜂窝、Wi-Fi、LoRa和SigFox。范围与中央服务器的物理距离、有效载荷大小、电池寿命和环境噪声等因素在最终确定特定物联网实现的理想通信技术方面发挥着作用。设备侧的一些其他考虑因素包括在与中央服务器的连接丢失的情况下存储/缓冲数据的能力、用于节省电池电量的睡眠/唤醒逻辑以及数据聚合/过滤需求。 下图总结了本节中讨论的关键体系结构原则/注意事项 图1.4-开发物联网解决方案的体系结构考虑因素
总结
本介绍性章节帮助您了解在开发或部署物联网解决方案时需要考虑的架构考虑因素。此外本章提供了上下文知识将帮助您理解本书中列出的模式。讨论了物联网解决方案与其他传统软件系统或IT解决方案不同的特征以及关于物联网参考体系结构不同层的信息。在接下来的两章中我们将深入探讨物联网架构模式。
