企业官网建设流程全解析

随着DIY手工消费场景的快速普及，拼豆作为低门槛、高可玩性的手工项目广受年轻群体欢迎，传统拼豆店存在人工成本高、营业时间受限、客流高峰结算慢等痛点，无人自助拼豆系统依托物联网、移动支付技术实现24小时无人值守运营，降低运营成本的同时提升用户消费体验。本文将从架构选型、核心功能实现、硬件对接、部署全流程展开，分享完整的落地开发实战经验。

整体技术架构选型与设计思路

无人自助拼豆系统属于典型的物联网软硬件一体化系统，需要同时支撑C端用户操作、B端运维管理、硬件终端实时通信三类需求，结合同类无人共享系统的成熟落地经验，终确定如下技术栈：

• 后端服务：采用Spring Boot + MyBatis Plus + MySQL 构建，Spring Boot的自动配置能力可大幅提升开发迭代效率，MyBatis Plus简化多表CRUD操作，MySQL存储订单、用户、库存、设备等核心业务数据，同时引入Redis实现缓存、过期事件监听、分布式锁等能力。
• 用户端：采用Uniapp（基于Vue语法）开发，支持一键打包为小程序、H5、APP多端产物，用户无需下载应用，直接扫码即可进入操作页面，符合无人自助场景的轻量化使用需求。
• 管理后台：采用Vue + Element UI 构建，页面组件成熟度高，运维人员上手成本低，可快速实现门店管理、设备监控、数据统计等功能。
• 物联网通信层：采用EMQX作为MQTT消息 broker，支撑设备与服务端的低延迟通信，满足电控锁控制、称重数据上传、心跳保活等实时性需求。

整体架构分为三层：用户交互层负责对接消费者与运维人员，服务层负责业务逻辑处理、数据存储、硬件指令调度，终端层负责执行开门、称重、信号上传等硬件操作，各层解耦设计，便于后续功能迭代与硬件扩展。

核心功能模块的实现逻辑

系统核心功能分为用户端消费流程、拼团优惠、管理后台运维三类，核心实现逻辑如下：

用户自助消费流程

用户扫码后首先触发身份校验，首次使用需完成授权，校验通过后服务端生成请求ID，通过MQTT下发开门指令，用户打开料仓门取拿对应颜色的拼豆，料仓底部的称重模块实时上传重量数据，服务端通过防抖算法计算终取豆重量，用户关门后自动按预设单价计算金额，触发免密支付完成结算，全程无需人工干预。

拼团优惠模块

针对拼豆高频消费用户，支持多人拼团享受优惠，核心逻辑基于Redis过期回调实现：用户发起拼团后，系统生成拼团记录存入MySQL，同时在Redis中写入带过期时间的key（过期时间为拼团有效期），有效期内其他用户可加入拼团，到期后Redis触发过期事件监听，系统自动校验拼团人数，满足成团条件则自动给所有参与用户发放优惠抵扣券，未成团则自动给已支付用户原路退回费用。核心代码示例如下：

// 监听Redis过期key，处理拼团到期逻辑@ComponentpublicclassGroupBuyExpireListenerextendsKeyExpirationEventMessageListener{@AutowiredprivateGroupBuyServicegroupBuyService;publicGroupBuyExpireListener(RedisMessageListenerContainerlistenerContainer){super(listenerContainer);}@OverrideprotectedvoiddoHandleMessage(Messagemessage){Stringkey=newString(message.getBody());// 只处理拼团相关的过期keyif(key.startsWith("group_buy:expire:")){StringgroupId=key.split(":")[3];GroupBuygroup=groupBuyService.getById(groupId);// 拼团待生效状态则校验成团条件if(group!=null&&group.getStatus()==GroupBuyStatus.PENDING){intjoinCount=groupBuyService.getJoinCount(groupId);if(joinCount>=group.getTargetCount()){// 成团：发放优惠groupBuyService.activeGroup(groupId);}else{// 未成团：自动退款groupBuyService.cancelGroup(groupId);}}}}}

管理后台运维功能

