Peter Lab

总结了这些月迁移系统的经历，用比较不恰当的比喻。:)

大背景: 争战

产品类型: 常规，多规格，组合产品，买赠，赠品，邮寄产品，套餐产品。

活动类型: 拼团，砍价，定金膨胀。均是单独下单，单独记录，只可下普通品，扩展时都需要字段 新增。

快速扩张的活动售卖，无法满足。

统一 (产品)

问题: 邮寄产品，买赠，套餐产品，组合产品当时设计为一种独立的产品类型。

那么不同的产品类型之间 就无法叠加，比方说买赠就无法邮寄，组合无法买赠;

代码中的分支判断越来越多，越来越复杂， 难以维护。

目标: 简化产品线:

• 将邮寄作为一种送达方式
• 买赠作为活动
• 套餐下线
• 组合，赠品作为活动 — 多规格将作为属性

变法 (优惠与活动)

问题: 优惠和活动没有统一处理和存储，类型和优惠存储分散。有字段歧义。瀑布式判断。

目标: 统一的活动定义，统一存储，采用策略，统一分发不同的优惠处理。

繁荣 (性能)

问题: 订单量增⻓极快，2020年六月gmv同比翻1倍到4亿，急需将下单流程优化

经过:

• 去年618和1111前对下单流做过几次优化，
• 包括重新梳理逻辑顺序，优化查询，库存校验，多线程同步，线程池异步，消息队列等。

革命 (下单)

问题: 后占库模式致使的超售退款，限时限量等活动的增多，参与活动完成却买不到货的等。 新订单系统 仍然受到业务线的局限，有跨业务线的下单需求，如购物⻋，预售券搭售日历房等。

目标:

• 新的库存系统:统一下单时即预占库存。
• 新的交易平台:跨业务线，集中处理优惠与活动。
• 预售单只作为基础产品订单。单品，多规格，买赠等开始迁移到交易订单下单。

大未来:共同富裕

问题: 多规格设计为一种大产品和若干子产品，平级存放在产品表。下单时生成一个大产品订单和对应的 小产品订单。这种打平的设计，在代码实现中增加了很多层级查找。由于没有约定的不好，现在有 些交互用大产品，有些交互则用小产品，特别容易混淆出错。 组合产品被设计为一种高于普通产品的产品类型，存放在另一张产品表，具有独立的产品信息，下 单接口与表，结算，奖励等都是独立的。

目标:

• 规格作为sku出现在产品的下层，对应大p订单不再存在。
• 组合产品成为一种活动出现在产品上一层。预售订单。