做物联网项目的人常遇到一个尴尬：设备接入了，数据上云了，但系统跑三个月就开始频繁掉线、响应变慢、维护成本飙升。问题往往不在单个智能硬件的质量，而是技术方案在架构选型阶段就埋下了隐患。东方科技在服务工业客户的过程中发现，超过60%的物联网项目返工与初期架构决策直接相关。

感知层与网络层：选型不是堆参数

很多方案文档把NB-IoT、LoRa、Cat.1并列对比，但实际选型要回到场景本身。以智能表计为例，数据上报频率低、对时延不敏感，NB-IoT的广覆盖和低功耗优势明显；而AGV调度场景要求毫秒级响应，Wi-Fi 6或5G专网才具备可行性。东方科技的建议是：先明确数据采集频率、设备移动性、现场供电条件三个约束，再倒推通信制式。

边缘侧的计算分配同样关键。把全部原始数据推送到云端做清洗和告警判断，带宽成本和响应时延都不可接受。合理的做法是在网关或边缘控制器上完成阈值判断、数据降采样和协议转换，云端只接收结构化结果。

平台层架构：微服务不是万能药

物联网平台层面临的核心矛盾是：设备连接管理需要高并发长连接，业务逻辑又需要灵活迭代。东方科技在多个落地项目中采用分层策略：

• 连接层独立部署MQTT Broker集群，负责会话保持和QoS管理，不做业务逻辑
• 数据处理层通过规则引擎将消息路由到不同后端服务，支持Kafka或RabbitMQ解耦
• 业务层按领域拆分微服务，但设备量低于10万时，单体架构加水平扩展反而更稳定、运维更简单

值得注意的趋势是，云原生IoT平台正在向边缘-云协同演进。KubeEdge、OpenYurt等框架让部分云端能力下沉到边缘节点，既降低了断网风险，也减少了数据出厂的合规压力。

实施中的三个隐形陷阱

架构图漂亮不等于落地顺利。东方科技复盘项目时总结出三个高频问题：

1. 设备身份管理缺失——大量项目用简单序列号做认证，缺乏一机一密的证书体系，后期无法安全地做OTA升级
2. 时序数据存储选型随意——用MySQL存传感器数据，写入瓶颈通常在设备量破千时就出现，InfluxDB或TDengine是更匹配的选择
3. 固件升级通道未预留——智能硬件的固件迭代是常态，方案设计阶段就要规划差分升级和回滚机制

这些问题的共同点是：不影响Demo演示，但会在规模化阶段集中爆发。东方科技目前在所有物联网技术方案交付中，强制要求包含设备身份生命周期管理和OTA通道设计两个模块。

从应用前景看，物联网正在从「连接」走向「智能」。端侧AI芯片的成熟让设备具备本地推理能力，云端则聚焦模型训练和跨设备协同。对于正在规划物联网项目的团队，架构选型的优先级应该是：安全机制 > 可扩展性 > 成本优化。先保证系统能安全地长大，再考虑跑得多快。