SpringCloud Alibaba无人售货柜实战（一）：项目整体架构设计——设备端、小程序、后台、微服务拆分
扫个码就能开门拿东西，关个门就自动扣钱——这台柜子背后到底藏了多少套系统？今天掰开揉碎给你讲明白。
一、项目背景：无人售货柜是个啥
传统自动售货机是"投币/扫码→选商品→机器弹出商品"的逻辑，结构复杂、故障率高、补货麻烦。无人售货柜换了个思路：扫码开门→自由拿取→关门自动结算，本质就是把"货柜"变成了"迷你无人超市"。
核心交互流程：
- 用户用微信小程序扫描柜体上的二维码
- 柜门弹开，用户自由拿取商品
- 用户关上柜门
- 系统通过重力传感器/RFID/视觉识别判断拿了什么
- 自动从用户微信支付中扣款
这套流程看着简单，背后涉及设备控制、实时通信、商品识别、订单结算、支付对接等多个技术域，是一个典型的IoT+微服务综合项目。
二、整体架构：四端协同
整个系统分为四端，各司其职：
| 端 | 技术 | 职责 |
|---|---|---|
| 设备端 | RK3588 Android工控板 | 柜门控制、商品识别、状态上报 |
| 小程序端 | 微信小程序 | 扫码开柜、订单展示、支付授权 |
| 后台管理 | Vue3 + ElementPlus | 设备管理、商品管理、数据看板 |
| 微服务后端 | SpringCloud Alibaba | 业务逻辑、数据持久、消息通信 |
2.1 分层架构总览
从上到下分为五层：
┌─────────────────────────────────────────────┐ │ 接入层（客户端） │ │ 微信小程序 │ Vue后台管理 │ 设备端App │ ├─────────────────────────────────────────────┤ │ 网关层（Gateway） │ │ SpringCloud Gateway + JWT鉴权 │ ├─────────────────────────────────────────────┤ │ 服务层（微服务集群） │ │ 设备服务│商品服务│库存服务│订单服务│支付服务 │ │ 用户服务│统计服务 │ ├─────────────────────────────────────────────┤ │ 中间件层 │ │ Nacos(注册配置)│Redis(缓存)│RocketMQ(消息) │ │ Seata(分布式事务)│Sentinel(限流)│MinIO(存储) │ ├─────────────────────────────────────────────┤ │ 数据层 │ │ MySQL(业务数据，每服务独占库) │ └─────────────────────────────────────────────┘三、微服务拆分策略
微服务拆分的核心原则：按业务领域拆，不按技术功能拆。每个服务独占数据库，通过接口通信，避免跨库Join。
3.1 七大微服务
| 服务名 | 职责 | 核心表 |
|---|---|---|
| device-service | 设备注册、心跳、指令下发 | device, device_command |
| product-service | 商品CRUD、分类管理 | product, product_category |
| stock-service | 库存管理、变动日志 | stock, stock_log |
| order-service | 订单创建、状态流转 | order, order_detail |
| pay-service | 微信支付、退款回调 | payment, payment_refund |
| user-service | 用户登录、地址管理 | user, user_address |
| stats-service | 销售统计、数据看板 | 从各服务同步数据 |
3.2 为什么这么拆
- 设备服务独立：设备通信是高频IO操作，MQTT长连接，和业务逻辑解耦
- 库存服务独立：库存扣减是高并发热点，需要独立扩容
- 订单和支付分离：支付有回调延迟，不能阻塞订单流程
- 统计服务独立：统计是读密集型，可以独立做读写分离
四、技术栈选型
4.1 后端技术栈
| 类别 | 技术 | 选型理由 |
|---|---|---|
| 框架 | SpringBoot 3.x | Java 17+，性能提升明显 |
| 微服务 | SpringCloud Alibaba | 国产生态，文档友好 |
| 注册中心 | Nacos | 注册+配置二合一 |
| 网关 | SpringCloud Gateway | 响应式，性能优于Zuul |
| 限流降级 | Sentinel | 接口级限流，熔断降级 |
| 分布式事务 | Seata | AT模式，对业务侵入小 |
| 消息队列 | RocketMQ | 支持事务消息，适合订单场景 |
| 缓存 | Redis 7 | 设备状态缓存、分布式锁 |
| 数据库 | MySQL 8 | 分库存储，每服务独占 |
| ORM | MyBatis-Plus | 代码简洁，分页插件好用 |
4.2 设备端技术
设备端是整个项目的"手和眼"，技术选型很关键：
- 主控板：RK3588 Android工控板，八核A76+A55，支持8路摄像头，跑Android 12
- 通信方式：MQTT协议长连接，EMQX作为Broker
- 柜门控制：串口（Serial）控制电磁锁，Android通过串口API发送开锁指令
- 商品识别：视觉方案（YOLOv8模型）+ 重力传感器双校验
4.3 小程序端
- 框架：原生微信小程序（性能优先，不上Uni-app）
- 扫码：
wx.scanCode扫描柜体二维码 - 实时状态：WebSocket连接网关，接收开柜/关门/结算结果推送
- 支付：微信支付JSAPI，先签约免密代扣再扣款
4.4 后台管理
- 框架：Vue3 + Vite + TypeScript
- UI：ElementPlus
- 权限：RBAC模型，动态路由菜单
- 图表：ECharts，设备分布地图+销售趋势看板
五、数据流走向
以"用户扫码开柜→拿商品→关门结算"为例，完整数据流：
用户扫码 │ ▼ 小程序 → Gateway网关(JWT鉴权) │ ▼ order-service: 预创建订单(状态=OPENING) │ ├─ Feign调用 device-service: 下发开柜指令 │ │ │ ▼ │ device-service → MQTT → 设备端 → 电磁锁开门 │ ├─ WebSocket通知小程序: 柜门已开 │ ▼ (用户拿商品...关门) │ 设备端 → MQTT → device-service: 上报关门+识别结果 │ ▼ order-service: 更新订单明细，计算总价 │ ▼ pay-service: 调用微信支付扣款 │ ├─ 支付成功 → order-service: 订单状态=PAID │ └─ WebSocket通知小程序: 支付成功，展示账单六、项目里程碑规划
| 阶段 | 内容 | 产出 |
|---|---|---|
| P0 | 基础设施搭建 | Nacos/Gateway/公共模块 |
| P1 | 设备接入 | 注册+心跳+指令通信跑通 |
| P2 | 核心业务 | 商品+库存+订单+支付 |
| P3 | 用户端 | 小程序扫码全流程 |
| P4 | 后台管理 | Vue后台+数据看板 |
| P5 | 上线优化 | 压测+Sentinel限流+灰度发布 |
七、小结
无人售货柜项目本质是一个IoT设备控制 + 微服务业务处理的双线作战项目。设备端管"物理世界"，微服务端管"数字世界"，中间靠MQTT这座桥连通。架构设计阶段最关键的是微服务拆分粒度——拆太粗失去意义，拆太细调用链爆炸。本文的七服务拆法是经过实战验证的平衡点，既保证业务清晰，又不会过度设计。
