我接手过不少物联网相关的项目也见过太多伪智能的售货机方案——所谓智能就是给传统机器加了个二维码支付完了还得站在原地等它慢悠悠出货。今天这篇聊的是一个真正让用户取货即走的架构设计SpringBoot做业务中台MQTT做设备控制通道把下单、出货、回执、扣款这一整条链路改造成实时闭环。这套思路不止适用于售货机共享充电宝、无人货柜、自助洗衣房这些设备控制场景都能直接套用。1. 为什么取货即走必须用MQTTHTTP轮询撑不起设备控制1.1 传统售货机的体验瓶颈到底在哪拆开看传统售货机的用户动线扫码打开小程序选商品支付成功然后机器收到后台指令开始出货用户隔着玻璃盯着货道螺旋弹簧转确认东西掉下来了才离开。问题出在第三步和第四步之间——支付成功到机器启动出货中间隔着一层平台-设备的通信延迟。早期方案是让售货机每隔几秒去服务器拉取一次待执行指令这叫短轮询。设备多起来之后麻烦就来了200台设备、5秒轮询间隔平均每秒就有40个HTTP请求打在后台其中绝大多数是没有新指令的空响应。更麻烦的是延迟不可控运气差的时候设备刚轮询完空结果后台正好落了新指令用户就得再等一个轮询周期体验直接拉垮。1.2 HTTP短轮询在设备场景的三个致命伤第一个是实时性差。轮询间隔设短了后台扛不住设长了设备响应慢这是一个无解的矛盾。第二个是真连接和假连接的问题——HTTP是请求响应模型没请求的时候服务器压根不知道设备还活着设备断网半小时后台完全无感。第三个是功耗售货机还好说内嵌4G模块的共享设备大多靠电池供电每多一次无效轮询就多耗一次电。这时候引入MQTT就顺理成章了。MQTT是长连接协议客户端售货机主动连上Broker链路保持不断。服务器要下发出货指令往对应的Topic一发设备端实时就收到了延迟从秒级压到毫秒级。而且Broker天然维护了连接状态设备离线了能立刻感知这就解决了心跳探测的难题。1.3 MQTT的发布订阅模型和售货机场景的契合点MQTT的核心是主题订阅加发布生产者和消费者完全解耦。后台不需要知道设备IP不需要维护设备连接状态只管往Topic里发消息设备只管订阅自己的Topic收到指令就干活。这个模型对售货机场景有三个直接好处设备动态上下线不影响业务。新装一台售货机插电联网后自动订阅指令Topic和上报Topic后台不需要写死设备地址。天然支持广播和点对点。给单台设备下指令就往device/{deviceId}/cmd发给所有设备发升级通知就发broadcast/upgrade。离线消息靠QoS机制兜底。设备断网期间积压的指令等它重连后Broker会按会话继续推送避免漏指令。当然MQTT也不是银弹。它只管消息传输不管设备具体执行什么逻辑。真正的取货即走还需要后端把订单流程、指令回执、超时重试这些编排好这把重头戏在SpringBoot这边。2. 核心架构拆解一条订单从手机滑到货道电机要走多少关2.1 系统里四个角色和各自的职责边界整个售货机系统分成四层我从下往上梳理一遍设备端售货机主控板通常是STM32或者ESP32控制货道电机、读传感器、管理制冷压缩机。它对上只有一个需求——能收指令、能上报状态。接入网关这是设备连接互联网的关键一环。多数售货机主板上没有联网能力需要外挂一个4G DTU或者WiFi模组这个模组里跑着MQTT客户端。设备主板通过串口TTL/RS485把业务数据交给DTUDTU负责封装成MQTT消息发到云端。消息Broker用EMQX或者Mosquitto都行。它负责维护海量设备连接按Topic路由消息处理心跳和离线状态。SpringBoot应用这就是业务中台。接收小程序的下单请求、调用支付预授权、通过MQTT下发指令给指定设备、监听出货回执、确认扣款、处理异常单。这里面容易被人忽略的是网关层。很多人以为售货机直接跑MQTT实际上工业设备大多还是串口思维主控板和通信模组之间靠AT指令或者Modbus协议对话数据到网关之后才转成MQTT报文。理解这一层后面讲485设备通信就好说了。2.2 取货即走的一次完整业务闭环我把取货即走的时序拆开一关一关过用户在小程序扫码看到该设备的库存和价格提交订单。SpringBoot收到下单请求先做预授权冻结额度或者信用评估生成待出货订单。SpringBoot把订单号、货道号、出货数量打包成JSON发布到device/dev001/cmdTopic同时把订单状态改为已下发。售货机通过DTU实时收到消息主控板驱动对应货道的螺旋电机转一圈商品掉进取货口。货道下方的红外传感器检测到商品通过计数信号主控板把出货结果成功/卡货/缺货上报到device/dev001/reportTopic。SpringBoot订阅到回执消息根据订单号匹配到原始订单更新状态为已出货然后执行真正的扣款。用户直接伸手取货走人全程不需要站在机器面前干等。这个链路的巧妙之处在于支付和出货是分离的。传统模式是先扣款再出货用户付了钱机器却卡货时体验极差。取货即走模式是先授权、后出货、再扣款出货成功才真正扣钱天然解决了卡货纠纷。当然这对系统的回执可靠性要求更高如果设备出货了但后台没收到回执就会出现货出了钱没扣的问题所以后面章节的状态机和超时兜底很关键。2.3 Topic设计命名规范决定了后续维护的幸福感Topic设计看似简单实际是项目里最容易返工的地方。一旦业务跑起来线上有几百台设备在订阅再改Topic名就是灾难。我推荐一套经过验证的规范Topic模式用途示例device/{deviceId}/cmd下发给单台设备的指令device/dev001/cmddevice/{deviceId}/report单台设备上报的实时状态device/dev001/reportdevice/{deviceId}/heartbeat设备心跳报文device/dev001/heartbeatbroadcast/upgrade全量设备固件升级通知broadcast/upgradebroadcast/announce系统公告、时间同步broadcast/announce约定几条硬规则Topic按设备维度拆不要混用指令和上报分属不同Topic避免互相干扰设备ID全部转小写且提前校验格式防止脏数据污染路由。这个规范定下来之后增删设备就是纯粹的配置不需要改代码。3. SpringBoot接入MQTT的工程细节客户端选型、配置参数和消息路由3.1 选型直接上Eclipse Paho还是套Spring Integration MQTTSpringBoot整合MQTT社区里主要有两条路。一条是用Eclipse Paho的Java客户端自己封装连接管理、消息回调和重连逻辑另一条是用Spring Integration MQTT模块它把MQTT客户端包装成了Spring的消息通道可以跟MessagingGateway、ServiceActivator这些注解无缝衔接。我的建议是追求快速落地且团队熟悉Spring生态用Spring Integration省事对连接细节要求高、需要精细控制重连和线程模型直接Paho更灵活。我自己的项目最终选了Paho原因是我们需要手动管理消息确认和离线缓冲Spring Integration那层封装反而有点隔靴搔痒。有一点必须强调无论选哪种都别把MQTT客户端直接写成单例Bean就用。要处理好重连时的幂等、回调线程池的隔离、以及客户端ID的唯一性这些细节决定了线上稳定性。3.2 核心配置项和连接参数的心得先看基于Paho的SpringBoot配置类核心代码这个是我在项目里沉淀下来的版本Configuration public class MqttConfig { Value(${mqtt.broker.url}) private String brokerUrl; Value(${mqtt.client.id}) private String clientId; Value(${mqtt.username}) private String username; Value(${mqtt.password}) private String password; Bean public MqttClient mqttClient() throws MqttException { // clientId必须全局唯一重复会导致Broker把旧连接踢掉 MqttClient client new MqttClient(brokerUrl, clientId, new MemoryPersistence()); MqttConnectOptions options new MqttConnectOptions(); options.setCleanSession(false); options.setAutomaticReconnect(true); options.setConnectionTimeout(10); options.setKeepAliveInterval(30); options.setUserName(username); options.setPassword(password.toCharArray()); // 遗嘱消息设备异常断线时Broker帮我们广播离线状态 options.setWill(device/ clientId /status, offline.getBytes(), 1, true); client.connect(options); return client; } }这里几个参数的实际经验我展开讲讲。cleanSession设为false非常关键它告诉Broker这个客户端离线期间的QoS 1以上消息要保留等重连后再推给它。售货机出货指令如果在设备断电瞬间到达有了这个机制设备恢复供电后还能补收到不至于丢单。代价是Broker要为每个离线客户端缓存消息所以生产环境要根据设备规模和离线时长评估Broker内存。keepAliveInterval设30秒意思是客户端每30秒发一次心跳Broker超过60秒没收到心跳就判定连接断开。这个值改小了会增加无效流量改大了离线检测就不及时。售货机场景30秒比较平衡。再就是自动重连。设备侧网络经常漂移4G信号切换、运营商重置连接没有自动重连就连回来。setAutomaticReconnect(true)之后SDK内部会处理重连时序但注意重连成功之后需要重新订阅Topic这一步有必要放在连接回调里做。client.setCallback(new MqttCallback() { Override public void connectionLost(Throwable cause) { // 记录日志告警等待自动重连 } Override public void messageArrived(String topic, MqttMessage message) { // 消息路由后面细说 } Override public void deliveryComplete(IMqttDeliveryToken token) { // QoS 1的确认回调 } });3.3 消息处理别在回调线程里做业务这是新手最容易踩的坑。Paho的消息回调是在客户端内置线程里执行的如果在messageArrived里直接查库、调接口、处理耗时的业务逻辑会阻塞后续所有消息的消费。设备规模一大消息处理延迟会肉眼可见地升高。我处理的办法是回调里只做两件事把消息按Topic分拣然后丢进一个独立的消息处理线程池。业务逻辑全在线程池里执行回调线程立刻返回保证MQTT消息消费不阻塞。Bean public ThreadPoolTaskExecutor mqttMessageExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(4); executor.setMaxPoolSize(8); executor.setQueueCapacity(1000); executor.setThreadNamePrefix(mqtt-msg-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; }这个线程池的参数不是拍脑袋定的。核心线程4个处理常规的上报消息足够队列1000是缓冲区应对设备集中上报的峰值拒绝策略用CallerRunsPolicy宁可让回调线程自己慢一点处理也不能把消息丢掉。还有一点小提醒SpringBoot对异步任务的支持很完善建议在线程池上配合Async注解使用把消息处理逻辑拆成独立Service代码会清爽很多。4. 出货指令与回执确认状态机和超时重试是取货即走的信任基石4.1 指令报文协议设计设备端不关心JSON的层次结构有多优雅它关心的是报文简单、好解析、不容易出错。我用的指令格式设计如下{ msgId: ORDER20240515001, type: DISPENSE, payload: { slotNo: 3, quantity: 1 } }字段说明msgId是全局唯一的消息ID用来关联回执type是指令类型DISPENSE表示出货payload里的slotNo是货道号quantity是出货数量。一条指令一个消息消息体控制在1KB以内避免设备端解析大报文浪费时间。这里有个设计取舍为什么不直接把订单号当作Topic的一部分因为订单号是动态的Topic应该是稳定的设备标识订单号放在消息体里更合理。设备收到出货指令后执行完成上报回执时需要带上msgId后台靠它找回订单完成闭环。4.2 回执超时怎么办状态机里的三个关键状态设备收到指令到上报回执中间隔着电机运行时间、传感器检测时间、网络上传时间理论上三五秒就能完成。但现实是可能电机卡住、商品被卡在货道半空、设备断网重连中——这些异常都可能导致后台迟迟等不到回执。这里必须有一个订单状态机我把核心状态定义如下状态含义触发条件PENDING订单已创建等待下发用户下单成功DISPATCHED出货指令已发到MQTT消息发送成功DELIVERED已收到出货成功回执设备上报成功FAILED出货失败设备上报失败TIMEOUT超时无回执超过阈值未上报转换逻辑不复杂但有个细节值得注意DISPATCHED状态出现后要立刻启动一个定时任务做超时检测。这个任务不是简单扫一次订单表就完事而是分前后台两层配合。后台用延时任务或者用Redis过期键监听在60秒后检查订单是否还停在DISPATCHED——如果是说明回执丢了此时发起补单查询向设备发一条QUERY_STATUS指令问它到底出没出货。设备端回复DELIVERED或FAILED再据实更新订单。4.3 重复回执的幂等保护出货成功是个敏感事件它直接关联扣款。如果设备因为网络重传把同一条成功回执发了两遍后台不做幂等保护就会扣两次款这是绝对不允许的。幂等策略很简单用msgId做唯一约束。上报消息进入处理逻辑前先去Redis里查这个msgId是否存在存在就说明处理过了直接丢弃不存在就正常处理然后写Redis并设置过期时间。这一步在生产里救了我很多次。不只是重复回执MQTT在QoS 1下本身就存在消息重复投递的可能协议设计上就默许了可以重但不能丢所以应用层必须自己处理幂等这是IoT消息架构的通用常识。5. 实际集成中容易被忽略的场景MQTT如何给485设备发指令5.1 售货机内部的RS485总线和Modbus协议前面提过售货机主控和传感器之间经常用RS485总线连接。RS485是半双工串行通信标准特点就是传输距离远、抗干扰强特别适合工业现场。一台售货机内部可能有多个货道控制板、温控板、称重传感器它们挂在一条485总线上每个设备有独立的Modbus地址。有朋友问过MQTT怎么给485设备发指令——这其实是一个链路的整合问题。MQTT和485是完全不同层级的通信方式MQTT跑在TCP/IP网络层485是物理层的串行总线。中间的桥接靠的是通信网关也就是前面说的DTU。链路是这样SpringBoot通过MQTT把出货指令发给网关网关收到后把MQTT报文解开转成Modbus-RTU帧通过485总线发给目标地址对应的货道控制板。货道控制板驱动电机完成出货。执行结果的反馈走相反路线从485设备到网关再封装成MQTT上报消息回传。5.2 网关层指令转换的关键逻辑网关程序通常是C语言或者嵌入式Lua脚本核心就是做协议转换。比如后端发来一条DISPENSE指令payload里有货道号3网关要把货道号映射为Modbus寄存器地址和值然后组装一条Modbus写指令帧。这里有个很实际的坑不同售货机厂商的485地址映射规则不一样。A厂商的货道3在Modbus上可能是寄存器1002B厂商可能就是寄存器1010。所以网关层需要维护一张映射表或者更优雅的做法是后端在MQTT下发指令时直接携带网关侧已经映射好的物理寄存器信息让网关做纯粹的转发即可。我在项目里选择的是后端下发语义指令、网关做地址翻译的模式。好处是业务侧不用关心设备厂家的差异换设备型号只改网关配置SpringBoot代码一行不用动。5.3 串口并发和总线仲裁的注意事项485总线是半双工的同一时刻只能一个设备说话所以网关在轮询多个控制板时要注意总线仲裁。出货指令通常是单播的出问题的是状态轮询多个Modbus设备如果同时应答总线上就会发生数据碰撞解析出来的数据全是乱码。解决办法是网关统一调度所有485请求走一个队列串行执行每次请求等到超时或者应答回来才发下一个。这个限制是硬件层面的应用层没法绕过但设计时心里有数消息处理超时就要把重试时间预留够。我这边实际经验是网关程序给485请求设置800毫秒超时轮一遍20个设备耗时不到2秒完全在可接受范围内。6. 线上跑起来才知道的坑连接互踢、消息积压和离线误判6.1 clientId重复导致设备互相踢下线MQTT协议规定Broker上同一个clientId只允许一个连接存活。如果两个设备配了相同的clientId后连上的会把先连上的踢掉两个设备就开始反复抢连接。售货机批量部署时配置模版的clientId字段如果写死了某个固定值几百台设备上线后就会发生大乱斗表现为设备频繁离线上线后台告警刷屏。排查这个问题的思路值得分享一下。现象是设备每几分钟掉线一次查Broker日志发现client already connected再一查设备配置果然所有DTU配的clientId都是同一个默认值。修复很简单clientId用设备唯一标识通常是设备SN号或者MAC地址并且在固件烧录时就要保证唯一性。6.2 QoS 1消息积压导致的重连风暴有一次线上事故让我印象很深刻。某天凌晨一批设备因为网络割接全部离线挂了一个小时。等网络恢复几百台设备同一时间重连Broker而Broker为每个离线客户端缓存了离线期间的心跳消息和指令消息瞬间消息洪峰打过来SpringBoot的消息处理线程池扛不住任务队列全部占满新消息被拒绝处理。事后复盘暴露了两个问题。第一个是没有做分批发重连控制设备重连是瞬时并发的没有抖动需要网关增加随机延时让设备在1到5分钟内随机重连。第二个是Broker端的离线消息缓冲设得太大大量过期的心跳报文没必要保留合理设置消息过期时间把无效积压消掉。SpringBoot这边也做了调整消息处理线程池增加了队列容量同时加了背压保护当队列积压超过阈值时主动丢弃非关键的消息类别比如过期心跳消息保证出货回执这类关键消息优先处理。6.3 心跳超时的误判问题设备心跳是判断在线状态的重要依据但心跳超时不一定代表设备真的离线。4G网络有短暂抖动一次心跳丢失很常见。如果后台一收到心跳超时就判定设备离线就会误报一堆故障单。我的处理是分级判定连续3次心跳丢失才标记为疑似离线然后主动发一条ping指令如果连续几次都没有任何回包才真正更新设备为离线状态。这个策略大大降低了误报率也避免了一惊一乍的告警。另外辅以遗嘱消息兜底。MQTT的遗嘱机制是设备异常断线时Broker自动发布的最后一条消息。设备连接时设置了will消息断线后Broker帮我们把设备状态标记为offline这是比心跳超时更快、更准确的离线感知方式。两种机制配合使用设备在线状态的准确性高很多。7. 一些额外的经验稳定性调优和性能参考最后分享几个数据供参考。我的项目里单台SpringBoot应用同时管理3000台左右在线设备消息吞吐峰值在每秒200条左右8核16G的实例CPU利用率稳定在30%上下。这个体量下问题的瓶颈往往不在应用本身而在于Broker和数据库的读写频率。库存扣减是一个容易忽视的性能点。每台售货机都有几十个货道每次出货成功都要更新库存。直接用MySQL更新的话频繁的设备上报会产生大量行锁竞争。我的做法是先把库存变更通过MQTT内部Topic转成异步消息落到Redis里做预扣减再由一个批量任务定时把Redis的变更同步回MySQL。这样既保证了响应速度又不会把数据库压垮。还有很多细节值得展开比如指令下发时的消息回溯、多Broker节点的集群部署、以及设备端固件远程升级的MQTT通道设计。每一块单独拿出来都能写一篇长文。不过核心思路就一条把每台售货机当成一个通过MQTT接入的数字化终端SpringBoot负责把业务编排、状态管理、兜底重试这些脏活累活都扛下来用户侧才能做到真正的取货即走。这套架构搭好之后再扩容新设备、接入新机型工作量都集中在设备和网关适配后端基本不用大改这也是我用了这么久最满意的地方。