电商系统架构设计：从下单到履约的全链路

电商是最典型的交易型系统：读多写多、链路长、对数据一致性敏感，还要扛得住大促的瞬时洪峰。本文从业务域出发，带你走一遍完整的下单履约链路，并重点分析几个最容易踩坑的技术点。

一、业务域划分

一个成熟电商平台通常按领域拆分为以下核心服务：

领域拆分的原则是高内聚、低耦合：库存归属库存域，订单不直接改库存表，而是通过接口或消息驱动。

二、整体分层架构

flowchart TB
    subgraph Access["接入层"]
        A1["App / H5 / 小程序"]
        A2["开放 API"]
        GW["API 网关：鉴权 · 限流 · 路由 · 灰度"]
    end
    subgraph Biz["业务层"]
        B1["商品"] --- B2["交易"] --- B3["营销"] --- B4["支付"] --- B5["履约"] --- B6["用户"]
    end
    subgraph Mid["中台层"]
        C1["订单中心"] --- C2["库存中心"] --- C3["支付中心"] --- C4["营销中心"]
    end
    subgraph Infra["基础设施"]
        D1[("MySQL 分库分表")] --- D2[("Redis 缓存")] --- D3["MQ 消息队列"] --- D4[("Elasticsearch")] --- D5["配置/注册中心"]
    end
    A1 --> GW
    A2 --> GW
    GW --> Biz
    Biz --> Mid
    Mid --> Infra

• 网关：鉴权、限流、路由、灰度。
• 缓存：商品详情、价格、热点库存放 Redis，挡住大部分读流量。
• 消息队列：订单创建、支付成功、库存变更等事件通过 MQ 异步解耦、削峰填谷。
• 搜索：商品检索走 Elasticsearch，与商品库通过 Binlog 订阅保持同步。

三、下单主链路

一次“提交订单”大致经历以下步骤：

1. 校验：登录态、商品上下架、收货地址、活动规则。
2. 价格计算：实时计算商品价、优惠、运费，生成订单快照（价格以服务端计算为准，绝不信任前端）。
3. 库存预占：锁定库存，设置超时释放。
4. 创建订单：生成订单（待支付状态），写订单库。
5. 发起支付：调用支付渠道，返回支付参数。
6. 支付回调：支付成功后，订单流转为“待发货”，通知履约系统。
7. 履约：拆单、推仓、出库、发货、签收。
8. 售后：退款、退货走逆向链路，库存回补。

订单用状态机管理：待支付 → 待发货 → 待收货 → 已完成，以及 已取消 / 售后中 / 已退款 等分支。每次状态流转都要记录操作与时间，保证可追溯。

四、关键挑战与方案

1. 库存：如何不超卖

超卖是电商最经典的问题。常见手段按精度递增：

• 数据库乐观锁：update stock set available = available - n where sku_id = ? and available >= n，简单但在高并发下行锁竞争激烈。
• Redis 预扣 + Lua 原子操作：大促前把热点库存预热到 Redis，用 Lua 脚本保证“判断 + 扣减”原子性，异步落库。
• 库存分桶：把一个 SKU 的库存拆成多份放在不同 key/分库，降低单 key 热点。
• 预占与回补：下单锁定、支付成功真正扣减；超时未支付由延迟消息触发回补。

2. 订单与支付：幂等 + 最终一致

支付回调可能重复投递，因此所有写操作都要幂等：用业务唯一键（如订单号 + 事件类型）做去重表或唯一索引。

订单、库存、支付跨服务，无法用本地事务，通常采用最终一致性：

• 本地消息表 / 事务消息保证“业务写库”和“发消息”原子；
• 下游消费消息幂等处理，失败重试；
• 定时对账兜底，发现不一致人工或自动修复。

3. 大促高并发

• 读写分离 + 多级缓存：CDN、浏览器缓存、Redis、本地缓存层层拦截。
• 异步化：下单后非核心动作（积分、通知、推荐）全部走 MQ。
• 限流降级：网关层按用户/接口限流；非核心服务（评价、推荐）可降级。
• 热点隔离：秒杀商品独立部署、独立库存，避免拖垮主站。

4. 数据一致性与对账

交易系统宁可慢一点也不能错。每天通过对账任务比对订单、支付、库存、物流数据，差异生成工单处理；关键表保留全量变更日志，便于审计与回溯。

五、技术选型参考

六、总结

电商架构没有银弹，核心是三件事：

1. 按领域拆分职责，让库存、订单、支付各司其职；
2. 用状态机 + 幂等 + 最终一致保证长链路的数据正确；
3. 用缓存、异步、限流换取高并发下的稳定。

真正的考验不在平时，而在大促——架构的好坏，往往体现在洪峰来临时系统是“优雅降级”还是“雪崩”。

本文由 AI 辅助创作，所有内容仅供交流与参考。