Mall4cloud微服务商城实战：从下单到库存扣减的避坑指南

简介Mall4cloud微服务商城系统是一套面向Java后端开发者与架构学习者的B2B2C电商实战项目适合希望深入掌握Spring Cloud微服务技术栈、构建新零售与网店商城的中高级开发者参考。项目整合Nacos注册配置中心、Seata分布式事务、RocketMQ消息队列、canal数据同步、ElasticSearch搜索、Redis缓存与minio对象存储覆盖商品、订单、用户、支付等核心业务模块可作为微服务架构落地的完整范例。资源包共1569个文件约17.01MB以520个Java源码为主体辅以273个JavaScript与135个Vue前端页面、335个PNG与48个SVG静态资源另有69个XML配置、17个SQL脚本、14个YML及Dockerfile、Nginx配置等部署文件前后端与运维配置齐备。目前已有167人学习下载。通过该资源可系统梳理微服务拆分思路、分布式事务处理与缓存搜索协同方案并借助SQL脚本与容器配置快速还原运行环境适合对照源码理解各组件协作流程与排错要点。1. Mall4cloud 微服务商城系统一套能跑通交易闭环的 Spring Cloud 实战底座如果你正在找一个能真正跑通「商品 → 购物车 → 下单 → 支付回调 → 库存扣减」全链路的 Spring Cloud 微服务开源项目Mall4cloud 大概率会出现在你的候选清单里。它不是一个只演示注册中心的玩具工程而是把商城系统里最容易翻车的几个环节——分布式事务、库存超卖、订单幂等、网关鉴权——都摆到了台面上。我第一次把它拉下来跑通的时候最直观的感受是这套东西的拆分粒度比很多「教学项目」要细服务之间的调用关系也更接近真实生产环境。它适合两类人一是想从单体商城过渡到微服务架构的后端开发者二是需要一套可裁剪的电商底座来做二次开发的小团队。接下来的内容我会按「先搞清楚它怎么拆、再动手跑起来、最后把坑填平」的顺序把 Mall4cloud 微服务商城系统的落地路径讲透。2. Mall4cloud 的服务拆分逻辑与本地环境搭建2.1 从微服务架构图看 Mall4cloud 的模块边界拿到一个微服务项目我习惯先看它的架构图因为架构图直接决定了你后面调试时该去哪个服务里找日志。Mall4cloud 的拆分思路是典型的「按业务域切」网关层统一入口认证服务独立商品、订单、购物车、用户、支付各自成服务另外还有一套基础服务承载文件、搜索、消息等横切能力。这种拆法在微服务拆分里算是比较克制的没有把每个实体都拆成一个服务避免了服务数量爆炸带来的运维负担。具体来说网关负责路由转发和 Token 校验认证中心签发和刷新凭证业务服务之间通过 OpenFeign 做同步调用异步场景走消息队列。库存扣减和订单创建之间的数据一致性是这套架构里最值得关注的部分。很多同类项目在这里要么用本地事务硬扛要么直接忽略Mall4cloud 的处理方式更接近实际生产中的折中方案。理解模块边界之后你还需要知道服务之间的依赖顺序。启动的时候注册中心和配置中心必须最先起来然后是网关和认证服务最后才是各个业务服务。这个顺序搞反了你会看到一堆连接超时的报错但问题其实不在代码上。2.2 本地跑通的最小步骤与依赖清单在动手之前先把环境对齐。我一般会用一个表格把依赖列清楚避免装到一半发现版本不兼容。组件作用版本建议JDK运行环境17 或 21Maven依赖管理3.8MySQL业务数据库8.0Redis缓存与分布式锁6.xNacos注册与配置中心2.xRocketMQ异步消息4.x 或 5.x环境准备好之后按下面的步骤操作。先克隆代码然后初始化数据库。Mall4cloud 的 SQL 脚本通常按服务分库你需要逐个执行。# 克隆项目到本地 git clone mall4cloud 仓库地址 cd mall4cloud # 初始化数据库按服务依次导入 mysql -uroot -p doc/sql/mall4cloud_gateway.sql mysql -uroot -p doc/sql/mall4cloud_auth.sql mysql -uroot -p doc/sql/mall4cloud_product.sql mysql -uroot -p doc/sql/mall4cloud_order.sql mysql -uroot -p doc/sql/mall4cloud_user.sql数据库导入完成后启动 Nacos。如果你用的是单机模式直接执行启动命令即可。# 启动 Nacos 单机模式 sh startup.sh -m standalone接下来修改各服务里的配置文件把数据库地址、Redis 地址、Nacos 地址改成你本地的。这一步是新手最容易翻车的地方——配置文件分散在多个模块里改漏一个就会导致服务注册不上。我的做法是用全局搜索把127.0.0.1和默认密码全部替换一遍然后再逐个确认。# 以订单服务为例application.yml 中需要关注的核心配置 spring: datasource: url: jdbc:mysql://127.0.0.1:3306/mall4cloud_order?useUnicodetruecharacterEncodingutf8 username: root password: your_password redis: host: 127.0.0.1 port: 6379 cloud: nacos: discovery: server-addr: 127.0.0.1:8848配置改完之后按依赖顺序启动服务。先启动基础服务再启动业务服务。启动过程中如果看到某个服务一直注册不上先去 Nacos 控制台看服务列表确认是网络问题还是配置问题。提示第一次启动建议只跑通「网关 认证 商品 订单」四个服务把主链路走通之后再逐步加其他服务这样排查问题的范围会小很多。3. 核心交易链路从下单到库存扣减的代码实现3.1 订单创建与分布式事务的处理方式订单创建是整个商城系统里最复杂的一环因为它同时涉及订单表写入、库存扣减、购物车清理、优惠券核销等多个操作。在单体应用里这些操作可以放在一个本地事务里但在微服务架构下它们分散在不同的服务中本地事务就失效了。Mall4cloud 在这块的处理思路是订单服务作为主控方先落订单记录然后通过 Feign 调用库存服务执行扣减。如果扣减失败订单状态回滚为「已取消」。这种方案不是强一致性而是最终一致性中间有一个短暂的不一致窗口。对于商城场景来说这个窗口是可以接受的因为用户下单后不会立刻要求库存数字同步。// 订单创建的核心逻辑简化示意 Transactional(rollbackFor Exception.class) public OrderVO createOrder(OrderParam param) { // 1. 校验商品状态和价格 ListProductVO products productFeign.getProductsByIds(param.getProductIds()); checkProductStatus(products); // 2. 计算订单金额 BigDecimal totalAmount calculateTotal(products, param.getCoupons()); // 3. 写入订单主表和明细表 Order order buildOrder(param, totalAmount); orderMapper.insert(order); orderItemMapper.batchInsert(buildOrderItems(order, products)); // 4. 调用库存服务扣减库存 try { stockFeign.deductStock(buildStockDTO(order)); } catch (Exception e) { // 扣减失败抛出异常触发本地事务回滚 throw new BusinessException(库存不足下单失败); } // 5. 清理购物车 cartFeign.removeByProductIds(param.getProductIds()); return convertToVO(order); }这段代码里有几个关键点值得展开。第一库存扣减放在本地事务的最后一步目的是让订单写入和库存扣减之间的时间窗口尽可能短。第二库存服务本身的扣减操作必须保证幂等否则网络重试会导致重复扣减。第三购物车清理放在库存扣减之后即使清理失败也不影响订单本身可以通过补偿任务兜底。参数方面OrderParam里通常包含用户 ID、商品列表、收货地址、优惠券信息等。deductStock接口的入参需要包含订单号这样库存服务可以用订单号做幂等键。如果你在压测时发现下单接口的响应时间波动很大大概率是库存服务的锁竞争导致的可以考虑把库存扣减改成异步消息驱动。3.2 库存防超卖的三种锁策略对比库存超卖是商城系统的经典问题也是面试里被问烂的话题。但在实际项目里真正把这个问题处理好并不容易。Mall4cloud 里用到了 Redis 分布式锁但分布式锁并不是唯一方案我把常见的三种策略列出来对比一下。策略实现方式优点缺点数据库悲观锁SELECT ... FOR UPDATE实现简单强一致并发差容易死锁Redis 分布式锁SETNX Lua 脚本性能好适合高并发需要处理锁续期和误删乐观锁版本号或库存字段 CAS无锁竞争吞吐高失败重试逻辑复杂Mall4cloud 采用的是 Redis 分布式锁加库存预扣减的组合。具体做法是先在 Redis 里扣减库存扣减成功后再异步同步到数据库。这样做的好处是 Redis 的原子操作能扛住高并发数据库只承担最终落盘的角色。// Redis 预扣减库存的 Lua 脚本 // KEYS[1]: 库存 key // ARGV[1]: 扣减数量 // ARGV[2]: 订单号用于幂等 String luaScript local stock redis.call(GET, KEYS[1]) if not stock then return -1 end if tonumber(stock) tonumber(ARGV[1]) then return -2 end redis.call(DECRBY, KEYS[1], ARGV[1]) redis.call(HSET, KEYS[1] .. :orders, ARGV[2], ARGV[1]) return 0 ; // 执行脚本 Long result redisTemplate.execute( new DefaultRedisScript(luaScript, Long.class), Collections.singletonList(stock: productId), String.valueOf(quantity), orderNo ); if (result -1) { throw new BusinessException(库存未初始化); } else if (result -2) { throw new BusinessException(库存不足); }Lua 脚本的好处是把「查库存」和「扣库存」两个操作合并成原子操作避免了并发场景下的竞态条件。脚本里的HSET记录了每个订单的扣减数量这是为了后续对账和回滚用的。如果订单超时未支付你需要根据这个记录把库存加回去。注意Redis 预扣减之后一定要有定时任务把 Redis 库存和数据库库存做对账。我见过太多项目因为 Redis 和数据库不一致导致线上出现「有库存但下不了单」的玄学问题。4. 网关鉴权与用户上下文传递的避坑指南4.1 Token 校验链路与常见失效场景Mall4cloud 的鉴权链路是这样的用户登录后认证服务签发 Token网关在转发请求前校验 Token 的有效性校验通过后把用户 ID 放到请求头里传给下游服务。下游服务从请求头里取用户 ID不需要再查一次认证服务。这个链路看起来简单但实际调试时经常遇到问题。最常见的现象是明明登录成功了但访问业务接口返回 401。原因通常有三种Token 过期时间设置太短、网关的过滤器顺序不对、或者下游服务没有正确读取请求头。// 网关全局过滤器中的 Token 校验逻辑简化示意 Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { String token exchange.getRequest().getHeaders().getFirst(Authorization); if (StringUtils.isEmpty(token)) { exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED); return exchange.getResponse().setComplete(); } // 校验 Token 并解析用户信息 UserInfo userInfo authService.parseToken(token); if (userInfo null) { exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED); return exchange.getResponse().setComplete(); } // 把用户信息放入请求头传递给下游服务 ServerHttpRequest request exchange.getRequest().mutate() .header(X-User-Id, String.valueOf(userInfo.getUserId())) .header(X-User-Type, userInfo.getUserType()) .build(); return chain.filter(exchange.mutate().request(request).build()); }这段代码里X-User-Id和X-User-Type是下游服务读取用户信息的 key。如果你在业务服务里取不到用户 ID先检查网关有没有正确设置这两个头再检查业务服务的拦截器有没有正确解析。4.2 用户上下文在 Feign 调用中的丢失问题这是一个非常隐蔽的坑。网关把用户 ID 放到了请求头里业务服务 A 能正常读取。但当服务 A 通过 Feign 调用服务 B 时请求头默认不会传递过去服务 B 就拿不到用户 ID 了。解决方式是配置 Feign 的请求拦截器把当前请求的用户信息透传到下游。// Feign 请求拦截器透传用户上下文 Configuration public class FeignConfig implements RequestInterceptor { Override public void apply(RequestTemplate template) { // 从当前线程的 RequestContextHolder 中获取请求头 ServletRequestAttributes attributes (ServletRequestAttributes) RequestContextHolder.getRequestAttributes(); if (attributes ! null) { HttpServletRequest request attributes.getRequest(); String userId request.getHeader(X-User-Id); String userType request.getHeader(X-User-Type); if (userId ! null) { template.header(X-User-Id, userId); } if (userType ! null) { template.header(X-User-Type, userType); } } } }这个拦截器需要放在所有 Feign 客户端都能扫描到的包路径下。如果你用的是异步线程池处理请求RequestContextHolder会拿不到数据这时候需要手动把用户信息传给异步线程。提示用户上下文透传这个问题在单体应用里根本不存在但到了微服务架构下就变成了必答题。我建议在项目初期就把这个拦截器配好不然后面每个服务都要单独处理很容易漏。5. 配置中心、链路追踪与本地调试的排查技巧5.1 Nacos 配置动态刷新的生效条件Mall4cloud 用 Nacos 做配置中心好处是改配置不用重启服务。但动态刷新有几个生效条件不满足的话你改了配置也不会生效。首先配置类上必须加RefreshScope注解。其次配置的 key 必须和 Nacos 里的 Data ID 对应上。最后如果你改的是数据库连接这种底层配置即使刷新了也不一定生效因为连接池已经初始化了。// 需要动态刷新的配置类 RefreshScope ConfigurationProperties(prefix mall4cloud.order) Component public class OrderProperties { private Integer timeoutMinutes; private Integer maxQuantity; // getter 和 setter 省略 }我一般会在 Nacos 控制台里改一个不痛不痒的参数比如订单超时时间然后观察日志里有没有刷新记录。如果没有就去检查RefreshScope有没有加以及 Nacos 的命名空间和分组有没有配对。5.2 用日志和断点定位跨服务调用失败跨服务调用失败是微服务调试里最头疼的问题因为错误信息往往只显示「调用超时」或「服务不可用」真正的原因藏在链路深处。我的排查顺序是这样的先看网关日志确认请求有没有转发出去再看服务 A 的日志确认 Feign 调用有没有发出最后看服务 B 的日志确认有没有收到请求。如果服务 B 完全没收到请求问题大概率在注册中心或网络层。如果服务 B 收到了但报错问题就在业务逻辑里。Mall4cloud 集成了链路追踪的话你可以通过 TraceId 把整条链路的日志串起来看效率会高很多。# 通过 TraceId 过滤日志 grep traceId: abc123 logs/mall4cloud-order.log grep traceId: abc123 logs/mall4cloud-stock.log另外本地调试时我习惯把 Feign 的日志级别调到 FULL这样能看到请求和响应的完整内容。但生产环境千万别这么干日志量会爆炸。# Feign 日志配置仅本地调试使用 feign: client: config: default: loggerLevel: FULL6. 避坑与常见问题排查6.1 服务注册不上 Nacos 的三种原因现象启动服务后Nacos 控制台的服务列表里找不到该服务或者服务状态一直是「不健康」。原因一Nacos 地址配错了。很多人只改了spring.cloud.nacos.discovery.server-addr忘了改spring.cloud.nacos.config.server-addr导致注册和配置用了不同的地址。解决全局搜索nacos相关的配置项逐个确认地址、命名空间、分组是否一致。原因二网络不通。如果你用的是 Docker 跑 Nacos而服务跑在宿主机上127.0.0.1是访问不到容器内部的。解决把 Nacos 地址改成宿主机的局域网 IP或者用host.docker.internal做桥接。原因三服务名冲突。两个不同的服务用了同一个spring.application.name后注册的会把先注册的覆盖掉。解决检查每个服务的application.name确保全局唯一。6.2 下单接口报「库存不足」但实际有库存现象商品详情页显示有库存但用户下单时提示库存不足。原因Redis 预扣减的库存和数据库库存不一致。常见的情况是之前有订单超时未支付Redis 库存没有及时回滚导致 Redis 里的库存比数据库少。解决写一个定时对账任务每隔几分钟把 Redis 库存和数据库库存同步一次。对账时以数据库为准同时清理掉 Redis 里过期的订单扣减记录。// 库存对账定时任务简化示意 Scheduled(fixedDelay 300000) // 每 5 分钟执行一次 public void reconcileStock() { ListLong productIds productMapper.getAllProductIds(); for (Long productId : productIds) { Integer dbStock productMapper.getStock(productId); String redisKey stock: productId; redisTemplate.opsForValue().set(redisKey, String.valueOf(dbStock)); // 清理过期的订单扣减记录 redisTemplate.delete(redisKey :orders); } }6.3 Feign 调用超时导致订单状态不一致现象用户下单后订单状态一直是「待支付」但库存已经被扣减了。原因订单服务调用库存服务时超时但库存服务实际上已经执行了扣减。订单服务因为超时抛了异常本地事务回滚订单没有落库但库存已经少了。解决库存服务的扣减接口必须支持幂等并且订单服务要有补偿机制。我一般会在订单服务里加一张「调用记录表」记录每次 Feign 调用的状态。如果调用超时定时任务会根据调用记录去查询库存服务的实际扣减结果然后决定是补单还是回滚库存。6.4 网关转发后请求头丢失现象通过网关访问业务接口业务服务里取不到X-User-Id。原因Spring Cloud Gateway 默认会过滤掉一些请求头或者你的过滤器顺序不对导致用户信息还没设置就被转发了。解决检查网关过滤器的order值确保鉴权过滤器在路由转发之前执行。另外如果你用了StripPrefix过滤器注意它只影响路径不影响请求头。6.5 本地启动多个服务导致端口冲突现象启动第二个服务时提示端口被占用。原因多个服务用了相同的server.port或者 Nacos 控制台占用了 8848 端口。解决给每个服务分配独立的端口建议按服务类型分段比如网关用 8000认证用 8001业务服务从 8010 开始递增。如果你在本地跑多个 Nacos 实例记得改端口。7. 用压测数据验证 Mall4cloud 的拆分是否合理跑通主链路之后我建议做一轮简单的压测用数据来判断这套微服务拆分是否合理。压测的目的不是追求多高的 QPS而是找到系统的瓶颈点看看瓶颈出现在哪个服务上。我一般用 JMeter 或 wrk 对下单接口做压测同时观察各服务的 CPU、内存和响应时间。下面是我在一次本地压测中记录的数据供你参考。服务平均响应时间CPU 峰值瓶颈表现网关12ms40%无明显瓶颈订单服务85ms75%数据库写入是瓶颈库存服务45ms60%Redis 连接池偏小商品服务20ms30%缓存命中率高从数据上看订单服务是整条链路的瓶颈主要耗时在订单表的写入和 Feign 调用的等待上。优化方向有两个一是把订单写入改成异步先返回订单号后台慢慢落库二是把库存扣减改成消息驱动减少同步等待。压测时还有一个细节值得注意如果你发现某个服务的响应时间随着并发数增加急剧上升但 CPU 并不高那大概率是线程池或连接池的配置太小了。Mall4cloud 默认的连接池配置偏保守生产环境需要根据实际并发调整。# 库存服务的 Redis 连接池配置压测时适当调大 spring: redis: lettuce: pool: max-active: 50 max-idle: 20 min-idle: 10 max-wait: 3000ms最后说一个我自己的习惯每次改完配置或代码不要只看接口通不通一定要用压测工具跑一轮对比改动前后的响应时间曲线。微服务架构下的性能问题往往是连锁反应单看一个服务的日志很难发现根因。希望这些经验能帮你在 Mall4cloud 微服务商城系统上少走点弯路。本文还有配套的精品资源点击获取