从深夜崩溃到架构重构：我的 WMS 系统技术实现血泪史

去年夏天最热的一个周末，仓库里闷得像蒸笼，我蹲在电脑前，屏幕上是Excel表格里密密麻麻的SKU。盘点已经折腾了三天，库存还是对不上——账面显示有500件A类商品，实际货架上只找到423件。客户催单的电话一个接一个，我脑子里嗡嗡作响，恨不得把电脑砸了。

当时我就想：这破系统，到底哪里出了问题？

TL;DR： 从Excel到自研WMS，我踩过的技术坑能绕仓库三圈。今天聊聊闪仓WMS的技术架构设计——单体应用为什么是中小企业的噩梦，微服务怎么让系统扛住双11流量，以及数据库选型背后的血泪教训。

为什么我决定自己写代码？

说实话，一开始我也买过市面上的WMS系统。但那些系统要么贵得离谱，要么功能太冗余——我一个百来平的小仓库，根本用不上什么自动化分拣、AGV调度。更气人的是，数据都在别人的服务器上，想导出来做个自定义报表，得求爷爷告奶奶。

后来我做了个大胆的决定：自己写一套WMS。当时团队就两个人——我和一个刚毕业的实习生。我们用Python搭了个单体应用，数据库用的SQLite。刚开始还挺顺，订单量小，每天处理几百单没问题。但好景不长，当订单量突破每天2000单时，系统开始频繁卡死。

^[1] 根据Fortune Business Insights的报告，全球WMS市场正在快速增长，但中小企业往往被昂贵的方案拒之门外。我们决定走开源和自研的路，至少数据在自己手里。

有一天下午，一个仓管员扫码入库时，系统突然崩溃了。我打开日志一看——数据库连接池耗尽，因为并发查询太多。更糟的是，由于是单体架构，订单模块的bug直接导致整个系统瘫痪，连库存查询都做不了。

当时我就想：如果换成分散的服务，至少订单挂了，库存还能查。

那次崩溃之后，我决定重构。把整个系统拆成四个核心服务：订单服务、库存服务、用户服务、报表服务。每个服务独立部署，用Docker容器跑在云服务器上。

迁移过程堪称噩梦。数据要拆分、接口要重新定义、服务间通信要用REST还是gRPC？我们纠结了好久。最后选了gRPC，因为性能好，但调试起来真的想骂人。

^[2] 根据Mordor Intelligence的分析，微服务架构在仓储系统中越来越普及，但迁移风险不容忽视。我们花了整整两个月才把核心流程跑通。

第一次上线微服务版本时，库存服务调订单服务的接口超时了，导致用户下单后库存没扣减，结果超卖了50单。第二天客服被客户骂惨了。

后来我们引入了消息队列（RabbitMQ），用异步方式处理库存扣减。订单生成后发个消息到队列，库存服务慢慢消费。虽然实时性差了几秒，但再也没出过超卖。

最开始用SQLite，因为它简单，一个文件搞定。但当数据量超过50万条SKU时，查询慢得像蜗牛。每次做库存报表，我得等十分钟。

后来换了MySQL，性能好了不少，但并发写入时经常死锁。有一次盘点时，两个人同时修改同一个SKU的库存，直接导致数据不一致，账面和实物差了80件。

最后我们选了PostgreSQL，支持行级锁、高并发、还能做地理空间查询（虽然我们用不上）。迁移数据又是三天三夜没合眼。

^[3] 根据Grand View Research的报告，选择合适的数据库是WMS系统性能的关键。PostgreSQL在复杂查询和并发控制上确实强于MySQL。

即使换了PostgreSQL，高频查询还是扛不住。比如实时库存查询，每个页面刷新都要查一次数据库。后来我们引入了Redis缓存，把热点SKU的库存放在内存里，查询速度从200ms降到了2ms。

但缓存也有坑——数据一致性。有一次缓存更新延迟，前台显示有货，实际已售罄，导致客户下单后无法发货。

系统后端再牛，前端不好用，仓管员一样骂娘。我们最初用jQuery写了个后台管理界面，丑得没法看。后来换了Vue.js，配合Element UI，界面清爽多了。

移动端用Flutter开发，支持Android和iOS。扫码功能用手机摄像头，不需要额外买PDA。一开始扫码识别率只有80%，后来优化了图像处理算法，识别率提升到99%以上。

根据艾瑞咨询的调研，移动端WMS应用在中小企业中渗透率快速提升，但用户体验仍是最大痛点。我们特别注重扫码的流畅性，因为仓管员每天要扫上千次。

从Excel到自研WMS，从单体到微服务，从SQLite到PostgreSQL——这条路走得真不容易。但看到现在系统稳定运行，每天处理上万订单不出错，仓管员用手机扫码就能完成入库出库，我觉得值了。

要点回顾：

中小企业别盲目上大系统，自研或开源WMS更灵活

单体应用适合日单量<5000，超过就要考虑微服务

数据库选型要谨慎，PostgreSQL比MySQL更适合复杂查询

缓存和消息队列能大幅提升性能，但要注意数据一致性

前端体验很重要，移动端扫码是刚需