从RPC框架到离线缓存：手机当扫码枪小程序在无人仓环境中的高可用设计实践
把手机当成工业扫码枪用，这主意听起来像降本增效的PPT里的噱头，但我们真在无人仓里跑通了。作为这个项目的技术负责人，我得说一句：从RPC框架选型到离线缓存设计，每一步都是被现实抽着耳光学出来的经验。
做仓储数字化这几年，我踩过不少坑。尤其是去年在华东一个客户现场落地无人仓项目时，为了压低成本，团队拍板用安卓手机加微信小程序替代传统扫码枪。初衷很美好：手机遍地都是，摄像头像素比扫码枪还高，开发个小程序就能跑。可真到了仓库里，才发现高可用这件事，远比写个demo要复杂得多。
仓库环境你懂的，铁皮货架一排排，AP点位覆盖总有死角。工人拿着手机走到角落，信号格直接掉到零。传统扫码枪用的是专网或者批处理方式，而我们小程序一开始依赖的HTTP短连接，在弱网下基本歇菜。每次扫码发起一个HTTPS请求，超时设个3秒，结果工人扫一笔等半天，盘点效率直接腰斩。后来我们复盘，决定把通信层推倒重来，引入了一套轻量级的RPC框架思路。
这里多说一句，小程序里跑不了原生TCP，但我们利用微信的WebSocket能力，封装了一层基于二进制的RPC协议。后端接的是我们自己改过的服务网格，服务发现走内部的名字服务。这样做的好处是，长连接保活，扫码请求封装成RPC调用，序列化用Protobuf，包体比JSON小了将近70%。最关键的是，我们在客户端实现了RPC的超时熔断和本地重试队列——网络闪断时，调用不立即失败，而是挂起在内存里，等链路恢复立马重发。这招在无人仓的过道里特别管用，工人根本感知不到网络抖动。
但光有RPC还不够。去年双十一压测，我们模拟了整个仓断网半小时的极端情况。这时候RPC的重试队列会爆内存，而且工人不能停工作业。于是离线缓存方案被提上日程。我们在小程序侧用IndexedDB（微信里是本地数据库能力）开了个持久化队列。扫码动作首先写本地日志，生成带时间戳和唯一UUID的作业记录，然后异步触发同步任务。这里头有个细节：仓库作业多是按单据维度，我们给每个单据加了状态机，离线时只允许追加扫描明细，不允许修改已提交数据，保证最终一致性。
上线后真遇过事故。有回机房交换机环路，核心服务不可达将近四十分钟。但现场六个小组用手机照常拣货，本地缓存了三千多条扫码记录。网络恢复后，客户端启动补偿协程，批量推送给后端，通过幂等接口去重，全程零差错。后来复盘，这种“离线优先”的设计，其实暗合了CAP里对分区容忍的妥协——我们牺牲了强一致，换来了仓库不停摆。
当然，高可用不只在代码层。我们在小程序里埋了硬件调用兜底：如果RPC连续失败，界面直接变灰并本地播报“已存本地”，避免工人怀疑手机坏了。监控侧也接了实时埋点，离线队列长度超过阈值就告警，运维能提前介入。有意思的是，传统扫码枪方案要是中心服务挂了，整条线就得停；而我们这套架构，本质上把决策权下放到了边缘设备，手机不再是哑终端，而是具备一定自治能力的节点。
折腾大半年，这套“RPC 离线缓存”的组合拳，在三个无人仓跑下了日均二十万扫码量，SLA维持在99.95%以上。回头看，把手机当扫码枪不是噱头，背后这些弯弯绕绕的可靠性设计，才是真正值钱的经验。如果最近你也在做类似轻量化改造，我的建议是：别迷信单一协议，把离线当成常态去设计，系统才活得久。
微信号：18581869297
