IoT 架构从 0 到 1

一、自建还是云平台关键决策因素在启动 IoT 项目时第一个问题就是自建还是用云平台选择云平台的场景✅ 小公司人员规模有限✅ MVP 阶段需要快速验证✅ 设备规模较小 10 万✅ 团队缺乏运维经验选择自建的理由✅ 设备规模很大长期成本考虑✅ 数据隐私和合规要求高✅ 想掌握核心物联基建能力✅ 有专门的运维团队我们的选择自建。原因是设备主要销往欧洲数据合规要求严格且长期设备规模预期较大。二、整体架构设计Device / APP / Browser│┌───────────────┼────────────────┐│ │MQTT TCP MQTT WebSocket│ │▼ ▼AWS NLB :1883 AWS ALB :443│ │▼ ▼EMQX Cluster (EC2)┌─────────┬─────────┬─────────┐│ │ │ │EMQX1 EMQX2 EMQX3 EMQX4│ │ │ │└───────── EMQX Cluster Sync ────────────┘│┌────────┴────────┐▼ ▼Redis Mysql(ElastiCache)/Cache Device Data架构说明组件作用选型接入层负载均衡AWS NLB/ALB消息层MQTT BrokerEMQX Cluster缓存层会话/缓存Redis ElastiCache存储层设备数据MySQL三、为什么选择 MQTT经过对比我们最终选择 MQTT 作为通信协议主要基于以下原因1. 弱网络环境适配设备销售国家多为弱网络地区欧洲部分区域、东南亚MQTT 的轻量级协议头更适合不稳定网络。2. 长连接 消息推送需要建立持久连接支持服务端主动推送如日程创建通知双向通信能力3. 自动重连 心跳机制设备网络差时自动重连心跳保活降低功耗QoS 级别保证消息可靠性4. 发布/订阅模式设备与业务解耦便于横向扩展。四、为什么不用 KafkaKafka 是优秀的消息队列但不适合 IoT 设备接入场景对比项MQTTKafka连接方式长连接短连接消息推送支持需主动拉取设备适配轻量级较重双向通信原生支持需额外设计结论Kafka 更适合服务端内部消息流转MQTT 更适合设备接入层。五、为什么选择 AWS1. 全球网络覆盖设备主要集中在欧洲AWS 在欧洲、东南亚、美国的网络质量更优延迟更低。2. 云产品生态完善NLB/ALB 负载均衡EC2 弹性计算ElastiCache 托管 RedisRDS 托管 MySQL完善的监控和告警3. 合规优势AWS 符合 GDPR 等欧洲数据合规要求减少法务风险。六、EMQX 集群部署要点集群规模4 节点 EMQX 集群支持水平扩展节点间自动同步关键配置# 集群发现cluster.discovery_strategy aws_ec2# 会话保持session.queued_message_max_size 1000# 心跳间隔keepalive_multiplier 1.5七、总结与建议技术选型总结决策点选择理由协议MQTT弱网适配、长连接、推送BrokerEMQX开源、集群、高性能云厂商AWS全球网络、合规、生态部署方式自建数据可控、长期成本给后来者的建议MVP 阶段先用云服务如 AWS IoT Core验证业务模式规模上来后再自建避免过早优化重视监控告警IoT 系统故障影响面大预留扩展能力设备增长往往超预期