一、真正的复杂度不在“功能”而在“组合”很多系统失败不是因为功能不够而是因为功能一旦组合就失控在电商中一个看似简单的下单过程实际包含多种营销叠加优惠券 / 积分 / 会员价 / 活动价多状态流转支付 / 取消 / 发货 / 售后多写操作订单 / 库存 / 资金 所以问题本质是如何在“组合复杂度”下仍然保持系统可控二、订单系统从“数据表”到“受控状态流”1️⃣ 为什么订单系统一定要用状态机大多数低质量实现用一个 status 字段随意修改 这会导致状态错乱已取消还能支付并发冲突多次更新无法追溯2️⃣ 正确模型有限状态机FSM订单应被建模为一组受约束的状态 合法迁移路径状态定义示例CREATED已创建 PAYING支付中 PAID已支付 DELIVERING履约中 FINISHED完成 CANCELLED已取消状态迁移核心约束CREATED → PAYING → PAID → DELIVERING → FINISHED ↓ ↓ CANCELLED TIMEOUT3️⃣ 工程实现关键点✔ 状态迁移必须“显式定义”boolean canTransit(State from, State to) 避免非法状态变更逻辑分散✔ 幂等控制必须有支付回调场景重复通知网络抖动解决唯一订单号状态校验✔ 状态变更必须具备“原子性”更新订单状态 → 再扣库存常见错误 正确方式核心操作同一事务或通过事件驱动4️⃣ 本质总结订单系统不是“存数据”而是“控制流程”三、营销系统规则引擎设计的真正难点1️⃣ 为什么 if-else 一定会失败典型代码if (coupon) {...} if (points) {...} if (vip) {...}问题规则顺序不可控无法组合无法扩展 当规则数量 5 时系统必然失控。2️⃣ 正确抽象规则引擎模型LikeShop 的核心思路是把营销能力从“代码逻辑”抽象为“规则系统”Rule规则 Condition条件 Action执行 Priority优先级 Constraint约束基本结构3️⃣ 真正的难点规则选择问题不是执行问题在一次下单中可能存在多张可用优惠券多种活动叠加互斥规则 本质问题如何在约束条件下找到“最优优惠组合”4️⃣ 工程解法核心算法思想❗ 不能做全量穷举复杂度O(2^n) 直接不可用✔ 实际策略LikeShop思路Step 1规则分层商品级订单级用户级Step 2优先级排序强约束规则优先高权重规则优先Step 3逐步计算贪心 局部最优逐层应用规则动态调整价格Step 4约束校验是否可叠加是否冲突 核心目标在可接受复杂度内得到“足够优”的结果5️⃣ 为什么必须统一计算入口很多系统的问题商品页算一套购物车算一套下单再算一套 结果价格不一致用户投诉无法排查正确设计所有价格计算必须进入统一 Price Engine特点输入一致输出一致可追踪四、订单 营销的耦合问题真正复杂的地方在于订单系统依赖营销结果而营销计算依赖订单上下文 典型循环依赖订单金额 → 影响优惠优惠结果 → 影响订单金额解决方案分阶段计算Step1基础价格计算 Step2应用营销规则 Step3生成最终订单金额 Step4锁定计算结果 原则一旦下单完成价格不可再变五、最终一致性与性能的平衡营销 订单会带来高计算成本高并发压力LikeShop 的策略✔ 计算前置在下单前完成✔ 缓存中间结果减少重复计算✔ 下单时只做“确认操作” 目标把复杂计算从“写链路”移出六、核心结论电商系统的扩展性不取决于是否微服务是否分布式而取决于✔ 订单是否可控状态机✔ 营销是否可扩展规则引擎✔ 计算是否一致统一入口✔ 复杂度是否被收敛最后电商系统的难点从来不在“功能实现”而在“如何让复杂规则长期可控”。总结LikeShop 通过状态机与规则引擎将电商系统的组合复杂度转化为可控计算问题从而实现高扩展性与长期可维护性。LikeShop 的设计目标不是一次性解决所有问题而是在控制复杂度的前提下支撑电商业务的持续增长与架构演进。