订单系统重构实践：Spring Boot+RocketMQ+ShardingSphere高可用架构

1. 项目定位与技术选型的核心逻辑

这个新项目在我们内部代号叫“星链订单协同系统”，本质上是一个传统制造业客户下的多端订单管理平台二期工程。先说结论：这不是一个从零开始搭建的“绿地项目”，而是对一套运行了五年多的老单体系统做的一次彻底重构与升级。老系统用的是 Spring MVC + MyBatis + MySQL 的经典组合，代码里堆了太多业务判断，一个订单状态流转的方法动辄几百行，每次加需求都要小心翼翼，因为根本不知道改一处会不会带崩另一处。

这次新项目的核心目标非常明确：把订单主链路拆出来，做成独立可扩展的服务，同时保留原有系统的查询和报表能力。技术栈上我们最终敲定的是 Spring Boot 3.2 + Java 17 + Redis 7 + RocketMQ 5 + ShardingSphere 5.3，前端没有太大改动，还是沿用 Vue 3 的管理后台。为什么这么选？因为团队对这套技术栈最熟，踩坑成本最低。Spring Boot 3 强制要求 Java 17，而 Java 17 的虚拟线程对 IO 密集型的订单处理场景帮助极大；RocketMQ 用来做订单状态变更的异步通知，能扛住秒杀和促销时期的峰值流量；ShardingSphere 则是为了应对订单表数据量已经接近单表千万级的现实压力。

很多人问为什么不上微服务那一套注册中心、网关、链路追踪全家桶。我的回答是：项目规模没到那个程度，强行上微服务只会把复杂度拉高，运维成本翻倍，对业务交付毫无帮助。这个系统核心服务就三个：订单中心、库存中心、支付对接服务。用一台 8C16G 的服务器跑订单中心，一台 4C8G 跑库存中心，支付对接服务直接并入订单中心内部模块，足够应对现有业务量。保留一个 Spring Cloud Gateway 做统一入口，主要是为了方便鉴权和限流，并不是为了“微服务而微服务”。

项目选型的首要原则从来不是“什么新用什么”，而是“什么稳用什么、团队熟用什么、业务需要什么”。重构系统最忌讳的就是在技术栈上追求花活，结果没人能维护。

2. 核心业务模块与数据模型设计

2.1 订单主链路的状态机设计

订单状态是整个系统的灵魂。老系统的状态流转散落在各个 Service 方法里，有的地方直接 update status，有的地方发消息通知，完全没有统一出口。这次我们做了一个 OrderStateMachine 组件，把订单状态和允许的流转事件全部集中管理。

订单状态我们设计为：待支付、已支付、备货中、已发货、已签收、已取消、售后中、已完成。每个状态有一个对应的允许事件列表，比如“待支付”状态下只允许“支付成功”和“用户取消”两个事件，“已支付”状态下只允许“卖家发货”或“用户退款申请”。事件触发时统一走 stateMachine.fire(event, orderContext) 方法，方法内部先校验当前状态是否允许该事件，再执行对应的业务逻辑，最后落库。

这里有个细节值得单独讲：订单状态更新必须使用乐观锁。我们在订单表加了 version 字段，所有 UPDATE 语句都带上 version = oldVersion 条件，影响行数为 0 时说明有并发冲突，需要重试或者提示用户。之前老系统在活动大促时候出现过订单状态被覆盖的问题，就是因为在 Service 层用 if 判断状态然后直接 update，两个线程同时读到“待支付”，一个支付成功一个取消，后提交的请求把前者覆盖了。

2.2 分库分表与归档策略

订单表和订单明细表是数据量增长最快的两张表。订单表现在每天新增两万行左右，半年下来就是三百多万，加上历史数据已经接近两千万。按照 MySQL 单表两千万的性能拐点，必须提前做拆分。

这次我们用的是 ShardingSphere 的 standard 分片策略，按订单号末两位做取模分片，分成 16 个库，每个库 4 张表。订单号生成规则是：时间戳 + 机器ID + 自增序列 + 两位随机数。取模键直接用订单号后两位，这样同一个订单的明细表和主表在同一分片下，避免跨库关联查询。实际验证下来，单表数据量控制在五百万以内时，简单条件查询加索引都在 50 毫秒以内。

归档策略也不能忽略。超过两年的完结订单（已签收、已取消、售后结束）会通过定时任务迁移到归档库。归档库是单独的 MySQL 实例，只开放只读权限，业务系统需要查询历史订单时走独立的数据源。这里有个经验：归档迁移必须分批执行，每批 1000 条，执行完一批休息 200 毫秒，避免长时间的锁表影响在线业务。迁移完成之后还要做数据校验，比对源表和归档表的数量、金额合计、状态是否一致，不一致的要记录日志重新迁移。

2.3 库存扣减与超卖防护

库存模块在重构前是直接在订单事务里扣减库存的，导致两个问题：一是库存表行锁竞争严重，二是订单失败时库存回滚逻辑混乱。这次我们改成了 Redis 预扣 + 数据库异步扣减的方案。

