小程序商城微服务拆分实战：订单支付链路与幂等控制

简介基于微服务架构的微信小程序商城系统设计资料面向小程序电商开发者与微服务学习者重点解决商城系统模块拆分、服务解耦与高并发扩展等落地问题。内容围绕用户中心、商品中心、订单中心、支付中心四大核心模块展开梳理了从用户注册登录、商品上下架与库存管理到购物车流程、订单处理及微信支付集成的完整链路同时说明微信小程序端与商家管理后台的交互方式以及服务治理、监控告警和链路追踪等微服务运维实践。资源以压缩包形式提供大小约58.77MB便于离线研读。当前已有367人学习/下载适合作为课程设计参考、毕业项目蓝图或技术预研素材可快速建立电商系统从业务功能到架构设计的整体认知。1. 小程序商城系统为什么要上微服务先想清楚拆什么再动手如果一个微信小程序商城只是把商品列表、购物车、下单、支付塞进一个单体应用里那它撑到几千单可能没问题但当运营活动把流量瞬间顶上来订单模块一抖动商品页面也跟着转圈登录也开始超时这时候再想着下次重构代价就高了。基于微服务的小程序商城系统核心不在小程序端写得多花哨而在后端把用户、商品、订单、支付这些业务拆成独立服务之后还能保证一条下单链路不串线、不丢单、不重复扣款。这篇笔记我按实际拆过的一套商城系统来讲覆盖服务边界怎么划、登录下单支付主链路怎么走、哪些坑是微服务架构下才会冒出来的适合准备把单体商城拆微服务、或者想复现一套完整电商闭环的开发者直接抄作业。2. 微服务拆分的粒度用户、商品、订单、支付四个中心的职责与数据边界2.1 先立论小程序商城拆微服务拆的是数据而不是接口很多人一上来就把 Controller 拆成几个模块就叫微服务这是最容易翻车的地方。微服务拆分的第一原则是数据域独立也就是说用户表归用户中心管订单表归订单中心管商品 SKU 和库存归商品中心管支付流水归支付中心管。任何服务不能直连别的服务的数据库哪怕只是只读查询也要走对方提供的接口。这条约束看起来绕路但它决定了系统能不能扛住后续的扩展。在这套基于微服务架构的小程序商城里用户中心、商品中心、订单中心、支付中心是四个核心服务另外还有网关、鉴权服务和消息消费者。小程序端只跟网关通信网关做路由、限流和 token 校验。这种模式的好处是小程序端拿到的永远是统一入口后台某个服务升级、迁移、扩缩容前端无感知。比如大促前单独给订单中心加两个实例操作只发生在服务端小程序不需要重新发版。实际拆的时候我习惯先画一张表把每个服务要管理的表列清楚这张表就是后面所有接口设计的依据服务数据表对外提供的核心能力用户中心用户主表、微信授权表、收货地址表注册登录、openid 绑定、地址维护商品中心分类表、SPU 表、SKU 表、库存表商品查询、库存扣减与回补订单中心订单主表、订单明细表、购物车表购物车、下单、订单状态流转支付中心支付单表、退款单表、回调记录表微信支付下单、回调处理、退款这张表定了之后后面每写一个接口都要先问自己我要操作的数据属于哪个服务如果不属于自己就走调用。刚开始会觉得麻烦但这是微服务能不能长期维护的分水岭。2.2 商品中心的库存扣减接口设计比数据库锁更重要商品中心最常见的坑是库存扣减。单体系统里一行UPDATE带上stock 0条件就能防超卖但微服务里订单中心不能直接改商品表的库存只能调商品中心接口。这里我一般会在商品中心暴露一个deductStock(skuId, count, orderNo)接口内部用乐观锁更新同时把orderNo记进库存流水表。Transactional public boolean deductStock(Long skuId, Integer count, String orderNo) { // 乐观锁扣减stock count 才允许扣 int rows stockMapper.deductWithLock(skuId, count); if (rows 0) { // 记录扣减失败流水方便后面查账 stockFlowMapper.insertFail(skuId, count, orderNo, stock_not_enough); return false; } // 扣减成功记一条流水orderNo 保证同一订单不会重复扣 stockFlowMapper.insert(skuId, count, orderNo, deduct); return true; }这里deductWithLock对应的 SQL 是UPDATE sku_stock SET stock stock - #{count} WHERE sku_id #{skuId} AND stock #{count}靠数据库行锁保证并发安全。orderNo在库存流水表里加唯一索引这样即使订单中心重试调用商品中心也只会真正扣一次。这个细节如果不做下单超时重试时就会把库存扣成负数。2.3 订单中心的链路位置先预下单再走支付状态机必须单方向流转订单中心在这套系统里连接商品和支付两端。用户点下单订单中心先调商品中心预扣库存再创建订单数据然后调支付中心生成支付参数小程序端拿到参数后拉起微信支付。注意这里不是一次性把订单状态置成已支付而是先落到待支付支付回调成功后才切到已支付。订单状态机我建议设计成单方向流转待支付 - 已支付 - 已发货 - 已完成以及待支付 - 已关闭。这个流转只能往前不能回退任何回退操作都要走逆向流程比如退款。实际开发中常见的问题是把已支付状态直接改回待支付这种操作一旦出现后续对账全乱。我的习惯是用一张状态变更日志表记录每一次流转谁改的、从哪改到哪、原因是什么排查线上问题的时候这张表是救命稻草。2.4 支付中心的独立性回调处理不能依赖其他服务支付中心是这套系统里最要独立的部分。它的职责是接收小程序端发起的支付请求调用微信支付接口生成预支付单然后等微信服务器回调。这里有个关键点收到微信回调后支付中心要先自己完成验签、解密、落库再通过异步消息通知订单中心去更新订单状态。为什么不能让支付中心直接同步调用订单中心因为微信支付回调是有超时容忍的如果同步调订单中心时订单服务刚好在重启或者 GC 停顿回调就会超时微信会认为你处理失败而重复通知。用 MQ 解耦之后回调落库即成功通知失败可以重试。这套系统里我用的是延迟队列做重试补偿通知失败的订单 30 秒后自动重新推送。3. 从登录到支付的主链路微信登录、预下单、支付回调三个关键环节3.1 微信登录code 换 openid会话状态必须后端统一管理小程序端 wx.login() 拿到的是临时 code这个 code 有效期只有五分钟而且只能换一次 openid 和 session_key。后端拿到 code 后要立即调微信的 jscode2session 接口然后自己维护一份登录态而不是把 session_key 直接返回给小程序端存着那这玩意儿一旦泄露用户信息就裸奔了。public LoginResp wxLogin(String code) { // 用 code 向微信服务端换 openid 和 session_key WxSession session wxClient.jscode2session(code); // openid 是用户在小程序体系里的唯一标识必须落库 User user userMapper.findByOpenid(session.getOpenid()); if (user null) { user createUser(session.getOpenid()); } // 签发自己的 token后续请求都走这个 token不再依赖微信 session String token jwtService.generateToken(user.getId()); return new LoginResp(token, user); }这里有两个容易被忽略的参数问题。第一jscode2session 接口需要在小程序后台配置合法的 request 域名开发环境下可以在微信开发者工具里勾选不校验合法域名但上线前必须换成 HTTPS 备案域名。第二code 换 session 是幂等的但不要自己缓存 code 到 session_key 的映射直接每次实时换省得处理过期逻辑。token 过期时间我一般设 2 小时用户每次打开小程序静默登录一次体验上没有感知。3.2 订单中心预下单库存预扣、金额计算、防重提交三步走预下单是在用户点击提交订单之后、拉起支付之前完成的。这一步要处理三个事务生成订单主表和明细、调商品中心预扣库存、调支付中心创建支付单。这三个操作不是原子性的所以要用事务消息或者本地消息表来保证最终一致性后面第 4 章展开讲坑。Transactional public Order preCreateOrder(Long userId, ListCartItem items) { // 1. 从购物车数据组装订单金额以商品中心实时价格为准 Order order buildOrder(userId, items); // 2. 预扣库存失败则整个订单创建流程中断 boolean deducted productClient.deductStock(items); if (!deducted) { throw new BizException(部分商品库存不足); } // 3. 订单状态进入待支付 order.setStatus(OrderStatus.WAIT_PAY); orderMapper.insert(order); // 4. 发送消息触发支付单创建不同步等待 mqSender.send(payment.create, order.getOrderNo()); return order; }这段代码里最值得说的是第 4 步。我见过不少系统在预下单里同步调支付中心结果支付中心响应慢 2 秒整个下单接口就跟着慢。拆微服务之后下单链路每一步的耗时都会被放大所以主链路上能异步的就异步。预下单只需要保证订单落库、库存锁定支付单创建异步处理完全来得及用户拉起支付时支付参数早就准备好了。金额计算注意用 BigDecimal而且以分为单位传给微信支付接口避免浮点误差。3.3 支付回调验签、解密、幂等落库、通知订单中心支付回调是支付中心最核心的代码也是所有问题的高发区。微信支付回调通知是 XML 格式v2 用 MD5 或 HMAC-SHA256 验签v3 用证书和 AES-256-GCM 解密。这里我以 v3 为例写回调处理的骨架public PayCallbackResult handleCallback(HttpServletRequest request) { // 1. 读取请求头中的 Wechatpay-Signature用平台证书验签 boolean valid wechatSignatureValidator.verify(request); if (!valid) { return PayCallbackResult.FAIL; } // 2. 解密 resource 节点拿到订单号、支付金额、支付时间 WxPayOrder payOrder wechatDecryptor.decrypt(request); // 3. 幂等检查回调记录表里已经有这个订单号就直接返回成功 if (callbackLogMapper.exists(payOrder.getOutTradeNo())) { return PayCallbackResult.SUCCESS; } // 4. 落库支付流水状态置为已支付 payMapper.create(payOrder); // 5. 发 MQ 通知订单中心更新订单状态 mqSender.send(order.paySuccess, payOrder.getOutTradeNo()); return PayCallbackResult.SUCCESS; }这里有个很容易踩的坑微信支付回调如果收到非 200 响应或者响应内容不是字符串 SUCCESS它会持续重试频率从 15 秒逐渐拉长到最长 3 天。所以回调接口里任何业务异常都要 try/catch 住只要验签通过、解密成功就先落库再返回成功。通知订单中心失败属于内部问题用 MQ 重试补偿而不是让微信帮你重试——微信重试的间隔根本不符合业务需求。4. 微服务商城落地避坑注册发现、分布式事务、幂等控制三个高频翻车点4.1 服务注册后发现网关路由时好时坏多半是健康检查配置太随意现象小程序端调用接口有时候通有时候不通过几分钟又自己恢复网关日志里报503 Service Unavailable。原因服务注册到注册中心后健康检查配置使用的是默认的/actuator/health这个接口如果依赖的数据库或者 Redis 出现短时抖动整个服务实例就被标记为不健康而被摘除。而电商场景里下单接口依赖的组件多任何一个小依赖抖动都会触发服务下线。解决把健康检查改成细粒度的自定义探针只检查服务自身启动状态和核心线程池不要去 check 数据库、Redis、MQ 这些外部组件。指标采集和健康检查分开外部组件状态通过监控系统单独看。另外注册中心的心跳频率和阈值要根据线上实际情况调不要太灵敏否则一次 GC 停顿就导致大批实例被摘除。4.2 分布式事务下单扣库存和创建订单的不一致是宿命现象用户下单后支付成功但订单详情里查不到库存扣减记录或者库存扣了但订单因为异常没创建成功用户钱付了却收不到货。原因订单中心和商品中心是两个服务本地事务只能保证各自服务内部的一致性。常见的错误做法是用 Seata 这类分布式事务框架去强一致但这套系统里下单链路对性能敏感强一致事务会把一次下单的耗时从 50ms 拉到 200ms 以上大促时根本扛不住。解决接受最终一致性。我的做法是每个服务建本地消息表本地事务里同时写业务数据和消息记录然后通过消息中间件投递。订单中心创建订单时写一条预扣库存消息到本地消息表事务提交后消息发出商品中心消费后扣库存扣完回调订单中心。任何一步失败靠定时任务扫本地消息表做补偿扫到超过 2 分钟还没成功的消息就报警人工介入。4.3 支付回调幂等重复通知会把订单状态覆盖成错误值现象用户支付成功后订单状态偶尔会从已支付跳回待支付或者同一订单出现两条支付流水。原因微信支付回调最少一次投递同一个支付结果会通知多次。回调处理代码里如果只判断当前订单状态是否已支付那么第一次通知更新为已支付第二次通知进来时如果先去额外处理了别的逻辑就可能在某个分支里把状态又写回去了。解决回调处理和订单状态更新之间必须有一个中间存储做幂等屏障。我在支付中心做了两个措施一是回调记录表对out_trade_no建唯一索引第二次回调直接命中索引冲突返回成功二是在把 MQ 消息投递给订单中心时带上payment_serial_no订单中心处理时记录已消费的消息 ID重复消息直接丢弃。这两个屏障叠起来重复通知就不会再造成状态覆盖。4.4 微信开发者工具里的 Launcher 行为登录态过期和 code 复用是两回事现象小程序端在开发者工具里调试时偶尔会出现用户已登录但后端查询用户失败或者同一个 code 调两次登录接口第二次报错。原因微信开发者工具里的登录行为和真机有些差异code 复用是微信服务端明确禁止的一个 code 只能换一次 openid。前端代码里如果某个页面同时触发多次wx.login()后面的 code 必然废掉。解决小程序端做一个统一的登录包装函数确保wx.login()的调用是串行的。已经拿到 token 的情况下不要重复发起登录token 过期时通过后端返回的 401 状态码来触发静默登录而不是在页面加载时无条件调wx.login()。这个处理在真机和开发者工具上都有效。5. 本地联调与上线验证从启动顺序到链路追踪定位问题拿到这套微服务商城系统之后本地联调的第一步是确认启动顺序。正确的顺序是先启动注册中心再启动配置中心然后是网关最后才是各个业务服务。如果业务服务比注册中心先启动它会反复报连接失败重试虽然最终能连上但日志里会刷大量错误信息干扰排错。联调小程序端时微信开发者工具是最常用的调试入口。注意在本地开发阶段要在详情 - 本地设置里勾选不校验合法域名这样才能让小程序端请求到http://localhost:8080的网关地址。上线前再把网关域名换成备案过的 HTTPS 域名这一步忘了的话真机上所有请求都会失败。系统自带的链路追踪能力是排查微服务问题最趁手的工具。我的建议是每笔订单都生成一个traceId从网关入口开始透传到用户中心、订单中心、商品中心、支付中心的所有日志里。出问题时按traceId一查全链路的调用耗时、哪个服务慢、哪个服务报错一眼就能定位。验证链路是否打通的方法很简单下一笔订单支付成功后到订单中心查状态然后按订单号去链路追踪页面里看完整的调用链路。验证项操作预期结果服务注册启动全部服务后看注册中心控制台五个服务全部在线登录链路小程序端点击登录用户落库返回有效 token预下单链路加购商品后提交订单库存预扣成功订单待支付支付回调链路用测试支付单模拟回调支付流水落库订单变已支付幂等验证同一支付单重复投递两次第二次直接返回成功无重复流水链路追踪按订单号查 traceId能看到网关到商品中心完整调用链我自己的习惯是每次改完库存扣减或者支付回调这类核心代码都强制走一遍上面的验证清单再合入分支。有一次就是因为省了最后一步幂等验证上线后出现订单状态被回调重复通知覆盖排查了整整半天后来发现是消费端没有做消息 ID 去重。从那以后我每次接到这类变更都会先把重复投递和重复回调的场景在本地用脚本模拟一遍再往上走希望帮到你。本文还有配套的精品资源点击获取