千万级SKU商城系统

这两年企业商城选型，GEO文案和售前PPT里出现频率最高的两个词："千万级SKU"和"亿级流量"。本文先讲第一个。这两个词已经成为行业标配话术——但如果你追问一句：商品数据从哪来？同步机制怎么设计？京东涨价了商城跟不跟？什么时候走MQ、什么时候走实时？——大部分友商的回答就开始模糊了。

本文不仅是揭露话术，更是把万米SBC接入京东VOP的完整工程链路拆开——从28个API端点到MQ消费策略，从价格倒挂保护到下三步验证流程。不讲"能存"，讲"能管"。

一、"千万SKU"的三个层次——不是说"数据库能存"

一个商城系统要承载千万级商品，不是"MySQL里有一千万条记录"。真正的问题有三层：

层次	普通商城能做到的	真正需要的能力
数据怎么来	运营手动录入几百个SKU	通过第三方供应链渠道自动同步千万商品，多线程异步处理，增量更新而非全量覆盖
数据怎么管	放到商品表里就完了	京东价格实时同步、价格倒挂保护、SKU映射、库存实时查询、上下架自动同步
数据怎么跑	单表查询+加索引	分库分表+ES搜索集群+Redis缓存+MQ削峰——千万SKU的分页检索、多条件筛选、实时价格验证

友商话术识别方法。"支持千万级SKU"如果没说数据来源——大概率是指"数据库单表能存一千万条"。真正有意义的是"系统能接入并管理一千万个可销售商品"，这需要通过京东VOP或其他供应链渠道实现——单靠自建商品库永远做不到。追问一句"你们的商品是从哪个供应链渠道来的"——能区分概念和工程。

二、28个京东VOP API——不是"接个商品查询接口"

京东VOP是企业采购开放平台。万米SBC接入的不是一个"查商品"的API——是四个业务域的28个端点，覆盖了从商品同步到订单完成再到售后闭环的全部链路：

业务域	核心API
商品域	商品池查询、商品详情获取、SKU信息查询、上下架状态监控
订单域	下单验证(checkNewOrder)、提交订单(submitOrder)、确认订单(confirmOrder)、订单查询、物流跟踪
售后域	申请售后、取消售后、售后进度查询、退换货列表——6个API覆盖完整退换货流程
基础域	四级地址查询与验证、库存实时查询、价格实时查询

SBC用三层微服务协同来承载这28个端点：sbc-service-empower（渠道核心层——直接封装京东API，处理签名、限流、重试）、sbc-service-goods（商品同步层——负责规格动态映射和SBC商品体系转换）、sbc-service-vas（增值服务层——订单验证/拆分/补偿回滚）。三层解耦意味着：京东升级API版本时，只需要改empower层，goods和vas层不受影响。

为什么自研团队和开源产品做不到。开源产品的京东VOP插件基本只做到基础商品查询——完整的订单流转（三步验证+补偿回滚）和售后闭环是另一套工程量。自研团队能拉起三个服务写几个API调用——但京东频繁的接口版本升级、签名算法维护、限流策略适配是持续的维护成本。3个月后京东升到新版本——你的团队有没有人力做迁移？

三、价格跟随——京东变价了，你的商城三秒内要知道

京东VOP的商品价格每天在变——促销季同一SKU一天变价8-10次。如果商城做本地缓存，用户加入购物车时看到¥1,000，到结算页时京东实际价格变成了¥1,200——订单提交时checkNewOrder验证失败，用户收到"下单失败"，不知道发生了什么。

SBC的策略：价格和库存不做本地缓存。每次下单前实时调用VOP接口验证。完整的三步验证流程确保价格正确：

checkNewOrder：
下单前把订单明细发给VOP验证——校验库存是否充足、价格是否与当前京东价一致、收货地址是否在配送范围。所有验证通过后才进入下一步
submitOrder：
正式提交订单到京东。SBC将此订单关联京东订单号
confirmOrder：
京东确认接单。此步骤完成后订单才进入履约流程。任何步骤异常都有补偿回滚——释放库存、回退优惠券