具体流程是这样的：用户提交订单时，先在 Redis 里执行 DECR 操作预扣库存，如果返回的值大于等于 0，说明库存充足，继续走创建订单流程；如果返回负数，说明库存不够，需要把扣减的量加回去并提示用户库存不足。订单创建成功后再通过 RocketMQ 发送一条异步消息，由库存服务消费消息执行数据库扣减。

预扣和实际扣减之间有个时间窗口，可能存在数据库扣减失败的情况。我们的兜底方案是：订单创建成功且数据库扣减失败时，消息重试三次，三次仍失败就进入人工处理队列，同时标记该订单为异常单。这个方案虽然不能百分之百自动化解决所有极端场景，但实际运行下来异常率控制在万分之一以内，完全可接受。

3. 工具选型与生产环境落地方案

3.1 构建与部署流水线

整个项目采用 GitLab 托管代码，Jenkins 做持续集成，Artifactory 做构件仓库，Docker Compose 做部署编排。为什么不用 K8s？因为公司运维团队只有两个人，K8s 集群维护成本太高，一个 docker-compose.yml 跑三台服务器足够稳定，出了问题排查也更直接。

流水线分为四步：代码拉取、单元测试与静态扫描、构建镜像并推送、服务器拉取镜像并重启容器。单元测试覆盖核心 Service 层，要求覆盖率不低于 70%，静态扫描用团队配置好的规则集，重点检查空指针风险、资源未关闭、SQL 注入等问题。构建阶段用 Maven 的 dockerfile-maven-plugin 直接打镜像，版本号取 Git commit 的短哈希，比如 order-center-8f3a2c1，这样回滚时只要查 Git 记录就能定位到对应镜像。

3.2 配置文件与环境隔离

配置文件我们踩过不少坑，最后形成了固定规范：每个服务有 application.yml（公共配置）、application-dev.yml（开发环境）、application-test.yml（测试环境）、application-prod.yml（生产环境）四份文件。敏感信息比如数据库密码、Redis 密码、消息队列密钥不允许直接写在配置文件里，统一放到环境变量中，由部署脚本注入。

生产环境启动命令大概是这样的：

docker run -d --name order-center \ -e SPRING_PROFILES_ACTIVE=prod \ -e DB_PASSWORD='xxx' \ -e REDIS_PASSWORD='xxx' \ -e ROCKETMQ_NAMESRV_ADDR='10.0.0.11:9876;10.0.0.12:9876' \ -p 8080:8080 \ --memory=4g \ order-center:8f3a2c1

这里有个细节值得注意：JVM 参数在容器里最好交给容器运行时来控制，而不是在 Dockerfile 里硬编码 -Xmx。我们给每个服务设置了 --memory 上限，并开启 JVM 的容器感知模式（UseContainerSupport 默认开启），让 JVM 自动根据容器内存限制调整堆大小，避免物理机内存和容器内存不一致导致的 OOM 问题。

3.3 数据库变更管理

数据库结构变更我们也是纳入版本管理的，用的是 Flyway。每次发版前，开发人员在迁移脚本目录下新增一个 V20240610__add_order_refund_no.sql 这种命名规范的脚本，程序启动时会自动校验版本号并执行未执行的脚本。这个习惯一开始推行很痛苦，总有同事喜欢直接连数据库改表，后来我们把生产数据库账号权限收掉，只保留只读权限，才彻底堵住这个口子。

4. 上线过程中的常见问题与排查技巧实录

4.1 内存溢出问题

项目上线第一周就出了一个大问题：订单中心服务频繁 OOM，每小时重启一次。刚开始以为是堆内存不够，把容器内存从 4G 调到 8G，问题依旧。后来通过 dump 文件分析才发现，问题不在堆内存，而在直接内存（Direct Memory）。

RocketMQ 的消费者客户端和 Netty 默认使用堆外内存做缓冲区，默认配置下每个连接会申请较大的 direct memory。我们生产环境消费者线程配置偏多，高峰期创建的连接数远超预期，直接把 direct memory 打满了。解决办法是调整 RocketMQ 消费者线程数和 Netty 的 buffer 池大小参数，同时在启动命令中加上 -XX:MaxDirectMemorySize=2g 做上限控制。这个坑非常经典，强烈建议所有使用 RocketMQ 或 Netty 的团队在压测阶段就关注直接内存的使用情况。

4.2 慢 SQL 排查与索引优化

上线后监控系统报出几条慢 SQL，都是订单明细表的查询。看执行计划发现，虽然查了订单号和商品ID两个字段，但只命中了订单号索引，商品ID的过滤是在回表之后才做的，数据量一上来就很慢。

