许多团队目前都处于同样的境地。大楼里有智能锁、空间占用传感器、摄像头、数字标牌、HVAC控制系统、自助终端、平板电脑、支付终端、宾客 WiFi、员工设备，以及不同部门在不同时期购买的一系列系统。一切都连接在一起，但并不一定连接得很好。
这就是物联架构（internet of things architecture）不再是一个抽象的图表，而是成为一个运行模型的地方。如果架构薄弱，设备最终会陷入孤岛，数据到达太迟，身份识别不一致，而安全只能靠运气。如果架构健全，那么同一个资产就更容易保障安全、更容易支持，并且对业务更加有用。
什么是 IoT 架构，以及为什么它现在很重要
酒店总监看到了一个问题。宾客想要快速的 WiFi，房间应该节能，员工应该在系统之间无缝切换，而连接的设备应该能正常工作。而 IT 总监则看到了底层的问题。所有这些结果都取决于组织是否对设备、连接性、处理、访问和应用拥有一个连贯的架构。
IoT 架构是定义物理设备如何收集数据、这些数据如何传输、在何处处理、系统如何根据数据采取行动，以及谁被允许与每个部分进行交互的蓝图。在实践中，它回答了决定运营成败的问题。温控器加入哪个网络。摄像头画面在何处分析。传统的传感器如何进行身份验证。承包商离开时会发生什么。宾客设备如何与临床系统或后台工具保持隔离。
在英国，这种紧迫性是真实存在的。连接资产的增长不再是理论上的。根据 GeeksforGeeks 引用的 IoT 架构和英国采用趋势概述，2023年英国拥有超过12亿个 IoT 连接，比2022年增长了35%，并且 77% 的英国企业报告其 IoT 系统面临网络安全威胁。
这种结合改变了对话。没有结构的规模会产生运营阻力。有结构的规模则会创造优势。
架构是将设备转化为系统的关键
大多数失败的 IoT 项目并不是因为传感器不好。它们的失败是因为周围的设计薄弱。
一个可行的架构能为您提供：
- 明确的角色分离：设备负责收集，网络负责传输，网关负责处理，应用负责展示，而身份则控制访问。
- 可预测的安全边界： 访客流量、员工访问和机器流量互不干扰。
- 运营一致性： 入网、吊销、监控和故障排除都遵循可重复的模式。
- 业务实用性： 数据能送达可对其采取行动的系统，无论是 BMS、CRM 还是服务台。
实用规则： 如果连接的设备只能通过“破例”来添加，那么该架构尚不成熟。
如果您想了解互联资产的扩展速度有多快，这篇关于 有多少设备连接到互联网 的概述是一个非常有用的业务级参考点。
IoT 架构的基础层
为了轻松理解物联网架构，可以将其想象成一栋大楼。每个楼层都有独特的作用。如果底层不稳定，顶层公寓建得再好也无济于事。
感知层
这是地面层。它包含进行感知或操作的物理实体。
这包括占用传感器、温控器、摄像头、智能锁、医疗监护仪、环境探针、自助终端、支付终端和执行器。这些设备产生了整套技术栈所依赖的原始信号。
这里的主要设计关注点不仅是设备的选择， 更是可信度。带有脆弱固件、较差更新路径或受限身份支持的廉价传感器所产生的问题，在技术栈的后期阶段是无法完全修复的。在酒店和零售业，团队通常会继承现代与传统设备混杂的资产。架构必须接纳这一现实，而不是假设一切从零开始。
网络层
这是大楼的布线和管道。它在设备、网关、平台和应用程序之间传输数据。
网络层涵盖了传输路径、无线和有线连接、网关部署、流量隔离，以及确定哪些系统可以与哪些系统进行通信的规则。在医院中，这可能意味着将患者监护流量与访客互联网访问隔离开来。在零售业中，这可能意味着将 POS 流量与占用分析及公共 WiFi 隔离开来。
一个强大的网络层可以做好以下三件事：
- 可靠连接： 设备保持在线，无需持续的手动干预。
- 正确分段： 一个区域的安全失守不会波及到另一个区域。
- 支持正确的协议组合：受限设备和企业应用对传输的需求并不相同。
边缘计算层
这是本地设备室。它靠近设备，并在流量向上传输之前处理对时间敏感或高带宽的任务。
边缘网关负责过滤噪声、规范数据、应用本地策略，有时还会做出即时决策。这在等待远程云服务往返响应属于糟糕设计的环境中至关重要。例如，门禁控制器不应依赖缓慢的外部路径来决定凭据是否有效。楼宇警报不应因为网关转发了所有原始事件而不是在本地进行处理而被延迟。
当延迟、带宽使用或隐私成为运营风险时，将决策推向更靠近事件发生的位置。
云和数据处理层
这是中央控制室。它汇总来自多个场所的信息、进行存储和关联，并为分析或业务流程提供支持。
云层是企业统一管理整个资产可见性的地方，但也往往是产生意外复杂性的地方。如果每个设备都在没有任何过滤的情况下将所有内容向上传送，团队不仅要为不必要的传输和存储付费，还会使仪表板更加杂乱、事件响应更加缓慢。
此层最适合用于受益于集中化的工作负载：
- 跨场所报告：比较不同场馆或楼宇之间的性能
- 历史分析：发现占用率、资产使用情况或服务质量的趋势
- 业务集成：将 IoT 事件链接到工单、CRM、自动化或数据平台
应用层
这是用户看到的部分。仪表板、服务门户、警报、楼宇管理界面、员工应用程序和报告工具都存在于此。
如果应用层很差，利益相关者会认为整个项目都很差。如果设施团队无法对警报做出反应，前台团队无法查看客房准备情况，或者运营经理无法区分真实事件和背景噪声，那么干净的后端也无济于事。
最优秀的应用层只展示每个受众需要的内容。网络团队需要遥测数据和策略可见性。场馆经理需要运营摘要。临床或酒店前台工作人员需要工作流程，而不是数据包级别的细节。
关于平台如何将这些层结合在一起的相关视角，这篇关于 internet of things platforms 的指南非常值得阅读。
了解 IoT 通信协议
协议的选择是物联网架构变得非常务实的地方。团队选择 MQTT、CoAP 或 AMQP，并不是因为哪一个听起来更现代，而是因为它们各自解决不同的问题。
错误的协议并不总是会立即失效。更多时候，它会带来摩擦。设备电池消耗过快。网关承载了不必要的冗余通信。系统集成变得脆弱。安全控制最终只是拼凑而成，而不是内置的。
从运行条件开始
酒店客房内电池供电的占用传感器，与向 CRM 或营销自动化系统传递事件的后端工作流有着截然不同的需求。前者需要轻量、高效的交换，而后者则需要持久、可靠的服务器对服务器消息传递。
来自 Intetics 的引用协议概述清晰地指出了这一区别。MQTT 专为低功耗数据收集而设计，CoAP 适合受限设备，而 AMQP 则适用于服务器对服务器的交换。该来源还指出，MQTT 的发布-订阅模式可以处理数以千计的并发连接，这对于运营数百个接入点以及许多连接终端的场所至关重要。
常见物联网通信协议比较
| 协议 | 传输 | 核心特性 | 最佳适用场景 |
|---|---|---|---|
| MQTT | TCP/IP | 轻量级发布 - 订阅消息传递 | 低功耗传感器、遥测、全场所设备事件 |
| CoAP | UDP/IP | 受限设备的最小开销 | 内存受限或对电池敏感的终端 |
| AMQP | 通常为 TCP/IP | 可靠的异步队列和代理交付 | 服务器对服务器工作流、企业集成 |
| DDS | 通常基于 IP 网络 | 实时分布式通信 | 需要快速点对点数据交换的环境 |
在实际部署中行之有效的方案
对于遥测密集型资产，MQTT 通常是最安全的首选。当大量设备频繁报告小数据包，并且您需要可扩展的分发给多个订阅者时，它非常适用。在零售中心或酒店中，这可以包括向多个下游系统提供数据的空间传感器、占用计数器或环境监测。
CoAP 适合电力或内存预算非常有限的设备。如果您的设备资产中包含需要节省电池寿命并交换适量数据的简单传感器，那么 CoAP 是一个逻辑上的选择。如果您的团队在设备生命周期管理和可观察性方面不够严谨，那么它的容错性就会降低，因为受限设备可能更难排除故障。
AMQP 属于更高级别的堆栈。它通常不是极小型边缘设备的首选，但它对于业务系统之间可靠的异步交接非常有意义。如果一个事件需要从物联网平台转移到预订、CRM、服务管理或分析工作流中，那么 AMQP 通常比试图将面向设备的协议延伸到企业消息传递角色中更容易管理。
安全性和可扩展性同样是协议决定
协议选择不仅会影响消息格式。它还会塑造安全模型和运营开销。
一个合理的合理设计通常包括：
- 加密传输：在协议和设备支持的情况下使用 TLS/SSL。
- 按功能细分：隔离设备类别和消息路径。
- 按行为监控：观察异常连接模式，而不仅仅是设备在线状态。
- 代理或网关规范：避免允许所有设备进行广泛的通信。
一个轻量但缺乏规范的协议在支持时间上的成本会变得非常昂贵。
一个常见的错误是过于激进地追求标准化。一些团队试图在每个层级强行使用一种协议，因为这感觉更简单。在实践中，这通常会将复杂性转移到其他地方。当设备层使用轻量级协议，而上游集成使用更强大的消息传递模型时，混合环境通常表现更好。
边缘计算层的关键作用
云优先思维仍然出现在很多物联网讨论中，但仅限云端的设计在繁忙的物理环境中并不能很好地支撑。从您的设备支持实时运营的那一刻起，边缘计算层就成为了核心架构的一部分，而不是一个可选的增强功能。
原因很简单。本地决策通常比远程决策更好。楼宇网关可以在数据离开站点之前对其进行过滤、聚合和处理。这减少了延迟，限制了不必要的网络回传流量，并使敏感处理更接近事件发生的位置。
为什么边缘在运营上很重要
英国向边缘赋能设计的转变已清晰可见。根据 Itransition 引用的架构概述，边缘赋能架构在 2023 年占英国部署的 52%，高于 2020 年的 28%。同一来源指出，边缘层可减少高达 60% 的带宽使用，并指出 42,000 间英国酒店客房已集成了物联网网关。
这些数据与网络团队在实践中看到的情况相符。当站点在本地处理明显的噪点时，上游系统会变得更干净、运行成本更低。同时它们也会变得更加实用。
优秀的边缘设计可解决三个常见问题
对延迟敏感的操作
如果某项规则需要立即响应，边缘处理通常是更好的选择。门禁、安全警报、本地环境控制以及占用触发的操作都受益于短决策路径。带宽浪费
并非每个原始事件都需要传输到云端。如果您将每条消息都视为具有同等价值，那么摄像头、密集的传感器群和频繁的状态更新可能会让链路不堪重负。数据处理限制
出于隐私、弹性和运营等原因，某些组织更倾向于将特定处理保留在靠近源头的地方。边缘网关使这成为可能，同时又不会完全放弃全局可见性。
不该做的事情
薄弱的边缘策略通常表现为两个极端之一。
要么将网关视为哑透传，几乎不产生价值；要么将其变成一个未受管制的微型数据中心，充斥着无人愿意支持的自定义逻辑。两者都会带来令人头疼的问题。
更好的模式是在边缘进行选择性智能。积极进行过滤。缓存必须在上行链路中断期间保持可用的内容。将本地策略应用于需要它的流。将摘要数据和有意义的事件推送到中央平台。
如果站点暂时失去上行连接，建筑的功能应该优雅降级，而不是变得无法使用。
这一原则在酒店、医疗保健和零售行业最为重要。这些环境不会因为中央服务缓慢而停摆。人们仍在办理入住、进入房间、在病房中走动或在收银台付款。架构必须考虑到这一点。
利用现代身份模式确保架构安全
传统的边界安全在物联网资产中很快就会失效。设备在移动。承包商来来往往。业务部门之间出现了新的服务。访客访问、员工访问和机器访问都共存于同一个物理基础设施上。一旦发生这种情况，“网络内部”就不再是一个有意义的信任边界。
这就是为什么现代物联网安全已转向身份认证。不仅是用户身份，还包括设备身份、服务身份以及与之相绑定的策略。
旧模型不适用于多用户环境
在酒店中，单个场所可能会托管访客手机、会议影音设备、客房传感器、员工平板电脑、智能电视、POS终端和工程设备。在医疗保健行业，这种情况甚至更难处理。临床系统、面向患者的访问、设施设备和传统医疗设备都因为不同的原因需要网络访问。
扁平化的信任模型无法在这种多样性下生存。共享密码极易过期失效。宽泛的 VLAN 访问权限会被滥用。手动取消配置的速度太慢。一旦设备或用户获得了超出其应有权限的访问权，横向移动就会变得非常容易。
身份认证是可扩展的控制点
更强大的模型将每个连接都视为需要验证、分类和限制的对象。
这通常意味着：
- 现代设备使用强身份控制：SSO、证书和目录驱动的访问使入网和撤销更加干净利落。
- 传统设备使用补偿性控制：在基于证书的方法不切实际的情况下，策略需要对它们进行严格的隔离和限制。
- 访问遵循角色和上下文：员工设备、访客手机和温控器绝不应该仅仅因为它们共享同一个 SSID 就置于同一个信任区域中。
- 吊销必须是自动的：如果用户离开或设备状态改变，访问权限应该自动更新，而无需排队等待工单处理。
引自 Arm Developer 的设计模式讨论反映了这一转变。它指出，英国的合规要求 - 如 Data Protection Act 2018 和 PSTI 2024 正在重塑物联网安全，而标准中间件模式已被证明是不够的。同一来源指出，结合了针对现代设备的 SSO 和针对传统设备的 iPSK 的混合方法，并具有自动吊销和租户隔离功能，在 Meraki 和 Aruba 等平台上可以将部署时间从几个月缩短到几周。
零信任是切合实际的，而非理论上的
一些团队听到“零信任”就会联想到一个为期数年的转型计划。但在物联网中，它比这更为具体。
这意味着每次有设备或用户连接时，都要提出几个严格的问题：
- 这是谁或这是什么
- 它是如何进行身份验证的
- 它应该访问什么
- 什么应该被拦截
- 访问权限能多快被撤销
这种方法之所以奏效，是因为它符合实际的运行条件。设备是多样化的。资产是共享的。变化是常态。
目的不是不信任任何事物。目的是停止默认信任。
对于 IT 总监来说，这是物联网架构安全的关键转变。停止在柔软的核心周围画一个硬壳。开始在连接点分配身份、最小权限和隔离。
将物联网整合到您的企业网络中
大多数物联网架构问题不会出现在全新的规划图上。它们出现在实时网络必须吸收新设备，同时又不能破坏访客访问、员工工作流程或合规性规则的时候。
在多用户企业环境中尤其如此。酒店、购物中心、医院、住宅楼和综合用途场所都有一个共同点。不同的群体共享相同的物理基础设施，但他们不应该共享相同的信任边界。
从共存开始，而不仅仅是连接性
一个常见的错误是将物联网部署视为对当前 WLAN 的简单附加。设备连接，数据包流动，项目被宣布上线。然后支持工单就来了。访客设备落到了不该去的地方。设施供应商需要访问权限，但无法进行清晰的隔离。遗留终端不支持首选的身份验证方法。员工漫游在不同建筑物之间变得不一致。
更好的问题是：连接的设备、用户和业务系统如何在同一个网络上共存，而不会相互继承风险？
一个实用的整合模型
对于大多数企业资产，基准应该包括以下设计选择：
- 按角色和目的分离流量：访客访问、员工访问和物联网设备流量应遵循不同的策略路径。
- 将身份映射到策略：在可能的情况下，对员工使用基于目录的访问，对托管设备进行显式分配。
- 刻意处理遗留设备：较旧的终端通常需要不同的入网模式，但它们仍然需要强大的隔离。
- 规划站点之间的移动：如果用户和设备漫游，策略应该随之移动。
最清晰的例子之一是长租公寓或学生公寓。居民期望像家一样的简便性。运营商需要企业级的隔离。同样的问题也出现在拥有员工、患者、访客和医疗设备的医院，以及拥有访客、员工、会议组织者和第三方供应商的酒店业中。
隔离在操作上必须简单
架构师往往在图纸上能做好隔离，但在实际操作中却不尽人意。策略是合理的，但入网流程极其繁琐，导致团队开始寻找捷径。共享凭据重新出现。临时例外变成了永久例外。由于平台模式过于死板，本地管理员只能依靠电子表格进行维护。
这就是为什么简单、可重复的设备隔离至关重要。这篇关于 IoT device segmentation on WiFi and isolating non-standard devices 的指南对于解决运营层面的问题是一个极具价值的参考。
在实际应用中行之有效的方法
务实的集成设计通常会融合多种访问模式，而不是将单一方法强加给所有对象。
基于目录的员工访问
员工设备应使用与组织目录和访问策略绑定的强身份认证。这能保持入网和离网流程的一致性，避免因共享凭据带来的混乱。干净隔离的访客与访客访问
访客应能轻松连接，但其流量必须与业务网络和设备网络保持严格隔离。优秀的架构能在保持用户体验流畅的同时，不打破网络边界。针对传统或无屏 IoT 设备的受控入网
某些设备可能不支持现代身份工作流。它们仍然需要独特的策略处理、受限的可达性以及明确的所有权划分。减少摩擦的漫游模式 在多站点资产中，用户不希望频繁地重新进行身份验证。无缝、安全的漫游能提升体验并降低服务台的工作负荷，但前提是跨站点的策略保持一致。
良好的集成设计可以消除歧义，从而减少支持工作量。网络本身就已经知道某个连接被允许执行哪些操作。
业务层面的成果通常比技术变革更具影响力。访客连接速度更快。员工流失的时间更少。设施团队可以添加设备，而无需申请高风险的例外情况。安全团队获得了更清晰的边界。这就是架构的意义所在。它应该让运行中的资产更易于管理，而不仅仅是增加连接性。
结论：您迈向成功的架构蓝图
物联网架构不是采购完成后就被归档的图纸。它是一系列的设计决策，决定了您的联网资产会变得井然有序还是混乱不堪。
最强大的架构都有一些共同的特质。它们采用清晰的分层。它们根据运行条件而非潮流来选择协议。它们将边缘处理视为提高速度、弹性和控制力的实用工具。它们通过身份和隔离来确保访问安全，而不是依赖逐渐失效的边界模型。
对于 IT 总监而言，这至关重要，因为这些成果对企业是显而易见的。更好的访客接入、更安全的设备引导、更清晰的数据流以及更低的运维摩擦，这一切都始于架构。只要蓝图正确，整个网络资产就会变得更容易扩展、更容易保障安全，并且更具价值。
关于 IoT 架构的常见问题解答
一些最棘手的问题往往是在对架构有了大致了解之后才出现的。难点通常在于从哪里开始、衡量什么，以及如何在不过度构建的情况下进行权衡。
IoT 架构常见问题
| 问题 | 回答 |
|---|---|
| 如果我们的网络中已经存在遗留设备和混合厂商，我们应该如何开始？ | 从发现和分类开始。确定哪些设备支持现代身份验证，哪些需要补偿控制，以及它们实际需要访问哪些业务系统。不要一开始就试图一次性标准化所有内容。首先要隔离设备类别、定义策略区域，并为每种类型设置引导路径。 |
| 我们的架构将会扩展的最有用迹象是什么？ | 关注运维指标，而不是虚荣指标。您是否可以在无需手动例外的情况下引导新设备。您是否可以快速撤销访问权限。您是否可以追踪设备接收了哪项策略以及原因。如果上行链路受损，分支机构是否可以优雅地降级运行。可扩展的架构通常表现为更低的运维支持摩擦和更可预测的变更管理。 |
| 我们如何在不使设计过度复杂化的情况下，平衡云、边缘和安全投入？ | 将处理能力放在符合业务实际成效的地方。利用边缘处理对时间敏感的操作和本地过滤。利用中央平台实现跨站点可见性和分析。在整个过程中使用以身份为导向的安全机制。如果一个层级不能提高弹性、控制力或可用性，那它可能只是增加了复杂度，而不是真正的架构。 |
评估决策的一种实用方法是根据以下三个测试来审查每项提议的变更：
- 运维测试： 现场团队是否能够持续一致地支持它
- 安全测试： 它是否减少了隐式信任并收紧了可达性
- 业务测试： 它是否改善了用户体验、数据实用性或交付速度
如果一个设计只能通过其中一项测试，通常说明它还需要进一步完善。
如果您正在计划跨越酒店、零售、医疗保健或多租户物业的互联地产， Purple 可帮助您将网络和身份管理完美融合。Purple 为宾客和员工提供免密码 WiFi 接入，支持多租户隔离，与 Entra ID 和 Okta 等平台无缝集成，并帮助组织通过 iPSK 等实用控制功能管理传统物联网设备。对于那些希望在不依赖共享密码或繁琐的 Captive Portal 的情况下，实现安全接入、简化运维和提升用户体验的团队而言，这是一个非常契合的选择。
