1. 为什么到了现在做物联网平台我依然会选Java先交代一下背景。我最近在帮一个做工业设备远程运维的团队做技术选型他们想自研一套物联网平台技术栈还没定内部争论了很久。有人提议用Go有人说Node.js开发快还有人觉得Python写AI算法方便最后问到我的时候我的回答很直接如果你们的重点是平台侧——设备接入、数据治理、规则引擎、对外API这套东西——那Java仍然是现阶段最稳的选择。这个结论不是拍脑袋。物联网平台这个词看起来简单实际拆开之后要承担的事情特别多海量设备的长连接维护、多协议解析、数据吞吐、消息路由、告警计算、权限体系、可视化大屏后端、第三方系统对接。这些需求每一个单拎出来Java生态里都有经过大规模生产验证的组件可以兜底。Netty处理高并发TCP接入是事实标准EMQX虽然底层是Erlang但Java客户端生态成熟Spring Cloud体系做微服务治理也是一套老练的打法。很多年轻工程师对Java的第一印象是重。说实话写个定时任务、做个CRUD后台Java确实不如Python、Node.js来得快但物联网平台的复杂性决定了它不是CRUD。你今天要对接的是一批只支持Modbus TCP的老设备明天可能要接入MQTT协议的智能硬件后天客户要求平台能每秒消化上万条遥测数据并触发告警。这种复杂度下Java的类型系统、成熟的并发工具、完善的监控生态Micrometer、Prometheus、Arthas能让你在排查问题的时候少掉很多头发。还有一个常被忽略但很重要的因素招人。Java工程师的供给量在所有后端语言里始终是最大的。物联网平台不是写完就结束的项目它要长期迭代中途会有人员流动。一个冷门语言写的东西两三年后没人接得住那才是真正的灾难。Java在这方面的容错率很高社区资料多、面试题多、解决方案也多新接手的人上手成本低。当然Java也不是包打天下。设备端的固件、资源受限的边缘网关、需要极低延迟的实时控制面这些场景我通常建议用C/C、Rust或者Python去处理。Java的位置是在平台侧也就是设备数据汇聚之后的处理中枢而不是贴近硬件的边缘神经末梢。搞清楚这个边界选型的时候就不会被Java太重这种话带偏。1.1 Java被吐槽的点和它真正的强项吐槽Java的人往往集中在两个点上内存占用高、启动慢。这个批评在微服务满天飞的今天确实有道理一个空Spring Boot应用跑起来就要几百MB内存容器化部署时资源成本比Go高不少。但物联网平台通常不是单实例部署而是多个服务配合JVM的堆外内存、元空间、线程栈这些开销可以通过合理的资源配置来控制。启动慢的问题在现代JavaGraalVM原生镜像和云原生实践的加持下也在缓解只是生产环境里我一般不会为了启动速度去牺牲生态成熟度。Java真正的强项是它的工业级确定性。JMMJava内存模型对并发行为的约束、JUC包下经过JDK团队长期打磨的并发容器和工具类、类型系统在编译期就能拦住一大批低级错误——这些特性在大规模、长时间运行的平台型项目里价值极高。设备接入层要处理成千上万个TCP连接每个连接都有自己的状态Go的goroutine虽然轻量但遇到复杂状态机时Java显式的线程池和连接状态管理反而更容易控制和排查。不要小看可排查性线上问题定位的速度往往决定了平台的可用性。1.2 什么位置适合Java什么位置坚决不用这是我给所有自研物联网平台的团队都会画的一条分界线平台中枢用Java边缘接入按需混用设备端别碰Java。设备端MCU级别资源极其有限跑Java虚拟机不现实那里是C和Rust的天下。边缘网关如果跑在树莓派或ARM工控机上Python或Go可以快速搞定协议转换数据清洗之后再往平台推。Java的位置是从网关接入之后开始的统一设备接入服务、消息路由、规则引擎、数据存储、API服务。这个分层方式不是我发明的是工业物联网领域大量实践沉淀出来的通用划分按这个边界选型各层的技术优势都能发挥出来。2. 一个能扛住生产环境的Java物联网平台架构骨架是这样的聊完了选型逻辑进入正题。我见过不少团队拿着开源项目就往上堆功能结果设备量一涨就崩。核心原因是没搞明白平台架构里每一层到底是干什么的。我按照自己落地过的项目把Java物联网平台的架构分成四个层次来讲接入层、处理层、存储层、开放层。每一层都有明确的技术选型逻辑照着这个骨架去搭即使不用我下面推荐的组件替换思路也是通用的。接入层是设备与平台之间的第一道门所以它的核心能力是hold住连接。设备不是浏览器不会用完就走它们会始终保持连接、定期上报数据一个网关后面可能挂几十个子设备连接数很容易冲上十万甚至百万。这一层最常用的技术就是Netty——Java高性能网络通信框架几乎所有Java物联网开源平台的接入层底层都是它。Netty的Reactor线程模型能让你用少量线程支撑海量连接配合自定义协议编解码器不管是TCP私有协议、Modbus还是HTTP轮询都能统一桥接进来。处理层负责把接入层收到的原始报文变成业务可用的数据并触发相应的业务动作。这一层包括协议解析、数据清洗、规则引擎、告警计算、设备命令下发等。规则引擎是这里的核心难点——后面我会专门用一节来讲。处理层的数据流场景通常用消息队列来解耦Kafka是首选吞吐量高、持久化可靠、分区机制特别适合设备消息这种基于设备ID做有序处理的场景。存储层是物联网平台经常翻车的地方。很多团队一开始只用了MySQL跑到几十万条数据后查询开始变慢然后才意识到时序数据需要专门的存储引擎。物联网平台的数据可以分成三类设备基础信息设备ID、厂商、型号、配置参数放MySQL或PostgreSQL这类关系库遥测数据温度、湿度、电压、开关状态等带时间戳的指标放时序数据库比如InfluxDB、TDengine或者IoTDB实时在线状态、最新属性值这种高频读写的数据放Redis。三层存储各司其职不要试图用一个库解决所有问题。开放层是平台对外输出的窗口。这个平台不只是给内部运维看的它要给上层应用提供API要给第三方系统推送数据要提供Webhook回调。Spring Cloud Gateway做统一网关、Spring Boot写REST API、WebSocket或SSE做实时推送这些都是Java生态里的基础操作。还有一个容易忽略的点API的鉴权体系。设备凭证、用户Token、应用API Key三套鉴权机制要在开放层一开始就设计清楚后面再补会非常痛苦。2.1 接入层Netty和MQTT Broker不是二选一很多刚接触物联网的人会问一个问题我用Netty自己写接入服务是不是就不需要EMQX了答案是它们解决的是不同层面的问题。Netty是给你自己实现私有TCP协议用的。工业现场大量存量设备还在用Modbus、DL/T 645甚至有些厂商自定义的帧格式这些协议MQTT Broker是不认的你需要用Netty写一套解码器把二进制帧解析成标准格式再转成内部的统一消息模型。Netty也负责和不支持标准MQTT的网关对接这部分无法替代。而对于那些原生支持MQTT协议的智能硬件直接用EMQX这类Broker接入要省事得多。EMQX处理百万级MQTT连接是常态支持共享订阅、遗嘱消息、延迟发布、集群扩展这些能力自己用Netty从零去写没有大半年做不扎实。我实际项目里的做法是Netty接入私有协议和存量设备EMQX接入标准MQTT设备两者解析后的数据统一发到Kafka后端的规则引擎不关心设备到底是从哪个通道进来的。2.2 存储层时序数据库选型要结合查询模式时序数据库的选型是物联网平台里最容易纠结的。我筛选下来主要就三个候选InfluxDB、TDengine、IoTDB。简单说说我的判断标准。如果团队对Java技术栈有执念、场景偏工业物联网设备点位多、数据结构灵活、需要复杂的时序分析IoTDB值得优先试它的底层就是Java写的和平台的融合度很高。如果团队希望部署简单、社区资料丰富InfluxDB的1.x版本是久经考验的选择但要注意2.x版本的数据模型变化比较大选型时要确认团队能适应。如果场景是海量设备、高吞吐写入、而且不少历史数据需要长时间保存TDengine在写入性能和集群架构上有明显优势SQL风格也容易上手。我给一个相对保守的默认建议设备量在万级以下、每秒写入在几千条以内InfluxDB就够了上了万级设备且数据保存周期要求较长优先考虑TDengine或IoTDB。关键是不要拿MySQL硬扛时序数据。关系库做时序查询随便一个时间范围聚合就能把慢查询日志刷屏而且数据文件膨胀后运维成本极高我见过太多项目在这个地方踩坑。2.3 Kafka在数据链路里的定位物联网平台的实时性要求不像金融交易系统那样毫秒必争但也不允许设备数据在链路里丢失。设备上报一条温度数据如果平台因为规则引擎处理不过来就把它丢了那这个平台的基本盘就崩了。所以我在处理层前面强制加一层Kafka作为整个数据链路的缓冲和削峰。设备接入层持续不断地往Kafka的device-telemetry主题写入原始数据规则引擎按需消费处理慢了可以扩展消费者组。Kafka的持久化机制还能保证在服务重启后数据不丢这个特性在物联网场景里特别重要——上夜班的设备不会因为你凌晨发布版本就停止上报。Kafka的分区策略按设备ID取模这样同一设备的消息有序写入同一分区规则引擎消费的时候就能保证单设备数据的时序性告警计算不会串线。3. 设备接入落地实战注册、认证、心跳、断线一个都不能少架构层面讲完了接下来进入编码层面的核心。我见过太多失败的物联网平台项目问题不是出在高大上的算法上而是出在最基本的设备生命周期管理上。设备不是用户用户忘了密码可以找回设备登不上平台你就得去现场。一个标准的生产级设备接入流程至少包含五个环节设备注册、凭证下发、连接认证、心跳维护、断线重连。我把每个环节的要点展开讲一下。设备注册设备第一次接入平台前需要在平台上登记设备的基本信息产品型号、设备编号、密钥平台生成全局唯一的设备ID并下发设备凭证。这一步通常在设备出厂时或者首次上电时完成。要注意的是设备ID的生成规则别用自增ID设备量大了以后会乱套推荐用UUID或者雪花算法生成的分布式ID。凭证下发设备侧拿到凭证后无论是走MQTT还是私有TCP协议连接时都要携带凭证。MQTT的凭证通常是ClientID、用户名、密码私有协议通常是在报文头里携带设备ID和签名。签名算法建议用HMAC-SHA256时间戳密钥做签名防止报文被重放攻击。连接认证服务端收到凭证后要做校验校验通过才允许连接。这里有一个很多初学者容易忽略的点认证服务和接入服务要分离认证失败时不能直接断开TCP而是要返回明确的错误码给设备不然设备方没法区分是网络问题还是凭证问题。心跳维护设备断开连接是常态所以心跳机制是必须的。MQTT协议自带心跳和遗嘱消息机制Broker会检测连接是否存活私有TCP协议的话一般要求设备每隔30秒发送一个心跳包服务端连续三次没收到心跳就判定设备离线。断线重连设备不会因为一次断线就放弃重连策略要设计好——指数退避加重试上限防止设备疯狂重连打垮接入层。设备恢复连接后要能断点续传未上报的数据这个属于设备侧的逻辑但平台侧要提供补传数据不重复的幂等机制。3.1 MQTT设备接入的完整示例假设我们选用EMQX作为MQTT Broker设备侧的接入流程大概长这样设备通过MQTT协议连接平台ClientID格式推荐为产品Key_设备编号例如iot_factory_gateway_001。连接时的用户名密码就是前面提到的设备凭证。连接成功后设备在主题/device/{deviceId}/telemetry上发布遥测数据在主题/device/{deviceId}/event上发布事件数据同时订阅/device/{deviceId}/command来接收平台下发的指令。服务端这边的代码结构核心就是通过订阅EMQX的Webhook或者直接消费Kafka里的消息来响应设备行为。这里我贴一段用Spring Boot集成EMQX Webhook做设备上下线记录的关键代码RestController RequestMapping(/emqx/webhook) public class EmqxWebhookController { Autowired private DeviceStatusService deviceStatusService; PostMapping(/event) public ResponseEntityString handleEvent(RequestBody EmqxEvent event) { // EMQX会在客户端连接、断开、订阅等事件发生时回调此接口 String action event.getAction(); if (client_connected.equals(action)) { String clientId event.getClientId(); deviceStatusService.markOnline(clientId); } else if (client_disconnected.equals(action)) { String clientId event.getClientId(); deviceStatusService.markOffline(clientId); } return ResponseEntity.ok(ok); } }要注意的是Webhook接口要做签名校验EMQX支持在Webhook请求头里带签名服务端验证签名后才能处理防止伪造回调。这个安全细节很容易被忽略我在线上环境就遇到过有人扫描到Webhook地址后强行发送假的上下线事件。3.2 Netty接入层处理私有TCP协议的真实心得如果现场设备不支持MQTT那就要自己用Netty搞一套接入服务。开始之前先想清楚你是在编解码一个固定格式的二进制协议还是在做一套自定义协议这两件事的复杂度差了一个量级。固定格式的协议比如设备上报的报文是帧头(2字节) 设备ID(4字节) 数据类型(1字节) 数据长度(2字节) 数据负载(N字节) CRC校验(2字节)直接用Netty的LengthFieldBasedFrameDecoder就能搞定拆包。但实际项目里工业设备厂商的协议往往会掺杂各种奇怪的设计——数据字段用BCD码编码、同一个字节里塞了多个开关量、CRC算法不是标准CRC16而是厂商魔改版。这些才是真正耗时间的地方。我总结了一个调试Netty解码器的血泪经验先录报文再写解码器。拿一个串口调试工具或者直接在网口抓包把设备上电后发送的原始hex数据完整录下来对照厂商协议文档逐字节解读。我遇到过某厂商文档里写数据域采用大端序但实际设备发出来的是小端序的情况没有真实报文做参照解码器写得再漂亮也是错的。下面是一个简化的Netty服务端初始化代码重点是pipeline的编解码器配置顺序ServerBootstrap bootstrap new ServerBootstrap() .group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .childHandler(new ChannelInitializerSocketChannel() { Override protected void initChannel(SocketChannel ch) { ch.pipeline() // 粘包/拆包处理帧头2字节长度字段在偏移6的位置长度字段占2字节 .addLast(new LengthFieldBasedFrameDecoder(1024, 6, 2, -8, 0)) .addLast(new MyCustomProtocolDecoder()) .addLast(new DeviceMessageHandler()); } });LengthFieldBasedFrameDecoder的参数看着简单实际很容易配置错。1024是单帧最大长度超过这个长度会抛出异常6是长度字段的起始偏移量2是长度字段占用的字节数-8是长度调整值很多协议里长度字段只包含数据负载的长度不包含帧头实际整帧长度要再加上前面的6字节帧头和数据域后面的CRC字节所以是负数最后一个0表示从帧开头剥离的字节数。3.3 设备状态管理的幂等设计设备上下线是高频事件状态管理模块最容易出现的问题是状态不一致。比如设备断线重连后平台显示的还是旧状态设备上线下线事件乱序到达导致状态被错误覆盖。我给的解决方案是状态变更不直接改数据库而是走版本号或者时间戳比对。Redis里存设备在线状态时带上lastHeartbeatTime每次收到心跳或者上下线事件时先比较时间戳只有更新的时间戳才能覆盖旧值。这个设计虽然简单但在高并发设备接入场景下能省掉很多数据库行锁冲突的问题。4. 规则引擎和数据处理链路从原始报文到业务动作设备接入只是开始平台的核心价值在于数据到了之后能干什么。这一步要解决的核心问题是一条设备原始报文进来后如何在毫秒级完成解析、转换、判断、触发告警、存储等一系列动作。我先把数据处理链路梳理一遍设备原始报文 → 协议解析 → 统一数据模型 → 规则引擎判断 → 触发动作或存储 → 告警/命令下发/API通知。这条链路里最需要设计的是统一数据模型和规则引擎。统一数据模型指的是平台内部定义一套标准化的消息结构不管设备是MQTT还是私有TCP接入的进了平台之后都转换成同样的结构。比如{ deviceId: dev_001, timestamp: 1716800000000, type: telemetry, data: { temperature: 36.5, humidity: 62.3, switch: 1 } }规则引擎收到这个统一模型后就不需要关心原始协议差异了。定义统一模型的价值在接入设备类型多的时候会特别明显——新增一种设备协议时只需要写一个对应的编码器把它转换成统一模型即可规则引擎和存储层完全不用动。4.1 规则引擎的三种实现思路按场景选规则引擎是物联网平台里的大脑但实话说很多项目根本用不上专业的规则引擎产品。我按复杂度从小到大整理三条路大家按需取用。方案一代码硬编码判断。设备量少、规则简单比如温度超过80度就告警时直接在消费Kafka的service里写if判断就完了。好处是逻辑直观、调试方便、性能最好坏处是每次改规则都要改代码发版。适合规则长时间不变的场景。方案二表达式引擎。如果规则经常需要调整可以用Aviator、QLExpress这类轻量级表达式引擎把规则配置在数据库里平台启动时加载进来。比如数据库里存一条规则data.temperature 80 data.humidity 30规则引擎解析这条表达式然后执行。这种方式支持动态加规则但是复杂逻辑比如连续三次超阈值才告警需要额外写脚本支持。方案三专业规则引擎Drools。当规则量大、规则之间有优先级冲突、需要复杂的Fusion推理时Drools是Java阵营的老牌选择。但它的问题是学习曲线陡峭、调试困难、性能开销大。我的观点是物联网平台的告警规则大部分用方案二就能解决除非你要做的是复杂的业务规则编排比如设备联动、跨设备条件的组合否则别上Drools给自己找麻烦。我自己的项目里默认用方案二规则定义用JSON格式保存在数据库规则引擎消费Kafka消息后逐条匹配。下面是一个规则配置的JSON示例{ ruleId: rule_001, name: 高温告警, condition: data.temperature 80, actions: [ { type: alarm, level: critical, message: 设备温度过高 }, { type: webhook, url: https://example.com/notify } ] }规则引擎的核心代码逻辑就是解析条件表达式 → 匹配数据 → 命中后执行动作列表。这个流程用Aviator实现的话核心代码量非常小而且上线后规则改动只需更新数据库里的一条JSON记录不用发版运维体验很好。4.2 设备影子平台和设备之间的状态缓存设备影子是物联网平台里一个很实用但容易被忽视的概念。它解决的核心问题是平台可能随时需要获取设备的最新状态但设备不一定能立即响应比如设备处于休眠状态或网络不通。设备影子的做法是平台维护一个设备期望状态和设备上报状态的缓存。设备上报的状态实时更新到reported中平台下发的配置先更新到desired中设备重新上线后对比desired和reported的差异主动拉取需要执行的配置。这其实就是给每个设备加了一个JSON文档存到Redis里{ deviceId: dev_001, reported: { temperature: 36.5, firmware: v1.0.3 }, desired: { firmware: v1.0.4 } }设备影子带来的好处有两个一是平台应用的读取逻辑变简单了直接读影子即可不用去猜测设备是否在线二是命令下发有了缓冲设备离线期间平台下发的指令不会丢重新上线后可以自动补拉。在Java落地时我推荐用Redis的Hash结构存设备影子Key为device_shadow:{deviceId}字段为reported和desired这样读取和局部更新都很方便。4.3 告警风暴怎么压设备量到一定规模后一定会遇到告警风暴。想象一下某个工厂停电几百台设备同时离线每台设备各自触发设备离线告警告警中心瞬间被刷屏。这里我分享三个经验。第一同一设备同类型告警做去重。用Redis存一个告警去重KeyKey包含设备ID和告警类型设置过期时间为N分钟N分钟内同一设备同类型告警只推一次。第二告警聚合。多个设备同时告警时将告警消息聚合成一条批量告警而不是几百条独立告警。第三告警升级策略。告警不必每次都通知到人可以做分级严重告警立即推送一般告警累积后定时推送摘要。这三层过滤做完告警中心的消息量至少能下降80%。5. 开源项目选型对比与二次开发的关键决策如果团队不打算从零自研那选择一个合适的开源Java物联网平台作为基座是更务实的路线。目前社区里比较活跃的Java系开源物联网平台我列一下我用过的主要几个横向对比一下。项目协议支持核心优势适用规模二次开发难度JetLinksMQTT、HTTP、TCP、CoAPJava系、功能全面、中文社区活跃中小规模中等ThingsBoardMQTT、HTTP、CoAP国际化、可视化组件丰富、规则链可视化中小规模中等偏高IoTDB 自研平台需自实现接入存储分析能力强、适合工业场景深度定制大规模较高FastBeeMQTT、HTTP轻量、适合单品智能硬件小规模较低JetLinks是我个人用得比较多的一个它是纯Java技术栈基于Spring Boot Netty构建设备接入、产品管理、规则引擎、可视化大屏都有对二次开发很友好。ThingsBoard的优势在前端可视化规则链编排适合不想写太多代码的团队但它的核心框架偏重改造内部逻辑时成本会高一些。选型时还有几个容易忽视的点看项目的GitHub更新频率和Issue处理速度一个社区半死不活的项目即使功能再全也不要选看协议扩展的难度你现场的设备是否支持MQTT如果不支持接入自定义TCP协议的接口是否开放这两个问题直接在GitHub上搜issue或者翻文档就能知道答案看是否支持集群部署不要被单机Demo迷惑生产环境必须支持水平扩展不然设备量上来后只能推倒重来。5.1 开源协议的边界商用前必须搞清楚这块必须要单独拎出来提醒一下。开源不等于免费商用不同开源协议对商用和二次开发的要求完全不同。Apache 2.0协议最宽松可以商用、可以修改、可以闭源发布GPL协议则是传染性协议用了GPL代码的项目衍生作品也必须开源AGPL协议更严格即使通过远程网络提供服务也可能被视为发布衍生作品商用要特别小心。选用Java物联网平台时一定要去项目主页确认它的开源协议。有些项目是开源版商业版双轨制开源版用的协议可能是GPL或AGPL商业版才是Apache 2.0。如果公司内部用GPL影响相对可控但如果你的平台是给第三方客户交付的SaaS服务AGPL会很麻烦商用前最好请公司法务或者咨询开源软件律师确认合规边界。5.2 二次开发里我遇到的三个坑基于开源平台做二次开发有一些坑是我实际踩过之后才领悟到的。第一个坑是升级困难。改过底层代码后上游项目一旦发布新版本合并代码会变得极其痛苦。建议的做法是尽量通过扩展机制插件、配置、独立微服务来开发新功能不要去改核心源码。如果确实要改把改动最小化并详细记录升级时才有回旋余地。第二个坑是过度依赖前端可视化。很多物联网开源项目的可视化大屏做得很漂亮拖拖拽拽就能生成图表但图表背后往往隐藏了查询性能问题。设备量大了以后大屏的每分钟刷新会变成数据库的灾难。我建议可视化部分尽量走独立的查询服务加缓存层不要让大屏直接查业务数据库。第三个坑是盲目追求自定义规则引擎。我用过两个开源平台内置的规则引擎虽然看起来功能强大但实际用起来配置复杂、排查困难。后来我把这些平台自带的规则引擎都绕过去直接用自己用Aviator写的轻量规则服务代码量少、运行逻辑完全可控、出问题也好定位。有时候不那么强大但足够简单的组件才是真正省心的。5.3 自研还是选开源决策框架这个问题的标准答案永远是看情况。我给一个相对实用的决策框架如果项目核心价值在于数据分析和业务逻辑设备接入只是基础能力那就用开源平台做底座把精力投在上层业务上如果项目本身就是靠多协议接入能力打差异化比如你要接入一堆全世界奇怪的工业设备和私有协议那核心能力在接入层开源平台的接入层未必灵活到能满足你这时候自研接入层整合开源存储分析组件反而更合适。还有一个折中路线也可以考虑用JetLinks这类开源平台做接入和管理自己写一套轻量级的业务服务通过它的API和事件订阅机制对接。我最近一个项目就是这么干的设备接入、数据汇集、基础管理全部交给JetLinks上层业务用Spring Boot MyBatis-Plus写了一套单独的BFF服务两边通过平台开放的Webhook和API沟通开发速度很快升级开源平台时也不用担心影响业务代码。6. 上线后最容易被忽视的JVM与性能问题上一节聊了选型和架构这一节来说说平台真正跑起来之后的性能问题。物联网平台的流量特征和普通Web应用完全不一样——它不是由用户在页面上的点击驱动的而是由设备自动上报驱动的流量模型是持续的、潮汐式的、且可能瞬间暴涨。这种流量特征下JVM参数和线程池的配置如果没调好平台会以各种诡异的方式崩溃。我遇到最多的三类问题分别是连接数暴涨导致的堆内存溢出、线程池排队导致的延迟飙升、以及消息积压引发的连锁故障。逐个拆开讲。6.1 连接数暴涨先从线程模型说起用Netty做接入服务时很多人对线程模型理解不深导致配置不合理。Netty的Reactor模型里Boss线程负责接受连接Worker线程负责处理IO读写。默认配置下Boss线程组1个线程、Worker线程组是CPU核数乘2。如果设备连接数超过Worker线程的承载能力新连接的建立就会变慢数据读写吞吐下降。生产环境里如果你用的是Linux服务器Netty默认使用Epoll模型性能已经很好了一般不用改线程数。真正要注意的是连接空闲超时和半开连接检测。设备网络不稳定时TCP连接可能是假死状态——服务端以为还连着设备实际已经断网。解决办法是设置ChannelOption.SO_KEEPALIVE为true同时配合IdleStateHandler超过N秒没有读写就主动关闭连接。6.2 从一条OOM日志看起热词里有java: outofmemoryerror: insufficient memory这个报错我见过太多次了。它经常出现在设备高峰上报时段服务进程突然挂掉日志里只有一行OOM。排查这种问题我建议按下面的顺序来先看是堆内存溢出还是堆外内存溢出。如果是java.lang.OutOfMemoryError: Java heap space多半是堆内存存量数据超过-Xmx配置或者代码里有对象没释放。如果是Direct buffer memory那是堆外直接内存耗尽Netty在处理高并发时用了大量DirectByteBuffer但-XX:MaxDirectMemorySize配置太小。如果是unable to create new native thread那是操作系统级别的线程数耗尽要么是应用创建了太多线程要么是服务器ulimit限制太小。# 线上排查OOM先抓堆dump和GC日志 jstat -gcutil pid 1000 jmap -dump:live,formatb,fileheap.hprof pid拿到堆dump后用MAT或者JProfiler分析优先看堆中占比最大的对象是什么。在我排查的案例里经常发现是因为设备消息对象里有个字段是byte[]设备一多累积的消息对象没及时释放堆就爆了。这类问题的解决办法通常不是调大堆内存而是优化消息对象的生命周期比如把消息的byte[]提前转成基本类型用完即置空让GC能及时回收。6.3 线程池和消息积压的一对矛盾规则引擎消费Kafka消息时线程池参数配错了会产生一个很隐蔽的问题线程数配得太少消费速度跟不上Kafka积压越来越多线程数配得太多频繁的线程切换反而拖慢处理速度同时堆内存压力增大。线程池到底配多少合适业界有一个经验公式但实际要按场景调整。如果是CPU密集型任务比如大量计算、规则匹配线程数建议设为CPU核数1如果是IO密集型任务比如处理完成后要写数据库、调外部API线程数可以设为CPU核数×2。如果你的规则引擎里既有计算又有IO那就把它拆成两个线程池避免互相干扰。另一个容易被忽略的是拒绝策略。默认的AbortPolicy在线程池满时会直接抛异常导致消息丢失CallerRunsPolicy会把任务推回调用线程执行虽然不丢消息但有阻塞消费的风险DiscardOldestPolicy会丢掉最旧的数据对物联网遥测数据来说反而可以接受。我的习惯是遥测数据管道用DiscardOldestPolicy旧数据丢了就丢了新数据才重要但告警和命令管道必须用有界队列加CallerRunsPolicy保证重要消息至少被处理。6.4 定位线上问题的几个实战工具Java平台排查问题有一个天然优势诊断工具链非常完善。我在线上排障时必用的工具有四个Arthas阿里巴巴开源的Java诊断工具用于在线查看方法调用栈、动态调整日志级别JFRJDK Flight Recorder用于录制JVM运行数据定位CPU飙高和内存分配热点jstat和jmap用于快速查看GC情况和堆内存使用Arthas的watch命令配合Kafka消费者的业务日志能快速定位消息链路中哪个环节耗时最长。有一次线上告警延迟很高我用Arthas的trace命令定位到规则引擎里一个JSON序列化方法耗时异常点开发现是某条告警消息的data字段里塞了一个超长的JSON数组序列化耗时飙升。后来给这个字段加了长度限制问题直接解决。没有Arthas这种工具这种问题定位起来会非常费劲。最后说几句实在话写了这么多其实最核心的建议就一个别一上来就研究技术细节先把架构和价值链路想清楚。Java生态里做物联网平台不缺组件、不缺开源项目、不缺资料缺的是对设备接入后到底要做什么的清晰认知。我在选型、搭建、排障的过程中走过不少弯路上面这些内容基本就是我踩坑之后留下的精华。如果大家刚开始接触Java物联网平台我的建议是先拿JetLinks或者ThingsBoard跑通一条完整链路——从设备模拟、MQTT接入、数据展示到告警触发——把整体流程在脑子里建立起来再去思考哪些部分需要定制、哪些部分可以复用。等到真正开始自研或者二次开发时再回头看我上面写的这些架构和性能细节会有完全不同的体会。