这两年做物联网平台项目Java算是我的主力技术栈。经常有人问Java到底适不适合搞物联网我一般会反问一句你说的物联网是嵌入式那层还是平台那层如果是做设备端固件Java确实不如C直接但如果目标是承载数万设备、稳定处理每天上亿条上报数据那Java搭配Netty、消息中间件、时序数据库是我实测下来最稳的组合之一。这篇文章就围绕JAVA物联网平台讲讲我踩过的坑和沉淀下来的方法论适合想从零搭建平台、或者正在从单机Demo往生产级集群过渡的团队参考。1. 用Java搭物联网平台第一步不是选框架而是定边界1.1 为什么Java在物联网领域常常被低估先说个反直觉的结论Java做物联网平台最大的优势恰恰是重。物联网平台的核心痛点不是并发量而是长期稳定性和生态承接能力。设备数量上去了以后连接层、消息管道、数据存储、业务服务每一块都是持续演进的复杂系统Java生态里每一个环节都有成熟方案可以接手。我项目里用到的典型技术栈是这样设备接入用NettyMQTT协议层用EMQX Broker消息流转用Kafka设备状态和影子数据放Redis时序数据落TDengine业务数据在MySQL。这套组合里除了EMQX之外全是Java生态或者有成熟Java客户端的组件团队换人接手也容易。这里要澄清一个常见误区Java并不是用来跑在传感器或单片机上的。现在很多带屏幕的智能设备确实跑的是Android底层是Java虚拟机但工业设备、水电表、传感器终端那边大多数还是走C/C或者专用SDK。Java的位置是平台侧——所有设备数据汇聚到云端之后的接入、存储、计算、管理、开放API这一整套东西才是Java的主场。1.2 平台该管什么不管什么动手写第一版框架前我给自己列过一张边界清单把物联网平台该管和不该管的事情钉死。平台该管三件事连接、存储、分发。连接是指设备接入、认证、心跳保活和下行指令通道存储是指上报数据的落库、归档和查询分发是指把数据推给业务系统、告警服务或者实时大屏。最怕的是把不该平台管的东西揉进来。我见过很多团队把规则引擎、设备OTA升级状态机、业务审批流程全塞进接入层最后接入层变成一个大泥球改一个协议适配要牵连告警逻辑动一个告警逻辑要影响OTA链路。我的建议是平台只做传输管道和数据底座规则引擎单独拆服务OTA单独拆服务设备接入层只负责收报文、转标准格式、交给下游这三件事。一句话总结Java物联网平台的核心竞争力不是能收到数据而是稳定地收、可靠地存、安全地分。2. 一条数据从设备到业务屏幕跨过了哪些层级2.1 五层链路设计我把整个平台的数据链路拆成五层每一层管一件事层与层之间通过接口和消息解耦层级职责关键组件接入层设备网络接入、协议解析、连接管理Netty、EMQX消息层数据流转、削峰填谷、顺序保证Kafka存储层时序数据、状态数据、业务数据的落库与查询TDengine、Redis、MySQL服务层设备管理、产品模型、告警规则、权限控制Spring Boot接口层对外RESTful API、WebSocket推送Spring MVC、Netty这个分层最核心的目的是让数据路径有序。设备上报的数据不会直接写数据库而是先进入消息层写库动作由独立的消费服务完成。这样做的直接好处是瞬时流量不会打崩数据库。我遇到过很典型的场景某批次设备凌晨统一重启开机注册请求瞬间冲上来如果这个时候写库链路直连数据库数据库连接池直接被打满正常业务查询也跟着挂。但数据先进Kafka消费者按自身吞吐能力慢慢落库系统最多是出现几秒钟消费延迟很快就会追平这比数据库被压垮再恢复要安全得多。2.2 统一消息结构所有协议最终都变成同一个对象设备端协议五花八门有MQTT、有HTTP定时上报、有TCP自定义二进制、有Modbus RTU通过DTU网关转发上来。如果每个协议都定义一套数据格式下游每个模块都要适配多套格式那就乱套了。我做的妥协是所有Adapter解析完最终都转换成一个统一的标准消息对象。public class StandardMessage { private Long productId; // 产品标识 private String deviceId; // 设备标识 private Long timestamp; // 上报时间毫秒 private MapString, Object properties; // 物模型属性 private String eventId; // 可选事件ID private byte[] rawPayload; // 原始报文用于追溯 }后续所有模块只认StandardMessage这个结构不关心原始报文来自哪种协议。新增设备类型时只写新的Adapter做协议转换下游代码零改动。这套设计在接入几十种不同设备时节省的维护成本是非常明显的。3. 设备接入层的三个硬骨头连接、心跳、协议解析3.1 Netty长连接管理与Channel上下文接入层是整个平台最敏感的一层因为设备接入数量和稳定性直接决定了平台口碑。我用的方案是用Netty统一承载TCP和HTTP请求MQTT这层因为协议复杂度太高一期用Netty做了个简陋版二期改成了EMQX自己只保留设备认证回调。Netty连接管理有几个细节值得反复确认。第一个是用IdleStateHandler做心跳超时检测读空闲超过设定时间就主动断开连接并释放资源防止僵尸连接占满服务端句柄。第二个是用ChannelGroup统一管理所有活跃连接服务端发布重启通知时可以借助它广播消息。第三个是每个Channel的attr里保存设备上下文一次连接成功后设备ID、产品ID直接存到Channel属性里后续报文进来不用再查一次数据库确认设备是否存在。ChannelGroup channels new DefaultChannelGroup(GlobalEventExecutor.INSTANCE); // 在handler里收报文的时候直接从channel attr取设备上下文 DeviceContext ctx channel.attr(AttributeKey.valueOf(device)).get();这个看起来简单的设计避免了很多重复查询也让报文处理逻辑变得非常轻。3.2 协议解析把报文模板做成配置而不是代码设备二进制报文的格式差异很大但单独看某一类设备帧结构通常是固定的帧头、地址域、功能码、数据长度、数据区、校验码。我的做法是做一个简化版的报文模板机制把字段偏移、字节序、数据类型都配置化。public class FieldDefinition { private int offset; // 字段在报文中的偏移 private int length; // 字段长度 private String byteOrder; // BIG_ENDIAN / LITTLE_ENDIAN private String dataType; // UINT8 / UINT16 / FLOAT / BCD / STRING private String name; // 字段名 private double scale; // 缩放系数比如上报值是368实际温度36.8 }平台解析引擎根据模板配置读取报文再按缩放系数转换实际数值。这样做的好处是同类协议不同型号的新设备接入时配置一条记录就能解析不用改代码重新发版。我在接入电表、温控器、水浸传感器、门磁这些设备时基本走的都是这个套路。当然报文模板不是万能药。有些设备报文里的数据是变长的比如带GPS的定位器坐标数据长度每次可能不同。这种情况就要在模板里增加长度字段引用的机制先读一个字节得到数据长度再按动态偏移继续解析。这种复杂度建议在一开始就保留扩展点不要为了快把模板机制写死。3.3 离线判定、设备影子与掉线补偿设备管理里最影响用户体验的是在线状态不准。我见过很多平台用进程内存标记在线Netty连接一断就置为离线但设备在弱网环境下的连接本来就时断时续这种做法会造成频繁的上线下线抖动告警风暴就是这么来的。我实际采用的是时间窗口判定策略。以心跳周期为基准一般将离线判定窗口设为心跳周期的1.5到2倍。比如设备5分钟一次心跳那么15分钟没有新数据才会判定离线避免网络抖动导致误报。这个值不能拍脑袋定需要结合设备实际通信频率、网络环境和业务容忍度来调。设备影子机制也是接入层非常值得做的一个模块。影子就是平台侧保存的设备期望状态设备离线期间App上修改的配置不会直接下发而是先写入影子等设备上线后自动对比影子和实际状态有差异就补发指令。没有影子机制的弱网平台用户设置一次温度设备永远收不到投诉率会非常难看。4. 消息管道设计上行进Kafka、下行走Netty通道4.1 上下行两条链路的差异化设计设备数据从接入层到业务层实际上要经过两条链路。上行链路是数据从设备到平台的消息中间件这是核心数据通道我用的是Kafka。Topic按产品ID划分同一设备的消息通过设备ID哈希取模确保进入同一个分区从而保证同一设备的数据有序。下行链路是平台给设备下发指令。因为指令下发要求实时性高我的做法是优先走Netty的长连接通道设备不在线时把指令存入Redis待发送队列等设备上线后通过设备影子机制补发。这里必须强调补发机制不是可选项而是必须项。在4G网络不稳定的场景里设备频繁上下线没有补发机制用户的指令就会凭空丢失。4.2 MQTT Broker选型的经验谈我在自研MQTT Broker和部署EMQX之间来回犹豫过。自研一轮确实能深入理解MQTT的会话状态、遗嘱消息、QoS语义这对排查问题很有帮助但生产环境我最后还是选了EMQX。原因非常实际MQTT 5.0协议的QoS 2状态机非常复杂自研要达到生产级可靠性需要大量时间和测试投入EMQX原生支持MQTT 3.1.1和5.0有认证钩子可以对接我的Java鉴权服务而且集群共享订阅能力成熟。除非你的核心产品就是MQTT服务本身否则不要重造这个轮子。把自研的时间省下来投入在业务层和数据处理上回报率要高得多。4.3 指令下发的幂等、超时与回执校验给设备下发命令看着简单做起来全是坑。典型场景是App点击打开开关平台把指令发给设备设备也执行了但回执在网络传输中丢失。平台没收到回执就重试设备又把开关执行了一遍这是无法接受的。我给指令下发定了三条硬性规则。第一每条指令带全局唯一的messageId设备回执必须携带原ID。第二平台侧缓存已下发指令及状态收到正确回执才算完成。第三重试时携带原messageId设备端对同一messageId去重只执行一次。需要落地的模块有三个指令ID生成器、Redis缓存指令状态、超时扫描任务。任何一个环节缺失指令都会出乱子。我见过比较隐蔽的一个问题是指令状态缓存使用了固定短TTL导致一条指令在超时边缘被误判失败重试后设备又执行了一次。这个TTL必须大于指令超时时间加上合理余量并且要考虑网络高峰期链路变慢的极端情况。5. 三类数据三种存储时序、状态与业务的取舍5.1 存储选型与分区策略物联网平台的数据类型差异极大不能所有数据塞进一个MySQL。我按数据特征拆成三类数据类型典型内容存储方案关键设计时序数据温度、电压、点位上报数据TDengine按设备建子表按时间分区状态数据在线状态、当前属性值、设备影子RedisTTL、哈希结构业务数据产品信息、设备档案、用户权限MySQL事务、约束、索引当时从MySQL迁移到TDengine的契机是设备量超过5万台每分钟一轮上报后MySQL写入压力非常大查询历史趋势更是慢到不可接受。TDengine的超级表和子表模型非常适合物联网场景一个设备一张子表天然将数据按设备物理隔离查询某一设备的历史数据非常高效。5.2 原始数据、聚合数据、归档数据的分级管理时序数据如果不设置保留策略存储成本会快速失控。我的做法是分三档原始点位数据保留3个月用于故障回溯和设备诊断按小时和天聚合的数据保留6个月用于趋势分析和报表月度汇总数据保留2年用于长期运营决策。聚合任务用定时任务在每天凌晨执行先把昨天的分钟级原始数据聚合为小时级和天级结果写入聚合表。前端大屏和报表只查聚合表不回原始表查询速度能提升一个量级。这里要特别提醒聚合任务在集群环境必须加分布式锁否则多实例同时跑归档会造成数据重复写入。6. 四级归属与动态权限多租户平台的隔离细节6.1 产品、设备、租户、用户的归属链企业级物联网平台不是一个简单的设备列表它必须支持的归属关系是设备归属于产品产品归属于租户租户即企业客户租户下面有多个用户账号。这种四级归属链直接决定了权限模型复杂度。我处理数据结构时所有业务表都带tenant_id和应用ID字段查询必须强制带租户过滤条件。光靠开发人员自觉不够我在ORM层写了一个自定义拦截器自动在SQL后面拼接tenant_id条件从机制上杜绝跨租户查询。这个问题一旦出事故就是数据泄露级别容不得半点侥幸。6.2 权限秒级生效而不是重启生效用户权限如果只在登录时加载到内存那么运维人员临时获得某个设备分组管理权限、操作完立刻回收的场景就没法支持因为权限变更要等重新登录才生效。我的方案是在网关层做动态权限校验每次API请求都从Redis读取当前用户的权限集合权限变更时同步更新Redis缓存。这样权限调整秒级生效不需要用户重新登录。这个方案也有代价每次请求多一次Redis读但因为权限数据量不大且网关层有本地缓存兜底整体性能损耗可以接受。7. 集群部署后的稳定性会话共享、分布式锁与告警聚合7.1 单机跑通不等于集群跑通从单机版过渡到集群部署我踩过的三个坑很有代表性。第一个是会话共享。单机版设备连接状态存在本地内存集群后必须把会话状态、设备连接映射迁到Redis。这个迁移有个隐蔽问题设备连接的是A节点如果某个请求被负载均衡转发到了B节点B节点从Redis里能查到设备在线但不知道设备连接在哪个节点指令就没法直接下发了。我的方案是Redis里同时保存设备连接节点信息下发时先查节点找到节点后通过内部RPC把指令转发到对应节点再由该节点的Netty通道发给设备。第二个是定时任务冲突。Spring的Scheduled任务在每个节点都会执行如果不加分布式锁数据归档、报表聚合、超时扫描这些任务会被多个节点重复执行。我用Redisson的分布式锁包住了所有定时任务保证同一时刻只有一个节点在执行。第三个是负载均衡与长连接的配合。Netty长连接如果被负载均衡器定期清理设备连接会莫名断开。需要把LB的空闲超时时间调大并且客户端要有自动重连机制否则设备会大量出现假在线。7.2 监控指标只留五个监控面板我精简到五个指标再多容易失真连接数、消息吞吐、消息堆积数、指令下发成功率、时序库写入失败数。指令下发成功率是里面最有价值的指标。它综合反映了设备在线率、网络链路质量、消息中间件状态和接入层健康程度。这个数字如果掉到90%以下不用看别的指标直接沿着指令下发链路排查就行先查设备在线状态再查Redis缓存再查Netty通道最后查设备回执。我印象最深的一次事故是某办公楼装修期间切断了设备网络8分钟内平台生成了上百条离线通知和几万条告警短信网关直接被冲爆。后来我们把告警逻辑从逐设备触发改成按楼栋聚合触发一个网络分区只发一条告警附带受影响设备数量从根上解决了告警风暴。这个经验后来推广到所有场景任何告警都先聚合再推送聚合维度可以是区域、楼栋、设备分组防止批量故障时对通知渠道造成冲击。8. 我把实战中的几个坑记了下来第一不要在项目初期就去自研MQTT Broker。自研一轮的目的是理解协议细节但生产级MQTT服务需要非常成熟的QoS状态机和集群能力直接上EMQX这类成熟产品把省下来的时间投到业务层性价比高得多。第二上线前一定做弱网模拟测试。用工具模拟20%丢包率、500ms延迟的网络环境观察平台会不会误判离线、指令会不会重复重试。这个测试如果不上线前做生产环境一定会被网络问题教育。第三设备接入层的代码要尽量无状态。接入层的实例随时可能重启如果连接状态和业务状态都放在本地内存每次重启都会造成全量设备重连。把状态外移到Redis接入层就变成了可以随时扩缩容的无状态节点。第四不要忽略设备厂商的非标准行为。很多设备虽然宣称走MQTT协议但有的设备在重连时不会携带遗嘱消息有的设备上报的topic大小写不统一有的设备会周期性发一条空数据请求保活。这些都需要在Adapter层做容错否则平台日志会被各种异常刷屏。做个JAVA物联网平台本质上拼的不是什么高深算法而是对连接、消息、数据、权限、运维这些基础能力的耐心打磨。把边界划清楚把每一层的职责定死再通过实际事故不断修正细节平台才能从能跑慢慢变成扛得住。
Java物联网平台实战：从设备接入到集群稳定的完整方法论
这两年做物联网平台项目Java算是我的主力技术栈。经常有人问Java到底适不适合搞物联网我一般会反问一句你说的物联网是嵌入式那层还是平台那层如果是做设备端固件Java确实不如C直接但如果目标是承载数万设备、稳定处理每天上亿条上报数据那Java搭配Netty、消息中间件、时序数据库是我实测下来最稳的组合之一。这篇文章就围绕JAVA物联网平台讲讲我踩过的坑和沉淀下来的方法论适合想从零搭建平台、或者正在从单机Demo往生产级集群过渡的团队参考。1. 用Java搭物联网平台第一步不是选框架而是定边界1.1 为什么Java在物联网领域常常被低估先说个反直觉的结论Java做物联网平台最大的优势恰恰是重。物联网平台的核心痛点不是并发量而是长期稳定性和生态承接能力。设备数量上去了以后连接层、消息管道、数据存储、业务服务每一块都是持续演进的复杂系统Java生态里每一个环节都有成熟方案可以接手。我项目里用到的典型技术栈是这样设备接入用NettyMQTT协议层用EMQX Broker消息流转用Kafka设备状态和影子数据放Redis时序数据落TDengine业务数据在MySQL。这套组合里除了EMQX之外全是Java生态或者有成熟Java客户端的组件团队换人接手也容易。这里要澄清一个常见误区Java并不是用来跑在传感器或单片机上的。现在很多带屏幕的智能设备确实跑的是Android底层是Java虚拟机但工业设备、水电表、传感器终端那边大多数还是走C/C或者专用SDK。Java的位置是平台侧——所有设备数据汇聚到云端之后的接入、存储、计算、管理、开放API这一整套东西才是Java的主场。1.2 平台该管什么不管什么动手写第一版框架前我给自己列过一张边界清单把物联网平台该管和不该管的事情钉死。平台该管三件事连接、存储、分发。连接是指设备接入、认证、心跳保活和下行指令通道存储是指上报数据的落库、归档和查询分发是指把数据推给业务系统、告警服务或者实时大屏。最怕的是把不该平台管的东西揉进来。我见过很多团队把规则引擎、设备OTA升级状态机、业务审批流程全塞进接入层最后接入层变成一个大泥球改一个协议适配要牵连告警逻辑动一个告警逻辑要影响OTA链路。我的建议是平台只做传输管道和数据底座规则引擎单独拆服务OTA单独拆服务设备接入层只负责收报文、转标准格式、交给下游这三件事。一句话总结Java物联网平台的核心竞争力不是能收到数据而是稳定地收、可靠地存、安全地分。2. 一条数据从设备到业务屏幕跨过了哪些层级2.1 五层链路设计我把整个平台的数据链路拆成五层每一层管一件事层与层之间通过接口和消息解耦层级职责关键组件接入层设备网络接入、协议解析、连接管理Netty、EMQX消息层数据流转、削峰填谷、顺序保证Kafka存储层时序数据、状态数据、业务数据的落库与查询TDengine、Redis、MySQL服务层设备管理、产品模型、告警规则、权限控制Spring Boot接口层对外RESTful API、WebSocket推送Spring MVC、Netty这个分层最核心的目的是让数据路径有序。设备上报的数据不会直接写数据库而是先进入消息层写库动作由独立的消费服务完成。这样做的直接好处是瞬时流量不会打崩数据库。我遇到过很典型的场景某批次设备凌晨统一重启开机注册请求瞬间冲上来如果这个时候写库链路直连数据库数据库连接池直接被打满正常业务查询也跟着挂。但数据先进Kafka消费者按自身吞吐能力慢慢落库系统最多是出现几秒钟消费延迟很快就会追平这比数据库被压垮再恢复要安全得多。2.2 统一消息结构所有协议最终都变成同一个对象设备端协议五花八门有MQTT、有HTTP定时上报、有TCP自定义二进制、有Modbus RTU通过DTU网关转发上来。如果每个协议都定义一套数据格式下游每个模块都要适配多套格式那就乱套了。我做的妥协是所有Adapter解析完最终都转换成一个统一的标准消息对象。public class StandardMessage { private Long productId; // 产品标识 private String deviceId; // 设备标识 private Long timestamp; // 上报时间毫秒 private MapString, Object properties; // 物模型属性 private String eventId; // 可选事件ID private byte[] rawPayload; // 原始报文用于追溯 }后续所有模块只认StandardMessage这个结构不关心原始报文来自哪种协议。新增设备类型时只写新的Adapter做协议转换下游代码零改动。这套设计在接入几十种不同设备时节省的维护成本是非常明显的。3. 设备接入层的三个硬骨头连接、心跳、协议解析3.1 Netty长连接管理与Channel上下文接入层是整个平台最敏感的一层因为设备接入数量和稳定性直接决定了平台口碑。我用的方案是用Netty统一承载TCP和HTTP请求MQTT这层因为协议复杂度太高一期用Netty做了个简陋版二期改成了EMQX自己只保留设备认证回调。Netty连接管理有几个细节值得反复确认。第一个是用IdleStateHandler做心跳超时检测读空闲超过设定时间就主动断开连接并释放资源防止僵尸连接占满服务端句柄。第二个是用ChannelGroup统一管理所有活跃连接服务端发布重启通知时可以借助它广播消息。第三个是每个Channel的attr里保存设备上下文一次连接成功后设备ID、产品ID直接存到Channel属性里后续报文进来不用再查一次数据库确认设备是否存在。ChannelGroup channels new DefaultChannelGroup(GlobalEventExecutor.INSTANCE); // 在handler里收报文的时候直接从channel attr取设备上下文 DeviceContext ctx channel.attr(AttributeKey.valueOf(device)).get();这个看起来简单的设计避免了很多重复查询也让报文处理逻辑变得非常轻。3.2 协议解析把报文模板做成配置而不是代码设备二进制报文的格式差异很大但单独看某一类设备帧结构通常是固定的帧头、地址域、功能码、数据长度、数据区、校验码。我的做法是做一个简化版的报文模板机制把字段偏移、字节序、数据类型都配置化。public class FieldDefinition { private int offset; // 字段在报文中的偏移 private int length; // 字段长度 private String byteOrder; // BIG_ENDIAN / LITTLE_ENDIAN private String dataType; // UINT8 / UINT16 / FLOAT / BCD / STRING private String name; // 字段名 private double scale; // 缩放系数比如上报值是368实际温度36.8 }平台解析引擎根据模板配置读取报文再按缩放系数转换实际数值。这样做的好处是同类协议不同型号的新设备接入时配置一条记录就能解析不用改代码重新发版。我在接入电表、温控器、水浸传感器、门磁这些设备时基本走的都是这个套路。当然报文模板不是万能药。有些设备报文里的数据是变长的比如带GPS的定位器坐标数据长度每次可能不同。这种情况就要在模板里增加长度字段引用的机制先读一个字节得到数据长度再按动态偏移继续解析。这种复杂度建议在一开始就保留扩展点不要为了快把模板机制写死。3.3 离线判定、设备影子与掉线补偿设备管理里最影响用户体验的是在线状态不准。我见过很多平台用进程内存标记在线Netty连接一断就置为离线但设备在弱网环境下的连接本来就时断时续这种做法会造成频繁的上线下线抖动告警风暴就是这么来的。我实际采用的是时间窗口判定策略。以心跳周期为基准一般将离线判定窗口设为心跳周期的1.5到2倍。比如设备5分钟一次心跳那么15分钟没有新数据才会判定离线避免网络抖动导致误报。这个值不能拍脑袋定需要结合设备实际通信频率、网络环境和业务容忍度来调。设备影子机制也是接入层非常值得做的一个模块。影子就是平台侧保存的设备期望状态设备离线期间App上修改的配置不会直接下发而是先写入影子等设备上线后自动对比影子和实际状态有差异就补发指令。没有影子机制的弱网平台用户设置一次温度设备永远收不到投诉率会非常难看。4. 消息管道设计上行进Kafka、下行走Netty通道4.1 上下行两条链路的差异化设计设备数据从接入层到业务层实际上要经过两条链路。上行链路是数据从设备到平台的消息中间件这是核心数据通道我用的是Kafka。Topic按产品ID划分同一设备的消息通过设备ID哈希取模确保进入同一个分区从而保证同一设备的数据有序。下行链路是平台给设备下发指令。因为指令下发要求实时性高我的做法是优先走Netty的长连接通道设备不在线时把指令存入Redis待发送队列等设备上线后通过设备影子机制补发。这里必须强调补发机制不是可选项而是必须项。在4G网络不稳定的场景里设备频繁上下线没有补发机制用户的指令就会凭空丢失。4.2 MQTT Broker选型的经验谈我在自研MQTT Broker和部署EMQX之间来回犹豫过。自研一轮确实能深入理解MQTT的会话状态、遗嘱消息、QoS语义这对排查问题很有帮助但生产环境我最后还是选了EMQX。原因非常实际MQTT 5.0协议的QoS 2状态机非常复杂自研要达到生产级可靠性需要大量时间和测试投入EMQX原生支持MQTT 3.1.1和5.0有认证钩子可以对接我的Java鉴权服务而且集群共享订阅能力成熟。除非你的核心产品就是MQTT服务本身否则不要重造这个轮子。把自研的时间省下来投入在业务层和数据处理上回报率要高得多。4.3 指令下发的幂等、超时与回执校验给设备下发命令看着简单做起来全是坑。典型场景是App点击打开开关平台把指令发给设备设备也执行了但回执在网络传输中丢失。平台没收到回执就重试设备又把开关执行了一遍这是无法接受的。我给指令下发定了三条硬性规则。第一每条指令带全局唯一的messageId设备回执必须携带原ID。第二平台侧缓存已下发指令及状态收到正确回执才算完成。第三重试时携带原messageId设备端对同一messageId去重只执行一次。需要落地的模块有三个指令ID生成器、Redis缓存指令状态、超时扫描任务。任何一个环节缺失指令都会出乱子。我见过比较隐蔽的一个问题是指令状态缓存使用了固定短TTL导致一条指令在超时边缘被误判失败重试后设备又执行了一次。这个TTL必须大于指令超时时间加上合理余量并且要考虑网络高峰期链路变慢的极端情况。5. 三类数据三种存储时序、状态与业务的取舍5.1 存储选型与分区策略物联网平台的数据类型差异极大不能所有数据塞进一个MySQL。我按数据特征拆成三类数据类型典型内容存储方案关键设计时序数据温度、电压、点位上报数据TDengine按设备建子表按时间分区状态数据在线状态、当前属性值、设备影子RedisTTL、哈希结构业务数据产品信息、设备档案、用户权限MySQL事务、约束、索引当时从MySQL迁移到TDengine的契机是设备量超过5万台每分钟一轮上报后MySQL写入压力非常大查询历史趋势更是慢到不可接受。TDengine的超级表和子表模型非常适合物联网场景一个设备一张子表天然将数据按设备物理隔离查询某一设备的历史数据非常高效。5.2 原始数据、聚合数据、归档数据的分级管理时序数据如果不设置保留策略存储成本会快速失控。我的做法是分三档原始点位数据保留3个月用于故障回溯和设备诊断按小时和天聚合的数据保留6个月用于趋势分析和报表月度汇总数据保留2年用于长期运营决策。聚合任务用定时任务在每天凌晨执行先把昨天的分钟级原始数据聚合为小时级和天级结果写入聚合表。前端大屏和报表只查聚合表不回原始表查询速度能提升一个量级。这里要特别提醒聚合任务在集群环境必须加分布式锁否则多实例同时跑归档会造成数据重复写入。6. 四级归属与动态权限多租户平台的隔离细节6.1 产品、设备、租户、用户的归属链企业级物联网平台不是一个简单的设备列表它必须支持的归属关系是设备归属于产品产品归属于租户租户即企业客户租户下面有多个用户账号。这种四级归属链直接决定了权限模型复杂度。我处理数据结构时所有业务表都带tenant_id和应用ID字段查询必须强制带租户过滤条件。光靠开发人员自觉不够我在ORM层写了一个自定义拦截器自动在SQL后面拼接tenant_id条件从机制上杜绝跨租户查询。这个问题一旦出事故就是数据泄露级别容不得半点侥幸。6.2 权限秒级生效而不是重启生效用户权限如果只在登录时加载到内存那么运维人员临时获得某个设备分组管理权限、操作完立刻回收的场景就没法支持因为权限变更要等重新登录才生效。我的方案是在网关层做动态权限校验每次API请求都从Redis读取当前用户的权限集合权限变更时同步更新Redis缓存。这样权限调整秒级生效不需要用户重新登录。这个方案也有代价每次请求多一次Redis读但因为权限数据量不大且网关层有本地缓存兜底整体性能损耗可以接受。7. 集群部署后的稳定性会话共享、分布式锁与告警聚合7.1 单机跑通不等于集群跑通从单机版过渡到集群部署我踩过的三个坑很有代表性。第一个是会话共享。单机版设备连接状态存在本地内存集群后必须把会话状态、设备连接映射迁到Redis。这个迁移有个隐蔽问题设备连接的是A节点如果某个请求被负载均衡转发到了B节点B节点从Redis里能查到设备在线但不知道设备连接在哪个节点指令就没法直接下发了。我的方案是Redis里同时保存设备连接节点信息下发时先查节点找到节点后通过内部RPC把指令转发到对应节点再由该节点的Netty通道发给设备。第二个是定时任务冲突。Spring的Scheduled任务在每个节点都会执行如果不加分布式锁数据归档、报表聚合、超时扫描这些任务会被多个节点重复执行。我用Redisson的分布式锁包住了所有定时任务保证同一时刻只有一个节点在执行。第三个是负载均衡与长连接的配合。Netty长连接如果被负载均衡器定期清理设备连接会莫名断开。需要把LB的空闲超时时间调大并且客户端要有自动重连机制否则设备会大量出现假在线。7.2 监控指标只留五个监控面板我精简到五个指标再多容易失真连接数、消息吞吐、消息堆积数、指令下发成功率、时序库写入失败数。指令下发成功率是里面最有价值的指标。它综合反映了设备在线率、网络链路质量、消息中间件状态和接入层健康程度。这个数字如果掉到90%以下不用看别的指标直接沿着指令下发链路排查就行先查设备在线状态再查Redis缓存再查Netty通道最后查设备回执。我印象最深的一次事故是某办公楼装修期间切断了设备网络8分钟内平台生成了上百条离线通知和几万条告警短信网关直接被冲爆。后来我们把告警逻辑从逐设备触发改成按楼栋聚合触发一个网络分区只发一条告警附带受影响设备数量从根上解决了告警风暴。这个经验后来推广到所有场景任何告警都先聚合再推送聚合维度可以是区域、楼栋、设备分组防止批量故障时对通知渠道造成冲击。8. 我把实战中的几个坑记了下来第一不要在项目初期就去自研MQTT Broker。自研一轮的目的是理解协议细节但生产级MQTT服务需要非常成熟的QoS状态机和集群能力直接上EMQX这类成熟产品把省下来的时间投到业务层性价比高得多。第二上线前一定做弱网模拟测试。用工具模拟20%丢包率、500ms延迟的网络环境观察平台会不会误判离线、指令会不会重复重试。这个测试如果不上线前做生产环境一定会被网络问题教育。第三设备接入层的代码要尽量无状态。接入层的实例随时可能重启如果连接状态和业务状态都放在本地内存每次重启都会造成全量设备重连。把状态外移到Redis接入层就变成了可以随时扩缩容的无状态节点。第四不要忽略设备厂商的非标准行为。很多设备虽然宣称走MQTT协议但有的设备在重连时不会携带遗嘱消息有的设备上报的topic大小写不统一有的设备会周期性发一条空数据请求保活。这些都需要在Adapter层做容错否则平台日志会被各种异常刷屏。做个JAVA物联网平台本质上拼的不是什么高深算法而是对连接、消息、数据、权限、运维这些基础能力的耐心打磨。把边界划清楚把每一层的职责定死再通过实际事故不断修正细节平台才能从能跑慢慢变成扛得住。
