从软件系统商视角：剖析手机小程序替代扫码枪的WebSocket实时架构实战
我们公司主要是做仓储物流和零售数字化的，说白了就是帮客户把线下的货、人、场用软件串起来。这两年有个明显的趋势，不少仓管客户跑来问：你们能不能把扫码枪干掉，用大家口袋里的手机，跑个微信小程序，扫条码就能入库出库？这需求背后全是算盘声——一把工业扫码枪少说四百块，易丢易坏，手机可是员工标配。
但作为软件系统提供方，我们得泼点冷水：手机摄像头扫码精度其实不差，难点在“实时”二字。传统扫码枪为什么好用？它跟终端之间是硬连接（串口或蓝牙RFCOMM），扫一下，本地立刻有回执，几乎零感知延迟。手机小程序跑在微信环境下，底层是浏览器内核，想做到近似体验，靠传统的HTTP接口轮询（polling）肯定完蛋。我们早期在一个零售盘点项目里试过3秒轮询，服务器QPS直接飙到上万，小程序端还老是串数据。后来架构评审时我们CTO拍桌子：必须上WebSocket，没有商量余地。
从我们软件系统公司的架构视角看，这套“手机变扫码枪”的方案，核心是一张轻量但健壮的实时通信网，而不是简单调个相机API。
先说整体拓扑。小程序作为WebSocket客户端，通过WSS（WebSocket over TLS）连到我们部署在云上的API网关，网关背后不是业务Tomcat，而是一组用Netty写的WebSocket集群节点。这么做的原因很实际：业务系统（比如WMS、ERP）不需要直接hold住海量长连接，否则内存分分钟爆炸。Netty节点只负责连接管理和消息转发，收到小程序发来的扫码事件（通常是JSON片段，含taskId、code、timestamp、deviceId），立马推送到Redis Pub/Sub或者Kafka主题里，后端消费者服务再去落库和做业务逻辑。这种分离让我们在华东一个冷链仓的项目里，单节点轻松撑住5万并发设备，业务系统那边完全无感。
连接生命周期是我们踩过坑的地方。微信小程序的WebSocket API在切后台时会被系统挂起，这是操作系统级的限制。我们就在小程序端做了“可见性监听”，一旦onHide就主动发心跳暂停帧，onShow重新鉴权握手。鉴权这块，我们强制每次连接带JWT，并且服务端做单次会话绑定，防止码被截胡。心跳间隔设的15秒，服务端18秒无包就断连，释放资源。断线重连用了指数退避，避免风暴。这些参数不是拍脑袋，是我们交付组在客户现场用真机测了一周调出来的。
扫码数据的传输模式，我们设计成“端到边缘，边缘到中心”。手机扫出码后，小程序不先调业务REST接口，而是直接通过已建立的WebSocket通道发二进制帧（我们自定义了1字节头标识类型，后面跟protobuf，体积比JSON小一半）。这样做延迟极低，4G网下从扫到服务端收到平均70ms。服务端Netty节点收到后，除了发往消息队列，还会针对同一个盘点任务的工作站PC（也开了WebSocket）进行实时广播，这样办公室的大屏马上就能看到“张三刚扫了A12货架”。这种全双工推模式，才是手机能代替枪的灵魂。
弱网是仓库常态。地库或者金属货架旁信号差，小程序端的WebSocket容易假死。我们的做法是小程序侧用IndexedDB做个本地待发队列，扫码动作照常存本地，连上了就按顺序补传。服务端对每条码做幂等键（deviceId timestamp code哈希），重复推也不怕。这个细节是我们在实际交付中加班两天才补上的，客户后来特别满意，说这比他们原来的枪还稳。
安全方面，别以为内网小程序就安全。我们见过有人用伪造证书抓包，所以全站WSS是底线，且Netty层做了空闲违例封IP。码内容后端必须校验格式，防止有人塞个SQL片段进来。
总结一句，手机代替扫码枪不是炫技，背后的实时架构才是真功夫。我们作为系统开发商，建议各位技术负责人在规划时，把长连接基础设施和业务解耦，留好扩展位。毕竟，让手机像枪一样快，用户才会忘记它只是部手机，而你们老板才会真正看到TCO（总拥有成本）掉下来。这套架构我们跑了一年多，历经双十一峰值考验，欢迎同行拍砖交流。
微信号：18581869297
