获课：shanxueit.com/9499/

已完结项目复盘：面向未来，重构电商商品中心技术方案

去年这个时候，我所在的团队刚刚完成了一场历时四个月的“手术”——电商商品中心技术方案全面重构。项目完结复盘会上，看着屏幕上那张从“蜘蛛网”变成“梳子”的架构图，我心里涌上来的不是成就感，而是一种劫后余生的庆幸。今天不聊具体代码实现，单从个人视角，聊聊这次重构背后那些让我刻骨铭心的思考、争执和认知转变。

一、为什么要重构？不是技术债，是业务已经“跑不动”了

很多技术人一提重构就兴奋，觉得终于可以扔掉历史包袱、用上最新框架了。但我们启动这个项目的理由非常“庸俗”——老系统已经撑不住业务了。

商品中心是电商的中枢，所有商品信息的上架、编辑、查询、分发都要经过它。老系统是五年前单体架构时期建的，那时候SKU（库存量单位）总量才几十万，如今膨胀到近千万级。更致命的是，业务方这些年不断提出新需求——多维度属性搜索、智能推荐标签、实时价格策略、区域差异化展示——每一个新需求都在老系统上“打补丁”。到后来，一个商品上架请求要经过十多个过滤器和拦截器，改了A逻辑，B莫名其妙报错，开发同学戏称这是在“雷区里跳舞”。

重构的核心理由从来都不是“技术太烂”，而是“业务预期和技术现状之间的鸿沟已经无法靠修修补补来弥合了”。 这是我在项目启动会上反复强调的一句话，也是说服管理层投入资源的关键论据。

二、重构最大的难点，不在技术，在“切流”

说实话，技术方案的选型、新模型的建模、存储层的迁移，虽然复杂，但都是有章可循的。真正让我夜不能寐的，是 “怎么把流量从老系统平滑地切到新系统，用户和商家完全无感知” 。

我们最终采用的策略是“双写+灰度+校验”：新系统上线初期，所有写请求同时写入老系统和备用表，读请求依然走老系统。接下来逐步灰度读流量——1%、5%、10%、50%，每切一个档次，观察至少24小时。同时，后台有个对账程序，定期对比新老两套系统的数据一致性，发现差异就告警。

这个过程持续了近六周，每一周的灰度都像在走钢丝。我记得切到30%那天，监控突然出现了一波错误日志，我整个人从椅子上弹起来，后来发现是新系统的某个缓存策略把老数据的过期时间算错了，导致部分商品详情页渲染失败。好在灰度开关就在手边，一键切回老系统，十分钟恢复。那次之后我更加坚定了一个认知：重构项目里，最核心的代码不是业务逻辑，而是“开关”和“回滚”的代码。

三、领域模型的重新审视：商品不只是“表”，是“聚合”

新方案里最大的架构调整，是把商品中心从“数据表驱动”的设计，改成了“领域驱动”的设计。听起来很学术，但落到实际，就是一句话：把商品当成一个有机整体来管理，而不是一堆散落在不同表里的字段。

老系统里，商品的基本信息、库存、价格、规格、图片、详情描述，分别存在七八张表里，任何一次商品编辑都要联表更新，事务范围极大，性能堪忧。新方案借鉴了DDD（领域驱动设计）的聚合根思想，把商品作为一个聚合根，所有属性作为聚合内的实体和值对象，一次操作只锁一个聚合，事务边界大大缩小。

但这个过程并不顺利。最激烈的争论发生在“规格和SKU是否应该放在聚合内”这个问题上。一部分人认为规格是商品的核心属性，必须强一致；另一部分人认为规格变化频率低，可以最终一致。我们僵持了整整三天，最后用了一个折中方案：核心规格强一致，扩展属性允许异步补全。这种“取舍”的艺术，我觉得比任何技术选型都更能体现架构师的价值。 什么都想要最强的方案，往往是最糟糕的方案。

四、存储选型的“反直觉”决策：继续用MySQL，而不是换NewSQL

这次重构还有一个决策让我印象很深：我们没有盲目追逐流行的NewSQL或分布式数据库，而是选择了继续用MySQL，但做了垂直分库和水平分表的组合。

原因很朴素：团队对MySQL的运维经验最丰富，出任何问题都能迅速定位和修复。而引入一款新数据库，意味着监控体系要重建、故障处理手册要重写、开发人员的SQL思维要调整——这些隐形成本，远比数据库本身的性能差异更值得关注。

最终方案是：商品主表按商家ID做水平分表，属性扩展表独立成库，历史快照单独归档到冷存储。这套组合拳打下来，单表数据量从千万级降到了百万级，查询性能提升了五倍以上。技术选型的本质，不是比谁更时髦，而是比谁更适合当前团队的“体质”。

五、复盘会上最触动我的一句话

项目完结复盘会的最后，一位跟了全程的测试同学说了一句话，让我至今记忆犹新：“以前每次大促前我都失眠，因为商品中心总会出点幺蛾子。这次618我睡得很踏实。 ”

这句话比任何性能指标、任何架构图都更能说明这次重构的价值。技术方案的优劣，最终不是体现在QPS（每秒查询数）和RT（响应时间）的数字上，而是体现在团队的“安全感”上——业务方不再频繁投诉、开发敢放心改代码、测试不再害怕发版、运维不再半夜被叫醒。

写在最后

商品中心的重构虽然“已完结”，但我很清楚，架构的演进永远不会完结。未来的挑战还会来——AI驱动的个性化商品描述、实时价格博弈、跨域库存共享，每个新需求都可能再次挑战当前的方案。但这次重构让我有了一种笃定：好的架构不是一成不变的蓝图，而是一个能持续吸收新需求、同时保持核心稳定的有机体。

面向未来，我不怕变化，因为我终于学会了怎么“优雅地拥抱变化”。这大概就是这次项目复盘，给我最宝贵的遗产。