第1章物联网模式简介---独特要求和体系结构原则

物联网用例的独特要求

物联网用例往往在功耗、带宽、分析等方面具有非常独特的要求。此外，物联网实施的固有复杂性（一端的现场设备在计算上受到挑战，另一端的云容量几乎无限）迫使架构师做出艰难的架构决策和实施选择。可用实现技术的多样性和缺乏完善的标准是额外的挑战，使体系结构决策变得困难。

本书试图通过识别可以支持这些用例的架构之间的共性，来缓解与构建物联网用例相关的一些挑战。重要的是不要被用例的多样性所蒙蔽，并认识到多样性存在于表层和底层。

本书旨在通过展示如何将不同物联网用例的实现追溯到少数架构模式，弥合当前理解中的这一差距。在介绍各种物联网模式之前，值得一提的是，物联网架构不同于非物联网架构的独特期望：感知事件和驱动命令具有广泛的延迟预期——从实时到激发和忘记数据分析结果需要在各种消费设备上报告/可视化/消费——手机、台式机、平板电脑等。同样，数据消费者有不同的背景、数据需求和应用程序角色（人物角色）。

人们经常被迫与传统以及尖端设备和/或外部系统集成——很少有琐碎的用例具有独立/独立的架构。从遗留系统和非遗留系统中提取数据的方式有很大的不同——遗留系统可能会在内部整理数据，然后将其推送到外部端口（文件传输），而较新的系统可能会以连续的流（时间序列数据）推送数据。这种可变性是选择特定物联网架构模式时的关键考虑因素之一。不同的部署需求—边缘、内部部署、混合、云等等。遵守严格的监管规定，尤其是在医疗和航空领域。有人期望立即获得回报，投资回报率（ROI）、业务成果和新的服务业务模式。持续创新，产生新的服务或产品（尤其是云供应商），迫使物联网架构与这些新产品或服务保持持续同步。缺乏能够制定端到端物联网解决方案的熟练架构师——尽管可能有特定技能的人（设备架构师、连接架构师和云架构师）；然而，很少有端到端的物联网架构师。设备、设备连接、物联网协议或消息传输层没有通用标准，导致设备管理复杂。通常，物联网堆栈不会孤立运行，任何非琐碎的部署物联网解决方案都需要与其他外部系统（ERP、AMDB、MES等）集成。即使在这里，也没有关于如何无缝集成这些系统的标准。外部系统通常比物联网部署早几十年，并且在没有考虑集成需求的情况下进行了大量定制。从一个角度来看，物联网实施是一项流程自动化举措。一般来说，该过程是存在的，但是手动执行的，物联网有望部分或完全自动化该过程。

这些现有的工作流程没有记录在案，并且是流程从业者部落知识的一部分，这给物联网架构师带来了挑战，因为他们对流程和工作流程不清楚。因此，他们面临着一个两难的问题，即哪些子流程应该自动化以最大限度地提高ROI——他们必须决定是否满足于微小的改进（局部优化），并放弃通过考虑全局优化可以积累的好处。

设备生命周期管理在有氧医疗设备等领域是一个挑战，因为它们无法承受停机时间，但仍需要及时的固件更新（尤其是与安全修复相关的补丁，不能推迟到某个时间点之后）。需要定期校准现场传感器是一个挑战。漂移速率因传感器而异，也因环境而异。有一种趋势是通过在边缘或云中应用AI/ML模型来补偿这种漂移，但这些步骤远非理想，因为它们缺乏准确性，并且可能没有充分考虑局部或环境条件。依赖于位置信息的用例往往具有有限的可接受性，因为所有的位置传感器（室内或室外）具有有限的精度。大量边缘处理的历史数据（几十年来积累的）迁移到云是另一个关键的架构挑战，在许多机器到机器（M2M）到物联网的转型计划中都看到了这一挑战。所需的非功能性需求（NFR）（可扩展性、可用性、安全性、数据驻留/隐私等）值因用例而异，并增加了另一层复杂性。物联网数据的消费者有不同的背景（例如，家庭自动化用户的信息需求与想要监测工厂正常运行时间的工业用户有很大不同，而工业用户的信息需要又与使用物联网进行自动化临床试验的辅助医疗人员的需求不同），因此他们有不同的操作和利用物联网系统的方式。尽管这似乎对设备UI设计有更大的影响，但它也会以微妙的方式影响解决方案架构。在下一节中，我们将列出有助于您解决实施物联网解决方案的独特需求的架构原则或注意事项。

建议的体系结构原则和注意事项

确保体系结构一旦实现，即具有可扩展性、可修改性、鲁棒性和容错性的某些原则与物联网体系结构尤其相关。让我们来看看其中的一些：基于开放通信协议构建，以支持不同的设备通信需求：因为物联网是真实（硬件）和虚拟（软件）领域的融合，每一个领域都以自己独立的速度发展。稳健的物联网架构应该足够灵活，以支持这两个领域当前和未来可能的增强功能——例如，一方面，设备/硬件方面的连接/电源功能不断进步，而另一方面，中央服务器方面在分析和AI/ML能力方面取得了进步。