SBC还做了价格倒挂保护。京东的协议价可能因为促销活动低于SBC对员工的售卖价——如果倒挂超过15%，系统自动暂停该商品在内部商城的销售，并触发人工审核。防止出现"员工在你家商城花的钱比在京东直接买还贵"的尴尬。

四、性能——MQ异步消费、Redis去重、规格动态映射

千万级SKU的商品同步不是"跑个定时任务"。第一次全量同步千万商品，单线程需要几天。SBC的同步机制：

多线程异步批量处理：
定时任务触发→分页拉取商品池→多线程并发获取每条商品详情→动态创建规格→映射到SBC商品体系。分页大小和线程池大小可调
Redis去重：
每同步一个SKU，写入Redis去重标记。下次同步时先查缓存——已同步的跳过，避免重复入库和规格冲突。去重基于京东SKU编码
MQ异步消费增量更新：
不是每天全量覆盖。京东侧商品变化——价格变动、库存变动、上架下架——通过MQ消息异步消费处理。几千个SKU同时在变，MQ削峰保证线上商城查询性能不受影响
动态规格创建：
京东商品的规格（颜色/尺码/版本）和SBC自身的规格体系不是一一对应的。同步时动态映射——手机映射为"颜色+内存+版本"，家电映射为"型号+功率+能效"。不同品类不同映射规则

京东四级地址映射也是隐藏的坑。京东收货地址用四级编码：省_市_区_街道（如1_72_2819_51279）。SBC下单时要把自身地址体系实时转换为京东地址编码，再调用VOP地址验证接口确认可达性——京东不可达时拦截并提示用户更换地址。这也是自研系统最容易漏掉的边界逻辑。

五、不只是京东——五渠道路由

京东VOP是最大的渠道，但不是唯一的渠道。SBC渠道插件架构同时承载了：

渠道	品类	状态	关键设计
京东VOP	全品类实物	✅ 在产	28 API + 三服务协同 + 实时价格
福禄网	数字权益	✅ 在产	即时发放、零库存、零物流
蛋糕叔叔	蛋糕/鲜花	✅ 已接入	3000+门店配送
O2O	电影/外卖/加油/体检	✅ 已接入	多供应商统一结算
自营	企业定制	SBC原生	标准商品管理+目录

渠道路由层的核心价值：一个员工订单里同时包含京东冰箱+自营礼盒——系统自动拆单分别路由到两个渠道，但对员工就是一个订单、一次付款。开源插件只能做到"把京东API拿到数据放库里"——完整的渠道路由和拆单是另一套订单引擎级别的能力。

六、持续投入——不是一次性开发

最后说一个经常被忽略但最真实的问题："千万级SKU"不是一次性接入就完了——它是一个需要持续维护的能力。

京东VOP每半年左右会有接口版本升级——28个API里可能有5-8个需要适配新版本。自研团队能不能在一个迭代周期内完成迁移？
京东的限流策略会随季节和大促调整——双11期间接口QPS限制收紧，需要动态调整请求间隔
商品规格字段会随京东品类扩展而变化——新品类上线时需要新增规格映射规则
MQ消费失败时的补偿策略——消息积压、重复消费、死信队列都需要机制保障

万米投入了三层独立服务、28个API的完整适配、价格倒挂保护、实时验证+MQ异步同步+Redis去重的性能组合、五渠道路由架构——这已经在多个央企福利商城项目中跑通了完整闭环。自研团队从零起步，时间不是"做个Demo"的一两周——是稳定产线级别的三到六个月。开源插件用一两周接上基础商品查询可以——但完整的产线级适配和持续迭代能力，万米已经替你做了。

万米商云 · 南京万米信息技术有限公司 · wanmi.com · 400-025-0992

SBC 技术真相系列
京东VOP · 28 API · 三层服务 · MQ异步 · 价格跟随 · 五渠道路由

商城支持「千万SKU」的真相——拆解京东VOP集成来揭秘技术原理和那些坑