核心包含门店管理、库存预警、设备监控、数据统计四个模块：库存预警通过定时任务每分钟拉取所有料仓的称重数据，低于预设阈值时自动给管理员发送站内通知；设备监控模块实时展示所有终端的在线状态、电压、信号强度，设备离线超过2分钟自动触发告警；数据统计模块支持按日/周/月维度统计销售额、拼团成功率、热门拼豆品类等数据，为运营决策提供支撑。

物联网硬件对接的关键实现

硬件对接是无人自助系统的核心难点，主要需要解决指令可靠传输、称重数据防抖、设备状态管理三个问题：

指令可靠传输

所有硬件指令采用MQTT QoS1级别传输，服务端下发开门、校准等指令时生成指令ID，设备收到指令后返回ACK确认，服务端5秒内未收到ACK则自动重试，多重试3次，重试失败则给用户返回操作失败提示，避免指令丢失导致的用户体验问题。

称重数据防抖

由于用户取拿拼豆时可能产生晃动，导致称重数据波动，服务端采用滑动窗口算法校验数据稳定性：连续3次上报的重量差小于0.1g时才认定为终重量，以此过滤抖动数据，避免计费误差。核心代码示例如下：

// 处理设备上报的称重数据@MqttListener(topic="device/+/weight/report")publicvoidhandleWeightUpload(Stringtopic,Stringpayload){StringdeviceSn=topic.split("/")[1];WeightReportVOreport=JSON.parseObject(payload,WeightReportVO.class);// 取当前料仓近3次上报的重量数据List<Double>recentWeights=weightRecordMapper.selectRecentWeight(deviceSn,report.getBinId(),3);recentWeights.add(report.getWeight());// 校验数据稳定性：值与小值差小于0.1g则判定为稳定Doublemax=Collections.max(recentWeights);Doublemin=Collections.min(recentWeights);if(max-min<0.1){// 更新料仓库存，计算取豆重量DoublelastWeight=stockService.getBinLastWeight(deviceSn,report.getBinId());DoubleuseWeight=lastWeight-report.getWeight();if(useWeight>0){orderService.updateUseWeight(report.getOrderId(),useWeight);}}}

设备状态管理

所有终端每30秒上报一次心跳数据，包含在线状态、料仓重量、电压、信号强度，服务端将心跳数据存入Redis，超过2分钟未收到心跳则标记设备为离线，触发告警通知运维人员排查。

全链路部署实操指南

系统部署分为环境准备、后端部署、前端部署、硬件调试四个步骤，通用可执行流程如下：

1. 基础环境准备：服务器配置建议2核4G及以上，操作系统采用CentOS7.9，依次安装JDK1.8、MySQL8.0、Redis6.x、EMQX4.4、Node14.x，MySQL需开启binlog用于数据备份，Redis开启过期事件监听支持，EMQX开启客户端认证避免非法设备接入。
2. 后端服务部署：拉取后端代码后修改application.yml配置文件，配置数据库连接、Redis连接、MQTT连接、小程序/支付相关参数，通过Maven执行mvn clean package打包为jar包，上传至服务器后通过systemd托管运行，配置Nginx反向代理后端8080端口，挂载SSL证书实现HTTPS访问。
3. 前端部署：管理后台拉取Vue代码后修改生产环境API地址，执行npm install安装依赖，npm run build打包生成dist目录，上传至服务器Nginx静态资源目录配置路由即可；用户端Uniapp项目修改API地址与小程序APPID，选择对应平台打包，小程序端上传代码至公众平台提交审核，H5端直接部署至Nginx静态目录即可。
4. 硬件调试：给终端设备配置MQTT broker地址、端口、设备SN，通电后查看EMQX后台确认设备在线，依次测试开门、称重、结算、拼团全流程，验证数据一致性与指令可靠性，后模拟100并发请求做压力测试，确认系统稳定性后即可上线运营。

该系统架构具备较强的通用性，仅需修改料仓参数、计费规则即可适配自助零食、自助手工材料、自助五金配件等多个无人称重场景，后续可扩展AI视觉识别能力，通过摄像头识别用户取拿的拼豆品类，与称重数据做双重校验，进一步降低计费误差风险。