软件系统公司揭秘：手机当扫码枪的小程序，如何通过API网关扛住高并发扫码？
在零售和仓储行业摸爬滚打这十来年，我们团队交付过不少扫码相关的软件系统。最近一两年有个明显的变化：越来越多的客户不想再花大价钱采购专门的PDA扫码枪了，而是希望直接用店员自己的手机，或者配发的普通智能手机，跑一个小程序就能完成入库、盘点、收银核销。这思路没错，一部手机成本不到专业设备的三分之一，而且系统升级推送比固件刷机省事太多。
但问题也随之而来。上个月我们去一家华东的连锁便利店做技术巡检，他们的IT负责人直接倒苦水：门店搞满减活动，高峰时段十几个收银台同时用手机小程序扫码，后台接口直接雪崩，订单重复提交，数据库CPU飙到100%。说实话，这种场面我们见得太多了。手机当扫码枪看似只是前端多了个输入方式，背后的并发压力远超很多人的想象——专业扫码枪一般走串口或私有协议，吞吐可控；而手机小程序是基于公网的HTTPS请求，一旦营销活动带来脉冲流量，没有缓冲层就是灾难。
我们作为深耕行业多年的软件系统服务商，今天干脆揭个秘：我们给客户落地“手机扫码枪”方案时，是怎么用API网关稳稳接住高并发的。
先说手机端本身。很多人以为小程序调个 wx.scanCode 就行，其实那个API会中断当前页面跳转到扫码UI，不适合连续扫。我们在项目里改用 camera 组件实时取帧，在本地用开源解码库把条码解析成字符串，再通过 request 把纯编码 POST 给后端。这一步就极大减少了传输体积，一个扫码请求 payload 不到200字节，比传图片或者走默认扫码插件轻量得多。
重点在后端架构。我们绝不会让小程序直接连业务数据库。在客户端和微服务之间，必须架一层 API 网关。我们目前主推的方案是基于 Kong 做二次开发，加上自研的限流与聚合插件。
这里有几个实战细节，值得拿出来掰扯。第一是鉴权，小程序每次发起扫码请求，网关要校验其中的 openid 和门店 token，防止有人抓包后恶意刷接口。第二是精细化限流，不是全局限流，而是按“门店ID 设备指纹”做令牌桶。比如单店允许突发每秒300次扫码，平时50次，超出部分网关直接返回友好提示而非穿透到后台。第三是热点缓存，像商品条码和名称的对应关系，网关层接了 Redis，扫码后如果命中直接返回基础信息给前端，不用每次查库。第四是请求合并，我们在网关写了个短暂缓冲（比如10毫秒窗口），把同门店的多个扫码打包成批量校验请求发给后端服务，这样后端的数据库写入压力能降七成。
去年双十二，我们支撑的一个社区生鲜客户，当天上午抢购时段手机小程序扫码峰值达到1.2万 QPS。监控大屏上网关平均延迟稳定在40毫秒左右，后端订单服务毫无波动。客户后来跟我们说，以前用专业设备都没这么顺滑过，因为老设备根本不支持这种弹性架构。
当然，网关不是万能银弹。手机本身的摄像头在弱光下解码率会掉，我们建议在小程序里加了手电筒自动开启和对焦优化；另外网关背后的业务服务也要做幂等设计，避免网络重试导致重复入账。
如果你所在的企业也正打算把手机变成扫码枪，别只盯着前端那个小程序页面。找一家懂高并发架构的软件系统公司，把 API 网关这层地基打牢，系统才能既省钱又靠谱。我们在这行踩过的坑，希望变成你们的捷径。
微信号：18581869297
