从下单卡顿到秒级响应：一个电商服务端架构的实战演进

去年双十一前，老张负责的本地生鲜小程序突然崩了。用户点‘立即购买’后转圈两分钟，订单状态还是‘处理中’。运维查日志发现，下单接口平均响应时间飙到8.6秒，MySQL连接池打满，Redis缓存命中率跌到32%——这不是流量突增的问题，是服务端架构设计没扛住真实场景。

单体架构：能跑就行，但跑不远

最开始，整个系统就一个Java Spring Boot应用，用户、商品、订单、支付全塞在一个jar包里。开发快，部署也简单：一台4核8G云服务器，Nginx反向代理，数据库用MySQL主从。上线前三个月一切顺利，日均订单不到2000单。

问题出现在接入社区团购功能后。团长上传Excel批量上架商品，后台解析逻辑直接在Web线程里执行，一传就是5000条，CPU瞬间拉满，连登录都卡。当时我们改都没法热更，只能凌晨发版重启——用户等不了，业务也等不了。

拆不是目的，解耦才是关键

后来我们没急着上微服务，先做了三件事：

• 把商品导入拆成异步任务，用RabbitMQ接住请求，Worker服务单独消费；
• 订单创建流程剥离库存校验，改用Redis原子操作预占库存（DECRBY stock:1001 1），失败再走补偿；
• 用户中心独立出Auth服务，JWT签发和校验不再经过主应用网关。

这些改动没换技术栈，只是把‘揉在一起’的逻辑掰开，各自有资源、有超时、有降级开关。比如下单服务挂了，商品浏览和搜索照常可用。

一次真实的流量压测现场

今年6月做大促压测，模拟3000 QPS下单请求。原架构下，MySQL写入延迟从12ms跳到217ms，部分事务超时回滚。我们临时启用了读写分离+分库分表（按用户ID哈希分4库），同时把订单状态变更事件推到Kafka，通知物流、短信、积分三个下游系统异步处理。

关键代码片段（订单创建核心逻辑简化）：

public Order createOrder(OrderRequest req) {
    // 1. 预占库存（Redis）
    Long remain = redisTemplate.opsForValue().decr("stock:" + req.getProductId(), 1L);
    if (remain < 0) {
        throw new BusinessException("库存不足");
    }

    // 2. 创建订单（写DB）
    Order order = orderMapper.insert(req.toOrder());

    // 3. 发送事件（非阻塞）
    kafkaTemplate.send("order-created", order.getId(), order);

    return order;
}

压测结果：平均响应时间稳定在320ms以内，错误率低于0.02%，Redis缓存命中率回升至91%。

没用高大上的词，但每一步都踩在痛点上

我们没上Service Mesh，也没搞全链路灰度。真正起作用的是：接口分级（核心下单 vs 非核心评价）、依赖隔离（MySQL不和Redis争内存）、超时控制（HTTP调用统一设2s超时）、以及最重要的——敢砍需求。比如‘实时显示附近团长剩余库存’这个功能，评估后直接暂缓，因为要扫全量团长+实时聚合，代价远大于价值。

现在系统支撑日均3万订单，高峰期能扛住5000+ QPS。服务器从1台变成5台，但运维告警少了，发布频率高了，开发改一个支付渠道不用再担心影响到优惠券计算。