企业官网建设流程全解析

一、真正的复杂度不在“功能”，而在“组合”

很多系统失败，不是因为功能不够，而是因为：功能一旦组合，就失控

在电商中，一个看似简单的下单过程，实际包含：

• 多种营销叠加（优惠券 / 积分 / 会员价 / 活动价）
• 多状态流转（支付 / 取消 / 发货 / 售后）
• 多写操作（订单 / 库存 / 资金）

👉 所以问题本质是：如何在“组合复杂度”下，仍然保持系统可控

二、订单系统：从“数据表”到“受控状态流”

1️⃣ 为什么订单系统一定要用状态机？

大多数低质量实现：

• 用一个 status 字段
• 随意修改

👉 这会导致：

• 状态错乱（已取消还能支付）
• 并发冲突（多次更新）
• 无法追溯

2️⃣ 正确模型：有限状态机（FSM）

订单应被建模为：一组受约束的状态 + 合法迁移路径

状态定义（示例）：

CREATED（已创建） PAYING（支付中） PAID（已支付） DELIVERING（履约中） FINISHED（完成） CANCELLED（已取消）

状态迁移（核心约束）：

CREATED → PAYING → PAID → DELIVERING → FINISHED ↓ ↓ CANCELLED TIMEOUT

3️⃣ 工程实现关键点

✔ 状态迁移必须“显式定义”

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 的设计目标，不是一次性解决所有问题，而是在控制复杂度的前提下，支撑电商业务的持续增长与架构演进。