优化方式是建了一个联合索引 (order_no, sku_id, status)，把查询中最常用的三个条件全部覆盖，减少回表次数。改完之后同样的查询从 800 毫秒降到 30 毫秒。这里有个原则：索引不是越多越好，而是要结合真实的查询模式。先看慢查询日志里出现频率最高的 SQL，再决定加什么样的索引，不要凭感觉建一堆用不上的索引，反而拖慢写入速度。

4.3 消息队列消息积压与重复消费

活动期间 RocketMQ 出现一次消费积压，积压消息数一度到了 5 万条。原因是库存扣减消费者里调了第三方物流接口，第三方接口超时时间设的 30 秒，消费者线程又少，一下就堵住了。后来做了两个改动：一是把调用第三方接口的逻辑改成异步化，发送一条状态为“待通知物流”的消息，由专门的延迟任务去轮询；二是把消费失败的重试策略从立即重试改为延迟重试，第一次延迟 5 秒，第二次延迟 30 秒，第三次延迟 5 分钟，超过三次进入死信队列人工处理。

消息重复消费这个事也要特别注意，生产环境偶发因为网络抖动导致同一条消息被消费两次。我们在所有消费逻辑上都做了幂等处理，核心思路是利用数据库唯一索引：比如库存扣减表加了业务单号唯一索引，重复消费时插入失败直接忽略，保证结果一致。

5. 性能压测数据与容量规划心得

5.1 压测环境搭建与结果分析

上线前我们搭了一套和生产环境配置一致的压力测试环境，用 JMeter 模拟了三个典型场景：普通下单、活动秒杀、查询订单列表。压测的目标不是“能扛多少并发”，而是找到系统在什么量级下开始出现性能拐点，以便提前扩容。

普通下单场景，1000 并发持续压测 15 分钟，订单中心平均响应时间 120 毫秒，P99 在 380 毫秒，CPU 使用率稳定在 70% 左右，数据库连接池偶尔出现等待，整体表现健康。活动秒杀场景，5000 并发进来的时候，Redis 预扣库存成为瓶颈，因为所有请求都集中打在同一批 key 上，我们提前把库存按照商品维度做了分片，每个商品拆成 128 个 key，压力分散后通过了压测。

查询列表场景暴露了一个隐藏问题：订单列表页做了分页，但深分页（翻到第五百页）时 LIMIT 100000, 20 这种写法的扫描代价极高，响应时间到了 3 秒以上。后面改成基于游标的分页方式，用 (update_time, order_no) 联合索引记录上一页最后一条数据的位置，深分页问题才算解决。

5.2 容量规划与成本控制

根据压测数据，单台 8C16G 的订单中心可以支撑 800 QPS 的核心交易请求，双十一这种高峰期预估峰值在 2000 QPS 左右，所以配置两台订单中心做负载均衡，一台出问题另一台也能顶上。数据库方面，16 库 4 表的拆分方案在三五年内不需要再动，Redis 集群用三主三从的哨兵模式，内存共 96G，库存数据加会话数据完全够用。

成本控制上有一条很实用的经验：不要把生产环境的规格堆得太高，先把监控做起来，让数据告诉你哪里需要扩容。我们买服务器的时候，先按保守规格买，跑起来之后根据监控曲线调整，比一次性买最高配省了大约 30% 的成本。扩容这种事，有了监控数据和压测数据做支撑，决策就清晰了。

6. 上线后的稳定性保障与后续规划

6.1 监控告警体系搭建

上线稳定运行之后，监控这块反而成了我最重视的部分。整个监控体系分三层：基础层是服务器 CPU、内存、磁盘、网络，用 Prometheus + Grafana 展示；应用层是接口 QPS、响应时间、错误率、JVM 内存和 GC 情况，通过 Micrometer 暴露指标给 Prometheus 抓取；业务层是核心链路埋点，比如订单创建成功率、支付回调延迟、库存扣减异常数。

告警规则要控制好力度，太多无效告警会让值班的人麻木，太少又起不到作用。我们的经验是：基础设施告警只保留严重级别（CPU 持续 90% 以上 5 分钟、磁盘使用率超过 85%），应用层告警保留 P99 超过阈值或错误率超过 1% 的情况。告警通知渠道是企业微信机器人，带上服务名、环境、错误摘要和日志链接，值班人员点进去就能看到上下文。

6.2 后续迭代方向

这个项目上线后的第一轮迭代计划已经排好：一是订单详情页的缓存优化，把热点订单放到 Redis，减少数据库压力；二是增加供应商对账模块，对接现有的财务系统；三是把库存中心独立成完全可插拔的服务，后续如果要接其他销售渠道，就不用再动订单中心的代码。

从个人体会来说，企业级项目最难的从来不是技术本身，而是如何在业务快速变化和技术复杂度之间找到平衡点。技术方案不是越复杂越好，能够用最简单的手段解决实际问题、并且让团队每个人都看得懂、维护得动，这才是最好的方案。这次项目里踩过的那些坑，反而不是坏事，它们逼着我们把日志、监控、幂等等基础能力做扎实了，这些沉淀下来的东西，比任何一个“炫技”的技术点都更有价值。