因此，现实世界和虚拟世界之间存在固有的阻抗失配（涉及这些增强的速率和性质）。物联网架构师不仅应该意识到这种不匹配，还应该纳入所需的考虑因素，以在更长的时间内支持用例需求。这些要求部分是通过遵循分层架构来处理的，通过分层架构，特定层中的组件可以插入或插入，对整体架构的影响最小。

专为“端到端”安全设计：安全性是任何软件系统的重要考虑因素，尤其是在数据或命令通过公共通信信道进行通信的情况下。然而，就物联网而言，安全需要更深入的考虑，主要有两个原因：与虚拟/软件世界中的行动不同，在现实/物理世界中发起的行动是不能取消的：在有人检测到异常并采取纠正行动之前，一台灌溉泵被（恶意）指示开始在农田中抽水，它会泵出相当多的水。这与软件世界中的场景形成了鲜明对比，在软件世界中，一条简单的更新指令就足以撤消/滚动回溯数据库的更改。在医疗保健等领域，物联网系统通常控制人类生活（例如，由物联网系统控制的氧气呼吸机），情况可能更具灾难性。与纯软件系统相比，攻击向量要广泛得多：这是因为需要保护完整的数据管道（终端设备>网关>通信通道>中央服务器>应用程序），并且数据管道中的每个实体都有不同的适用安全要求——终端设备（其固有的受限计算/存储能力）无法支持中央服务器所能支持的严格安全性，因此需要独立分析每个组件的安全漏洞和相关安全防护措施。同样，数据在传输过程中以及在任何时候都应受到保护。

通过“API-first”方法实现的企业集成：任何生产级物联网系统通常都会与其他外部系统集成，以提供全部价值。物联网系统整理的真实世界数据被输入（数据推送）到外部系统，以实现更丰富的用例。类似地，来自外部系统的数据（数据拉取）用于丰富整理后的数据。这种类型的集成是不可能的，除非物联网系统已经使用API-first作为核心架构租户之一进行架构设计，企业应用程序可以使用物联网数据。这些API还支持跨物联网和非物联网（即外部系统）的工作流。满足不同的数据需求：物联网系统由不同的用户使用，每个用户都有不同的背景和信息需求。因此，重要的是要捕捉所有（当前和未来）利益相关者的原始数据需求，并以一种易于被不同利益相关者（人物角色）同化的方式呈现数据。

基于角色的访问控制（RBAC）是一种向利益相关者显示所需信息，同时掩盖非相关信息的机制。此外，一些利益相关者将有实时数据需求（希望紧急警报实时通知的运营商），而其他利益相关者则希望从合并数据中获得见解（批量处理）。将数据摄取与数据处理解耦是使我们能够满足这一需求的一个原则。以下列出了一些其他数据整理/操作要求：来自制造执行系统（MES）和实验室信息管理系统（LIMS）等源的各种（结构化、半结构化和非结构化）操作数据应整合在边缘、云或两者的通用数据存储（数据湖）中。出于可扩展性、效率和成本优化考虑，分离流式、批处理和正确的时间数据管道。数据生产者与消费者的解耦确保了强健的体系结构以及技术和实现选择的灵活性。提供部署灵活性的技术中立架构：物联网系统可以部署在不同的配置中，如内部部署、公有云、私有云和/或混合多云配置，这取决于客户对安全的敏感性以及治理和监管需求。考虑到这一点，体系结构应该足够通用，可以满足不同的部署需求，并可以由多个技术堆栈支持。这通常是通过创建物联网参考体系结构（没有特定的技术选择），然后过渡到技术体系结构（其中通用体系结构组件被特定的技术组件取代）来实现的。高可用性设计：尽管不同的物联网用例对高可用性的需求差异很大，但一些用例被归类为任务关键型用例，几乎没有停机预期，而另一些用例可以适应相当长的停机时间。中央服务器体系结构应该模仿正常运行时间的预期，因为通常情况下，停机时间越少，成本越高。在物联网的背景下，必须从整体系统的角度考虑高可用性。例如，在可以接受更长的中央服务器停机时间的情况下，终端设备需要具有更高的数据缓冲能力（即更大的存储空间），以最大限度地减少数据丢失。支持“无限可扩展性”：物联网部署从少量终端设备开始，但往往在短时间内扩展到大量。因此，通常，在物联网解决方案中，水平可扩展性优先于垂直可扩展性设备通信注意事项：数据通过网关和中央服务器之间的双向通信信道进行通信。该信道可以由多种通信技术支持（其中一些常见的技术是蜂窝、Wi-Fi、LoRa和SigFox）。范围（与中央服务器的物理距离）、有效载荷大小、电池寿命和环境噪声等因素在最终确定特定物联网实现的理想通信技术方面发挥着作用。设备侧的一些其他考虑因素包括在与中央服务器的连接丢失的情况下存储/缓冲数据的能力、用于节省电池电量的睡眠/唤醒逻辑以及数据聚合/过滤需求。下图总结了本节中讨论的关键体系结构原则/注意事项：