店小秘架构升级：订单写入延迟降至120毫秒

2026 年 5 月 9 日，店小秘完成订单服务架构升级。写入与查询链路拆分后，订单写入 P99 延迟从 310 毫秒降至 120 毫秒，历史订单检索的平均响应时间缩短 44%。

随着客户店铺数量增长，订单表的数据量快速上升。旧架构在同一张表上同时承担写入与复杂查询，遇到大促或批量导出时互相影响。架构团队从 2026 年 1 月开始分阶段改造，先拆链路，再迁移历史数据。

拆分思路与迁移过程

新架构把订单写入与查询分成两条链路，写入链路只做校验、幂等与落库，查询链路通过异步索引构建多维度视图。订单按店铺与时间分区，冷数据归档到独立存储，减少主表扫描。

迁移采用双写与灰度读，先对 5% 的店铺开启新链路，对比 14 天数据一致后再扩大。整个过程没有停止服务，历史订单按批次迁移，迁移进度与差异在控制台可查。

“写入和查询混在一起，任何一次导出都会影响下单，拆分是迟早的事。”—— 沈一帆，店小秘技术负责人

升级后的指标

订单写入 P99 延迟从 310 毫秒降至 120 毫秒，批量导入 1 万单的耗时从 96 秒降到 41 秒。历史订单检索平均响应从 1.8 秒降到 1.0 秒，缩短 44%。数据库 CPU 峰值下降 27%。

在大促演练中，新架构在 6 倍日常订单量下保持稳定，队列积压时间比旧架构减少 58%。财务对账任务的执行窗口也缩短了 12 分钟。

“双写灰度跑了十四天，确认一致才敢放量。”—— 方启，店小秘订单架构师

对卖家的实际影响

卖家感知最明显的是批量操作更快：批量改价、批量发货与批量导出都不再拖慢日常订单处理。多店铺切换时的列表加载也更稳定，减少了等待与重复点击。

后续将把同样的分区策略应用到商品与库存服务，并优化跨店铺查询。团队提醒卖家无需手动操作，升级已在后台完成。

订单服务架构升级已完成全量切换，卖家无需操作。如遇个别历史订单检索异常，可在客户端提交工单。后续架构优化将覆盖商品与库存服务。