简介面向微信小程序电商开发者的技术资料包围绕“基于微服务的小程序商城系统”展开系统讲解用户中心、商品中心、订单中心、支付中心等核心模块的职责与协作方式并延伸到微信端入口、商家管理平台以及服务治理、监控追踪等工程实践适合有一定后端基础、正在规划或维护小程序商城项目的初中级开发者学习参考。资源以ZIP压缩包形式提供包体约58.77MB目前源站未公开文件总数与具体类型需下载后查看结合主题判断内容应侧重架构设计思路与核心流程说明而非完整可运行的一整套源码。已有367人浏览学习。通过这份资料读者可以理解微服务拆分如何提升电商系统的扩展性与可靠性掌握从商品管理、购物车、订单到支付闭环的关键设计方法并借助其中的模块划分、服务治理和监控思路应用到自身项目的架构评审或方案落地中对技术选型和项目复盘都有一定借鉴价值。1. 基于微服务的小程序商城这不只是把接口拆开一个日活几千的商城单体会在什么时候开始崩溃我在接手一个微信小程序商城项目时发现最初版的 PHP 后端接口已经在促销期不断超时支付回调排队商品详情接口一次要查三张表。团队决定基于微服务重构目标不是“把单体接口拆开”这么浅而是按业务边界切出商品、库存、订单、支付、用户几个独立服务让小程序端只访问一个 API 网关域名后端各自扩缩容、各自隔离故障。这就是“基于微服务的小程序商城系统”真正要落地的事给依赖微信生态的商城套上一个能扛峰值、能独立迭代的后端底座。这篇文章面向正在做商城后端拆分的技术负责人也适合从 0 到 1 建商城、准备用 uniapp 做小程序前端的全栈工程师。我会按照服务划分、骨架搭建、微信登录联调、支付与库存对账、避坑和压测这条路径往下讲每一层都给到可以直接落地的参数和执行步骤。2. 服务边界怎么划按业务域切分别把接口也当成服务2.1 一个商城至少拆六个服务但库存必须是独立服务微服务拆分的第一步不是写代码是把业务边界划清楚。我在实际做小程序商城时最常用的划分是按业务域拆成六个中心用户中心、商品中心、库存中心、订单中心、支付中心、营销中心。小程序商城的典型页面是首页、分类、商品详情、购物车、下单、支付、我的这些页面背后调用的接口分别落在不同的服务里服务之间通过 HTTP 接口互相取数而不是共享同一个数据库。服务核心职责主要表对外接口前缀用户中心微信登录态、会员信息、收货地址member / member_address/api/user商品中心商品分类、SPU / SKU 信息、详情页内容spu / sku / category / banner/api/product库存中心SKU 实时库存、预扣与回补、库存流水stock / stock_flow/api/stock订单中心购物车、订单创建、订单状态机、售后cart / order_info / order_item/api/order支付中心支付单、微信支付回调、退款payment / refund/api/pay营销中心优惠券、秒杀活动、拼团配置coupon / activity / seckill/api/marketing为什么库存一定要独立成一个服务因为小程序商城秒杀和促销场景下库存服务会被高频调用而且它的写压力和商品详情、订单创建的写压力不是一回事。库存服务独立出来后可以单独给它的 Redis 配置更高的内存单独给库存接口做限流出了问题也只需要回滚库存这一条链路不会把商品详情和订单一起拖崩。这里有一个反例之前有团队把优惠券拆成了领券、用券、维权三个服务结果一次下单校验要跨三个服务查四次接口耗时直接到 800ms。商城起步阶段六个服务就是合理粒度再细就是给自己找麻烦。2.2 服务间只通过 API 交互拒绝跨库 join 和直接查别人库服务划分好之后最难执行的是数据边界。我做代码评审时第一条红线就是不允许订单服务直接连商品中心的库去查 SKU 名称和价格不允许支付中心直接改订单表的支付状态。跨服务的数据诉求一律通过提供方暴露的接口来完成。订单回显商品名时订单服务调用商品中心的“批量查询 SKU 信息”接口下单扣减库存时订单服务调用库存中心的“扣减库存”接口支付成功之后支付中心通过 RocketMQ 发一条“支付成功”消息订单服务订阅后自己更新订单状态。跨服务调用在 Spring Cloud Alibaba 里最常用的方式是 OpenFeign。我一般会为每个下游服务定义一个 FeignClient接口签名和下游 Controller 保持一致方便 review。下面是我在订单服务里调库存服务的典型写法FeignClient(contextId stockClient, name stock-service, path /api/stock) public interface StockClient { PostMapping(/deduct) DeductResult deduct(RequestBody StockDeductDTO dto); }这段代码里有三个参数要注意。contextId用来给当前服务里同一个下游服务的多个 FeignClient 起不同的容器名否则启动会报 bean 冲突name必须和库存服务在 Nacos 注册中心里的服务名保持一致也就是库存服务里spring.application.namestock-servicepath是统一的前缀对应库存服务 Controller 类上的RequestMapping(/api/stock)。调用方只看到接口定义不关心库存服务是单机还是集群也不用知道它的数据库在哪这就是微服务架构里服务自治的基本要求。2.3 扣减库存用 Lua DB 条件更新回补走消息支付回调用本地消息表兜底服务之间拆开了一致性就成了新问题。最典型的是库存扣减秒杀场景下同一个 SKU 的并发扣减很容易超卖。我的方案是 Redis 和数据库双保险。Redis 里保存每个 SKU 的实时库存扣减用 Lua 脚本保证原子性-- KEYS[1]: stock:{skuId} -- ARGV[1]: 本次扣减数量 local stock tonumber(redis.call(get, KEYS[1]) or 0) local qty tonumber(ARGV[1]) if stock qty then redis.call(decrby, KEYS[1], qty) redis.call(incrby, KEYS[1] .. :sold, qty) return 1 end return 0这段脚本的意思是读取 Redis 里当前库存如果库存充足就一次性完成扣减并累计已售数量返回 1库存不足直接返回 0。Redis 单线程执行 Lua所以并发请求会排队执行不会出现两个线程同时读到库存 5、各扣 5 件导致超卖的问题。Redis 扣减成功后库存服务会发一条“库存已扣减”消息由订单服务在本地事务里更新订单状态如果最终用户取消订单再发一条“库存回补”消息库存服务收到后把 Redis 和数据库里的库存加回去。数据库层我不依赖 Redis 做最终依据而是用条件更新兜底UPDATE stock SET stock stock - #{qty}, version version 1 WHERE sku_id #{skuId} AND stock #{qty}这条 SQL 返回受影响行数如果为 0说明数据库里库存已经不足需要告警并触发人工介入。这么做的原因是 Redis 可能被清空或宕机数据库条件更新可以作为最后一道防线保证库存数据不会因为缓存丢失而错乱。支付回调的一致性更麻烦。微信支付回调到达支付中心后支付中心要改支付单状态订单中心要改订单状态两个动作跨两个服务。我不会在这种场景直接用 Seata 做全局事务太重且小程序商城链路长、参与方多全局锁容易拖垮支付回调。我一般用本地消息表在支付中心数据库里建一张payment_message表支付回调成功后支付单状态更新和“支付成功消息”写入在同一事务里提交然后一个定时任务把未发送的消息投递到 RocketMQ订单服务消费后做幂等处理。这样支付中心和订单中心各自保证本地事务消息至少投递一次消费端通过订单号和支付单号去重不会重复入账。3. 后端骨架落地Spring Cloud Alibaba 的最小可跑集群3.1 技术选型和版本匹配先定 Spring Boot 基线再引 BOM小程序商城后端我倾向于用 Spring Cloud Alibaba。原因有三个一是 Nacos 同时承担注册中心和配置中心国内团队普遍熟悉二是和 Spring Cloud Gateway、OpenFeign、Sentinel 组合成熟社区踩坑案例多三是项目需要对接微信支付、微信登录这些都是标准 HTTP JSON 接口Spring Cloud 的 MVC 风格天然匹配。如果单用 Dubbo网关层还要额外转换协议小程序端拿到的不是标准 RESTful 接口联调成本会更高。版本匹配是入门微服务最容易翻车的地方。Spring Boot、Spring Cloud、Spring Cloud Alibaba 三个版本必须对齐否则会出现服务注册不上、Feign 调用报错这类“玄学问题”。实际项目里我常用的稳定组合是Spring Boot 2.7.18、Spring Cloud 2021.0.5、Spring Cloud Alibaba 2021.0.5.0Nacos 服务端 2.2.3。pom 里不要逐一手写各组件版本直接引 BOMdependencyManagement dependencies dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-alibaba-dependencies/artifactId version2021.0.5.0/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement引入 BOM 之后项目里加 Nacos 注册中心、配置中心、OpenFeign 的依赖时都不需要再写version。Spring Cloud Alibaba 的 BOM 会把spring-cloud-starter-alibaba-nacos-discovery、spring-cloud-starter-alibaba-nacos-config、spring-cloud-starter-alibaba-sentinel的版本统一管起来。这里要特别提一句不要用一个很新的 Spring Boot 3.x 去配老的 Alibaba 版本网上很多启动报错都是版本错配导致的先把基线定死再写业务代码。3.2 用 docker 快速起 Nacos、MySQL、Redis三个命令搭出环境本地开发环境我一般用 docker 直接起中间件比手动下载安装包省事得多。Nacos 2.x 需要注意一点它除了 8848 的 HTTP 端口还开了 9848 的 gRPC 端口只映射 8848 会导致服务注册后 Nacos 控制台能看到但服务间调用一直超时。下面是我常用的命令docker run -d --name mysql8 -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDroot123 mysql:8.0 docker run -d --name redis7 -p 6379:6379 redis:7 docker run -d --name nacos -p 8848:8848 -p 9848:9848 \ -e MODEstandalone nacos/nacos-server:v2.2.3MySQL 连上之后记得改连接参数。Spring Boot 的 datasource URL 要带上characterEncodingutf8serverTimezoneAsia/Shanghai否则中文存进去乱码、时间差 8 小时这类问题会在联调时一起爆发。Redis 在小程序商城里不只是缓存它还承担了库存预扣、验证码存储、JWT 黑名单启动参数里最好加上--appendonly yes开启 AOF防止重启丢数据。3.3 注册中心与配置中心bootstrap.yml 里的三个必调参数每个服务启动时都要去 Nacos 注册和拉配置所以服务的bootstrap.yml要在一开始就配好。下面是商品服务的标准配置spring: application: name: product-service cloud: nacos: discovery: server-addr: 127.0.0.1:8848 namespace: mall-dev config: server-addr: 127.0.0.1:8848 namespace: mall-dev file-extension: yaml openfeign: client: config: default: connectTimeout: 3000 readTimeout: 5000这里我把namespace单独拎出来强调。同一个 Nacos 环境里dev、test、prod 一定要用不同 namespace 隔离否则每个服务会拉到别人环境的配置数据库连接串直接乱掉。spring.application.name必须和注册到 Nacos 的名字一致Feign 调用方就是靠这个名字做服务发现的。OpenFeign 的超时时间我习惯设置成连接超时 3 秒、读超时 5 秒配合fallback快速失败避免某个下游服务卡死后整个接口线程池被打满。这个超时值不是固定的——如果订单服务要调用商品服务查详情商品服务本身有缓存5 秒读超时够用如果是做的报表导出接口可能要单独调大到 30 秒。网关是另一个容易漏配置的地方。小程序端只会请求一个域名比如https://api.mall.comNginx 把请求转发给 Spring Cloud Gateway再由网关根据路由前缀转发到具体服务。网关里每个服务至少一个 routespring: cloud: gateway: routes: - id: product-route uri: lb://product-service predicates: - Path/api/product/** filters: - StripPrefix1 - id: order-route uri: lb://order-service predicates: - Path/api/order/** filters: - StripPrefix1lb://product-service表示网关通过 Nacos 负载均衡找到商品服务实例StripPrefix1会把/api/product前缀去掉再转发给商品服务。这样小程序端只记一个域名不需要知道后端拆了几个服务。注意网关服务本身也要注册到 Nacos否则lb://解析不到实例。4. 小程序端对接后端从微信登录到订单提交的关键路径4.1 小程序端选型uniapp 是当前成本最低的多端方案小程序商城的客户端我一般推荐用 uniapp而不是微信原生开发。原因很直接微信小程序、支付宝小程序、H5 三端共用一套基于 Vue 的代码HBuilderX 里可以一键打包到微信开发者工具日常调试也能直接在 H5 浏览器里做。商城类项目通常不会只用微信一端商家后续大概率要上支付宝小程序uniapp 的跨端收益在商城场景里最明显。用 uniapp 有一个坑要提前知道微信小程序对单包体积限制是 2MB而 uniapp 构建出来的包很容易因为引入 ui 组件库和图片超过限制。解决办法是开启分包加载把首页、商品列表、订单列表拆到不同分包tabBar 相关的页面放主包非 tabBar 页面进分包。字段命名上也要注意后端返回的字段如果叫page或size在部分微信基础库里会和框架内部变量冲突我一般约定分页参数叫pageNum/pageSize。4.2 微信登录态打通code2Session 在后端做前端只传 code小程序登录的完整链路是前端调用wx.login拿到临时 code把 code 传给后端登录接口后端拿着 code 去微信服务器调用jscode2session换取 openid 和 session_key后端生成自己的登录态 token 返回给前端。前端绝对不能用 code 当身份凭证直接访问业务接口因为 code 五分钟内就失效而且它是临时凭证不是身份凭证。前端登录代码uni.login({ provider: weixin, success: async ({ code }) { const res await request({ url: /user/login, method: POST, data: { code } }) uni.setStorageSync(token, res.data.token) } })后端/user/login接口收到 code 后通过HttpClient调用微信接口。常见做法是使用restTemplate或者 Hutool 的HttpUtil发送 GET 请求到https://api.weixin.qq.com/sns/jscode2session带上appid、secret、js_code、grant_typeauthorization_code四个参数。微信返回的openid是用户在当前小程序下的唯一标识后端拿着 openid 先查用户表不存在就自动注册一个会员存在就更新最近登录时间最终生成 JWT 返回。JWT 生成时有一个细节payload 里不要放 openid而是放一个随机生成的userId或uuidopenid 属于敏感信息而且后续如果接多端登录openid 可能变化但业务用户 ID 应该保持稳定。token 有效期我一般设 7 天小程序用户没有频繁换设备登录的习惯太短会反复弹登录。4.3 请求封装与列表加载更多token 携带、错误码和分页约定小程序端每个请求都要带上 token我做了一个统一的request.js封装不管是登录、商品列表还是提交订单都走这个方法const request ({ url, method GET, data }) { return new Promise((resolve, reject) { uni.request({ url: https://api.mall.com${url}, method, data, header: { Authorization: uni.getStorageSync(token) }, success(res) { if (res.data.code 0) { resolve(res.data) } else if (res.statusCode 401) { uni.navigateTo({ url: /pages/login/index }) } else { reject(res.data) } }, fail: reject }) }) } export const getProductList (pageNum, pageSize) request({ url: /product/list?pageNum${pageNum}pageSize${pageSize} })后端返回结构我统一用{ code: 0, data: ..., msg: ok }业务成功时code为 0。前端判断只要code 0就 resolve其他情况都算失败。401 由网关在 token 验证失败时返回前端收到 401 统一跳转登录页。列表加载更多时接口返回里必须带hasMore字段小程序端用onReachBottom触发下一页如果hasMorefalse停止加载并提示用户没有更多数据。后端分页查询注意一点offset 分页在数据量大时性能会急剧下降比如LIMIT 100000, 20MySQL 要把前十万行都扫一遍商城商品数过百万时推荐用id 上次最后一条id的方式做游标分页。4.4 提交订单与支付幂等键、预扣库存和回调验签用户提交订单的链路牵涉多个服务最容易出问题的是重复下单。前端在提交按钮点击后置灰是不够的用户快进快出网络卡顿请求可能重试两次后端就可能生成两笔订单。常见做法是前端生成一个clientOrderNo作为幂等键后端订单服务收到请求后查一下这个订单号是否已存在存在就直接返回已创建订单不重复创建。下单接口的典型流程是校验购物车、调商品服务批量查询 SKU 和价格、调库存服务预扣库存、同一个本地事务里创建订单主表和订单明细表。库存预扣成功后如果订单创建失败要把预扣的库存释放掉否则库存会越扣越少。这里我建议把“预扣库存”和“创建订单”放在同一事务边界里先扣库存再创建订单订单创建失败则调用库存回补接口。两个服务之间不可能用数据库事务就用补偿事务这也是微服务商城最常见的代码路径之一。支付阶段前端拿到后端统一下单返回的支付参数后调用wx.requestPaymentwx.requestPayment({ timeStamp: res.data.timeStamp, nonceStr: res.data.nonceStr, package: res.data.package, signType: RSA, paySign: res.data.paySign, success: () { uni.redirectTo({ url: /pages/order/detail?id orderId }) } })微信支付成功后的回调会打到后端配置的 notify 地址这个地址必须是 HTTPS 公网域名。支付中心收到回调后第一步用微信平台证书验签第二步比对支付单里的金额和订单金额是否一致第三步更新支付单状态并发送“支付成功”消息。回调接口要返回给微信固定的成功应答{code: SUCCESS}如果后端处理失败返回了其他内容微信会在短时间内重试回调。所以支付回调处理逻辑必须幂等同一个支付单被回调三次不能产生三笔流水。5. 微服务商城避坑跨服务事务、会话与缓存的高频故障排查5.1 现象下单后库存表分毫没扣Redis 库存却已经变成负数这个问题不止一次出现在商城联调环境里。订单服务调库存服务预扣接口Redis 扣减成功但库存服务发消息回补库存时因为 RocketMQ 消费失败数据库里根本没有扣过库存结果展示给用户的库存越来越多。原因有两层一层是 Redis 库存和数据库库存的同步不是实时的另一层是消息消费失败后没有可靠的补偿机制。解决方式分三步。第一库存流水表里记录每一笔预扣和回补Redis 扣减成功就写一条stock_flow流水第二定时任务每隔一分钟对比 Redis 库存和数据库库存发现差异就告警第三RocketMQ 消费失败的消息进入重试队列重试 3 次仍然失败就进入死信队列由人工脚本兜底处理。库存数据是钱必须接受“最终一致”而不是“实时一致”但要保证对得上账。5.2 现象小程序偶现白屏或 401网关日志提示 token 解析失败问题通常不是出在 token 本身而是出在微服务各自持有的密钥不一致。线上环境有四个服务跑在同一套 JWT 校验逻辑里如果每个服务环境变量里配的jwt.secret不一样网关签发 token 用 secret A商品服务校验用 secret B签名验签必然失败接口表现就是随机性 401。解决方式是统一配置管理。把jwt.secret放到 Nacos 配置中心而不是写死在每个服务的 application.yml 里。还要注意另一个坑网关校验完 token 后把用户信息放到 header 里向下游传递但 Feign 默认不会传递原始请求的 header导致订单服务拿到请求后不知道当前用户是谁。需要加一个 Feign 拦截器把用户 header 透传下去Bean public RequestInterceptor userHeaderInterceptor() { return template - { ServletRequestAttributes attrs (ServletRequestAttributes) RequestContextHolder.getRequestAttributes(); if (attrs ! null) { String userId attrs.getRequest().getHeader(X-User-Id); if (userId ! null) { template.header(X-User-Id, userId); } } }; }这段代码本质上是把当前请求上下文里的X-User-Id复制到 Feign 请求的 header 里。需要注意RequestContextHolder在 Hystrix 线程池模式下默认拿不到所以如果开了线程池隔离要么配hystrix.shareSecurityContext要么直接把用户 ID 作为 Feign 方法入参往下传后者更直观也更推荐。5.3 现象促销开始前缓存刚过期商品服务数据库连接池被打满商城上线第一天就出现过这个情况。运营在后台批量改了商品价格管理员手动清空了商品缓存结果一瞬间所有用户请求都穿透到 MySQL数据库连接数直接打满商品服务宕机。原因是缓存集中失效也就是常说的缓存雪崩。解决思路有两个层面。首先是缓存过期时间不要设置为固定值比如统一设置 30 分钟应该加一个随机扰动改为30分钟 random(0, 10分钟)让每个 SKU 的过期时间错开。其次是服务里做多级缓存商品列表和详情先用本地 Caffeine 缓存再查 Redis最后才落到 MySQL。Caffeine 可以用 5 分钟有效期Redis 用 30 分钟本地缓存的过期时间永远早于 Redis就算 Redis 中某些 key 失效了也只是部分请求穿透到 Redis不会直接打到数据库。如果商品信息变更需要立即生效接 MySQL binlog 同步更新 Redis 缓存而不是简单清掉所有缓存这个成本可控收益立竿见影。5.4 现象发版时支付回调打到正在关闭的实例导致部分订单支付状态丢失微服务滚动更新时旧实例还在处理支付回调新实例已经开始注册网关负载均衡可能把请求派发给一个正在执行 shutdown 的实例这个实例处理到一半进程退出支付单状态没落库。原因是没有做优雅下线。解决方式有两个关键点。第一在 Nacos 控制台先把该实例下线让它从服务列表摘除等存量请求处理完再停止进程第二Spring Cloud 服务里配置server.shutdowngraceful配合 Spring Boot 2.3进程收到 SIGTERM 信号后停止接收新请求但继续处理旧请求。Kubernetes 部署时还要给 Pod 加preStopSleep比如睡 10 秒再真正退出给注册中心留出下线传播时间。我用 k8s 部署时会在 deployment 里加lifecycle: preStop: exec: command: [sh, -c, sleep 10]这样 Nacos 能及时感知实例下线网关就不会再把新请求转发到正在终止的 Pod。6. 上线前压测与调优定位慢接口和热点库存的两个技巧6.1 压测链路与预期水位小程序商城上线前至少要压三个核心链路首页接口带商品缓存、商品详情带库存查询、下单带预扣库存和订单创建。压测工具我用 JMeter 模拟并发线程组设计成阶梯加压从 50 并发到 200 并发再到 500 并发每档跑 10 分钟观察错误率上升拐点。接口预期水位可以按这个表定目标接口目标 P95 响应时间目标错误率最大并发首页 Banner 分类 推荐商品300ms0.1%500商品详情命中 Redis 缓存200ms0.1%500提交订单含库存预扣800ms0.5%200微信支付回调500ms0.1%100压测前数据要贴近真实SKU 至少造 1 万条用户 10 万条历史订单 50 万条否则 MySQL 执行计划跑出来的性能和线上差别很大压测通过上线后照样出问题。6.2 慢查询定位从网关时间到 MySQL 慢日志逐层拆压测出现超时时我的排查顺序是固定的先看网关日志里每个接口的响应时间分布定位是哪一个服务拖慢再进服务查看慢调用链路最后打开 MySQL 慢日志。MySQL 慢日志默认是关闭的压测前先开SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 0.5;long_query_time0.5表示超过 500ms 的 SQL 都会被记录到慢查询日志中。压测跑完看慢日志前几个出现频率高的 SQL 基本就能定位到问题。商城最常见的慢 SQL 是订单列表按用户分页查询订单表数据量上来后ORDER BY create_time DESC LIMIT offset, size非常容易慢优化方式是在create_time和user_id上建联合索引并且使用覆盖索引只查需要的字段避免回表。6.3 热点 SKU 的库存隔离分段预扣加 Sentinel 热点限流最后一个技巧是处理促销爆款。商品详情页里的库存查询如果每次走 Redis 都行但秒杀场景下同一个 SKU 的扣减请求会瞬时暴增。我会在库存服务里对秒杀 SKU 做热点识别预热时把库存拆成两段一段是日常库存一段是秒杀专用库存。秒杀库存独立预扣到 Redis同时用 Sentinel 给同一个 SKU 加热点参数限流按照商品 ID 维度限制每秒不超过 100 次扣减请求超出的直接返回“抢购太火爆”不继续往下压数据库。Sentinel 热点限流的配置不用写代码控制台里就能配但要在服务里引入依赖并且接上 Nacos 持久化。核心规则是resource指定为库存服务扣减接口名参数索引 1 对应 SKU ID单机阈值 100统计窗口 1 秒。这套配置上线前一定要在压测环境验证很多人把阈值拍脑袋填了 10结果秒杀刚开始用户就看到“活动太火爆”投诉反而不降反升。压测时根据实际场景调这个数字逐步放开。做微服务商城之后的感受是每次发布前都过一遍“登录态、库存扣减、支付回调”这条主链路总能在细节里救回一次线上故障。希望这些整理对你有帮助也欢迎你带着踩坑记录再来交流。本文还有配套的精品资源点击获取 基于微服务的小程序商城系统落地实践
简介面向微信小程序电商开发者的技术资料包围绕“基于微服务的小程序商城系统”展开系统讲解用户中心、商品中心、订单中心、支付中心等核心模块的职责与协作方式并延伸到微信端入口、商家管理平台以及服务治理、监控追踪等工程实践适合有一定后端基础、正在规划或维护小程序商城项目的初中级开发者学习参考。资源以ZIP压缩包形式提供包体约58.77MB目前源站未公开文件总数与具体类型需下载后查看结合主题判断内容应侧重架构设计思路与核心流程说明而非完整可运行的一整套源码。已有367人浏览学习。通过这份资料读者可以理解微服务拆分如何提升电商系统的扩展性与可靠性掌握从商品管理、购物车、订单到支付闭环的关键设计方法并借助其中的模块划分、服务治理和监控思路应用到自身项目的架构评审或方案落地中对技术选型和项目复盘都有一定借鉴价值。1. 基于微服务的小程序商城这不只是把接口拆开一个日活几千的商城单体会在什么时候开始崩溃我在接手一个微信小程序商城项目时发现最初版的 PHP 后端接口已经在促销期不断超时支付回调排队商品详情接口一次要查三张表。团队决定基于微服务重构目标不是“把单体接口拆开”这么浅而是按业务边界切出商品、库存、订单、支付、用户几个独立服务让小程序端只访问一个 API 网关域名后端各自扩缩容、各自隔离故障。这就是“基于微服务的小程序商城系统”真正要落地的事给依赖微信生态的商城套上一个能扛峰值、能独立迭代的后端底座。这篇文章面向正在做商城后端拆分的技术负责人也适合从 0 到 1 建商城、准备用 uniapp 做小程序前端的全栈工程师。我会按照服务划分、骨架搭建、微信登录联调、支付与库存对账、避坑和压测这条路径往下讲每一层都给到可以直接落地的参数和执行步骤。2. 服务边界怎么划按业务域切分别把接口也当成服务2.1 一个商城至少拆六个服务但库存必须是独立服务微服务拆分的第一步不是写代码是把业务边界划清楚。我在实际做小程序商城时最常用的划分是按业务域拆成六个中心用户中心、商品中心、库存中心、订单中心、支付中心、营销中心。小程序商城的典型页面是首页、分类、商品详情、购物车、下单、支付、我的这些页面背后调用的接口分别落在不同的服务里服务之间通过 HTTP 接口互相取数而不是共享同一个数据库。服务核心职责主要表对外接口前缀用户中心微信登录态、会员信息、收货地址member / member_address/api/user商品中心商品分类、SPU / SKU 信息、详情页内容spu / sku / category / banner/api/product库存中心SKU 实时库存、预扣与回补、库存流水stock / stock_flow/api/stock订单中心购物车、订单创建、订单状态机、售后cart / order_info / order_item/api/order支付中心支付单、微信支付回调、退款payment / refund/api/pay营销中心优惠券、秒杀活动、拼团配置coupon / activity / seckill/api/marketing为什么库存一定要独立成一个服务因为小程序商城秒杀和促销场景下库存服务会被高频调用而且它的写压力和商品详情、订单创建的写压力不是一回事。库存服务独立出来后可以单独给它的 Redis 配置更高的内存单独给库存接口做限流出了问题也只需要回滚库存这一条链路不会把商品详情和订单一起拖崩。这里有一个反例之前有团队把优惠券拆成了领券、用券、维权三个服务结果一次下单校验要跨三个服务查四次接口耗时直接到 800ms。商城起步阶段六个服务就是合理粒度再细就是给自己找麻烦。2.2 服务间只通过 API 交互拒绝跨库 join 和直接查别人库服务划分好之后最难执行的是数据边界。我做代码评审时第一条红线就是不允许订单服务直接连商品中心的库去查 SKU 名称和价格不允许支付中心直接改订单表的支付状态。跨服务的数据诉求一律通过提供方暴露的接口来完成。订单回显商品名时订单服务调用商品中心的“批量查询 SKU 信息”接口下单扣减库存时订单服务调用库存中心的“扣减库存”接口支付成功之后支付中心通过 RocketMQ 发一条“支付成功”消息订单服务订阅后自己更新订单状态。跨服务调用在 Spring Cloud Alibaba 里最常用的方式是 OpenFeign。我一般会为每个下游服务定义一个 FeignClient接口签名和下游 Controller 保持一致方便 review。下面是我在订单服务里调库存服务的典型写法FeignClient(contextId stockClient, name stock-service, path /api/stock) public interface StockClient { PostMapping(/deduct) DeductResult deduct(RequestBody StockDeductDTO dto); }这段代码里有三个参数要注意。contextId用来给当前服务里同一个下游服务的多个 FeignClient 起不同的容器名否则启动会报 bean 冲突name必须和库存服务在 Nacos 注册中心里的服务名保持一致也就是库存服务里spring.application.namestock-servicepath是统一的前缀对应库存服务 Controller 类上的RequestMapping(/api/stock)。调用方只看到接口定义不关心库存服务是单机还是集群也不用知道它的数据库在哪这就是微服务架构里服务自治的基本要求。2.3 扣减库存用 Lua DB 条件更新回补走消息支付回调用本地消息表兜底服务之间拆开了一致性就成了新问题。最典型的是库存扣减秒杀场景下同一个 SKU 的并发扣减很容易超卖。我的方案是 Redis 和数据库双保险。Redis 里保存每个 SKU 的实时库存扣减用 Lua 脚本保证原子性-- KEYS[1]: stock:{skuId} -- ARGV[1]: 本次扣减数量 local stock tonumber(redis.call(get, KEYS[1]) or 0) local qty tonumber(ARGV[1]) if stock qty then redis.call(decrby, KEYS[1], qty) redis.call(incrby, KEYS[1] .. :sold, qty) return 1 end return 0这段脚本的意思是读取 Redis 里当前库存如果库存充足就一次性完成扣减并累计已售数量返回 1库存不足直接返回 0。Redis 单线程执行 Lua所以并发请求会排队执行不会出现两个线程同时读到库存 5、各扣 5 件导致超卖的问题。Redis 扣减成功后库存服务会发一条“库存已扣减”消息由订单服务在本地事务里更新订单状态如果最终用户取消订单再发一条“库存回补”消息库存服务收到后把 Redis 和数据库里的库存加回去。数据库层我不依赖 Redis 做最终依据而是用条件更新兜底UPDATE stock SET stock stock - #{qty}, version version 1 WHERE sku_id #{skuId} AND stock #{qty}这条 SQL 返回受影响行数如果为 0说明数据库里库存已经不足需要告警并触发人工介入。这么做的原因是 Redis 可能被清空或宕机数据库条件更新可以作为最后一道防线保证库存数据不会因为缓存丢失而错乱。支付回调的一致性更麻烦。微信支付回调到达支付中心后支付中心要改支付单状态订单中心要改订单状态两个动作跨两个服务。我不会在这种场景直接用 Seata 做全局事务太重且小程序商城链路长、参与方多全局锁容易拖垮支付回调。我一般用本地消息表在支付中心数据库里建一张payment_message表支付回调成功后支付单状态更新和“支付成功消息”写入在同一事务里提交然后一个定时任务把未发送的消息投递到 RocketMQ订单服务消费后做幂等处理。这样支付中心和订单中心各自保证本地事务消息至少投递一次消费端通过订单号和支付单号去重不会重复入账。3. 后端骨架落地Spring Cloud Alibaba 的最小可跑集群3.1 技术选型和版本匹配先定 Spring Boot 基线再引 BOM小程序商城后端我倾向于用 Spring Cloud Alibaba。原因有三个一是 Nacos 同时承担注册中心和配置中心国内团队普遍熟悉二是和 Spring Cloud Gateway、OpenFeign、Sentinel 组合成熟社区踩坑案例多三是项目需要对接微信支付、微信登录这些都是标准 HTTP JSON 接口Spring Cloud 的 MVC 风格天然匹配。如果单用 Dubbo网关层还要额外转换协议小程序端拿到的不是标准 RESTful 接口联调成本会更高。版本匹配是入门微服务最容易翻车的地方。Spring Boot、Spring Cloud、Spring Cloud Alibaba 三个版本必须对齐否则会出现服务注册不上、Feign 调用报错这类“玄学问题”。实际项目里我常用的稳定组合是Spring Boot 2.7.18、Spring Cloud 2021.0.5、Spring Cloud Alibaba 2021.0.5.0Nacos 服务端 2.2.3。pom 里不要逐一手写各组件版本直接引 BOMdependencyManagement dependencies dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-alibaba-dependencies/artifactId version2021.0.5.0/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement引入 BOM 之后项目里加 Nacos 注册中心、配置中心、OpenFeign 的依赖时都不需要再写version。Spring Cloud Alibaba 的 BOM 会把spring-cloud-starter-alibaba-nacos-discovery、spring-cloud-starter-alibaba-nacos-config、spring-cloud-starter-alibaba-sentinel的版本统一管起来。这里要特别提一句不要用一个很新的 Spring Boot 3.x 去配老的 Alibaba 版本网上很多启动报错都是版本错配导致的先把基线定死再写业务代码。3.2 用 docker 快速起 Nacos、MySQL、Redis三个命令搭出环境本地开发环境我一般用 docker 直接起中间件比手动下载安装包省事得多。Nacos 2.x 需要注意一点它除了 8848 的 HTTP 端口还开了 9848 的 gRPC 端口只映射 8848 会导致服务注册后 Nacos 控制台能看到但服务间调用一直超时。下面是我常用的命令docker run -d --name mysql8 -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDroot123 mysql:8.0 docker run -d --name redis7 -p 6379:6379 redis:7 docker run -d --name nacos -p 8848:8848 -p 9848:9848 \ -e MODEstandalone nacos/nacos-server:v2.2.3MySQL 连上之后记得改连接参数。Spring Boot 的 datasource URL 要带上characterEncodingutf8serverTimezoneAsia/Shanghai否则中文存进去乱码、时间差 8 小时这类问题会在联调时一起爆发。Redis 在小程序商城里不只是缓存它还承担了库存预扣、验证码存储、JWT 黑名单启动参数里最好加上--appendonly yes开启 AOF防止重启丢数据。3.3 注册中心与配置中心bootstrap.yml 里的三个必调参数每个服务启动时都要去 Nacos 注册和拉配置所以服务的bootstrap.yml要在一开始就配好。下面是商品服务的标准配置spring: application: name: product-service cloud: nacos: discovery: server-addr: 127.0.0.1:8848 namespace: mall-dev config: server-addr: 127.0.0.1:8848 namespace: mall-dev file-extension: yaml openfeign: client: config: default: connectTimeout: 3000 readTimeout: 5000这里我把namespace单独拎出来强调。同一个 Nacos 环境里dev、test、prod 一定要用不同 namespace 隔离否则每个服务会拉到别人环境的配置数据库连接串直接乱掉。spring.application.name必须和注册到 Nacos 的名字一致Feign 调用方就是靠这个名字做服务发现的。OpenFeign 的超时时间我习惯设置成连接超时 3 秒、读超时 5 秒配合fallback快速失败避免某个下游服务卡死后整个接口线程池被打满。这个超时值不是固定的——如果订单服务要调用商品服务查详情商品服务本身有缓存5 秒读超时够用如果是做的报表导出接口可能要单独调大到 30 秒。网关是另一个容易漏配置的地方。小程序端只会请求一个域名比如https://api.mall.comNginx 把请求转发给 Spring Cloud Gateway再由网关根据路由前缀转发到具体服务。网关里每个服务至少一个 routespring: cloud: gateway: routes: - id: product-route uri: lb://product-service predicates: - Path/api/product/** filters: - StripPrefix1 - id: order-route uri: lb://order-service predicates: - Path/api/order/** filters: - StripPrefix1lb://product-service表示网关通过 Nacos 负载均衡找到商品服务实例StripPrefix1会把/api/product前缀去掉再转发给商品服务。这样小程序端只记一个域名不需要知道后端拆了几个服务。注意网关服务本身也要注册到 Nacos否则lb://解析不到实例。4. 小程序端对接后端从微信登录到订单提交的关键路径4.1 小程序端选型uniapp 是当前成本最低的多端方案小程序商城的客户端我一般推荐用 uniapp而不是微信原生开发。原因很直接微信小程序、支付宝小程序、H5 三端共用一套基于 Vue 的代码HBuilderX 里可以一键打包到微信开发者工具日常调试也能直接在 H5 浏览器里做。商城类项目通常不会只用微信一端商家后续大概率要上支付宝小程序uniapp 的跨端收益在商城场景里最明显。用 uniapp 有一个坑要提前知道微信小程序对单包体积限制是 2MB而 uniapp 构建出来的包很容易因为引入 ui 组件库和图片超过限制。解决办法是开启分包加载把首页、商品列表、订单列表拆到不同分包tabBar 相关的页面放主包非 tabBar 页面进分包。字段命名上也要注意后端返回的字段如果叫page或size在部分微信基础库里会和框架内部变量冲突我一般约定分页参数叫pageNum/pageSize。4.2 微信登录态打通code2Session 在后端做前端只传 code小程序登录的完整链路是前端调用wx.login拿到临时 code把 code 传给后端登录接口后端拿着 code 去微信服务器调用jscode2session换取 openid 和 session_key后端生成自己的登录态 token 返回给前端。前端绝对不能用 code 当身份凭证直接访问业务接口因为 code 五分钟内就失效而且它是临时凭证不是身份凭证。前端登录代码uni.login({ provider: weixin, success: async ({ code }) { const res await request({ url: /user/login, method: POST, data: { code } }) uni.setStorageSync(token, res.data.token) } })后端/user/login接口收到 code 后通过HttpClient调用微信接口。常见做法是使用restTemplate或者 Hutool 的HttpUtil发送 GET 请求到https://api.weixin.qq.com/sns/jscode2session带上appid、secret、js_code、grant_typeauthorization_code四个参数。微信返回的openid是用户在当前小程序下的唯一标识后端拿着 openid 先查用户表不存在就自动注册一个会员存在就更新最近登录时间最终生成 JWT 返回。JWT 生成时有一个细节payload 里不要放 openid而是放一个随机生成的userId或uuidopenid 属于敏感信息而且后续如果接多端登录openid 可能变化但业务用户 ID 应该保持稳定。token 有效期我一般设 7 天小程序用户没有频繁换设备登录的习惯太短会反复弹登录。4.3 请求封装与列表加载更多token 携带、错误码和分页约定小程序端每个请求都要带上 token我做了一个统一的request.js封装不管是登录、商品列表还是提交订单都走这个方法const request ({ url, method GET, data }) { return new Promise((resolve, reject) { uni.request({ url: https://api.mall.com${url}, method, data, header: { Authorization: uni.getStorageSync(token) }, success(res) { if (res.data.code 0) { resolve(res.data) } else if (res.statusCode 401) { uni.navigateTo({ url: /pages/login/index }) } else { reject(res.data) } }, fail: reject }) }) } export const getProductList (pageNum, pageSize) request({ url: /product/list?pageNum${pageNum}pageSize${pageSize} })后端返回结构我统一用{ code: 0, data: ..., msg: ok }业务成功时code为 0。前端判断只要code 0就 resolve其他情况都算失败。401 由网关在 token 验证失败时返回前端收到 401 统一跳转登录页。列表加载更多时接口返回里必须带hasMore字段小程序端用onReachBottom触发下一页如果hasMorefalse停止加载并提示用户没有更多数据。后端分页查询注意一点offset 分页在数据量大时性能会急剧下降比如LIMIT 100000, 20MySQL 要把前十万行都扫一遍商城商品数过百万时推荐用id 上次最后一条id的方式做游标分页。4.4 提交订单与支付幂等键、预扣库存和回调验签用户提交订单的链路牵涉多个服务最容易出问题的是重复下单。前端在提交按钮点击后置灰是不够的用户快进快出网络卡顿请求可能重试两次后端就可能生成两笔订单。常见做法是前端生成一个clientOrderNo作为幂等键后端订单服务收到请求后查一下这个订单号是否已存在存在就直接返回已创建订单不重复创建。下单接口的典型流程是校验购物车、调商品服务批量查询 SKU 和价格、调库存服务预扣库存、同一个本地事务里创建订单主表和订单明细表。库存预扣成功后如果订单创建失败要把预扣的库存释放掉否则库存会越扣越少。这里我建议把“预扣库存”和“创建订单”放在同一事务边界里先扣库存再创建订单订单创建失败则调用库存回补接口。两个服务之间不可能用数据库事务就用补偿事务这也是微服务商城最常见的代码路径之一。支付阶段前端拿到后端统一下单返回的支付参数后调用wx.requestPaymentwx.requestPayment({ timeStamp: res.data.timeStamp, nonceStr: res.data.nonceStr, package: res.data.package, signType: RSA, paySign: res.data.paySign, success: () { uni.redirectTo({ url: /pages/order/detail?id orderId }) } })微信支付成功后的回调会打到后端配置的 notify 地址这个地址必须是 HTTPS 公网域名。支付中心收到回调后第一步用微信平台证书验签第二步比对支付单里的金额和订单金额是否一致第三步更新支付单状态并发送“支付成功”消息。回调接口要返回给微信固定的成功应答{code: SUCCESS}如果后端处理失败返回了其他内容微信会在短时间内重试回调。所以支付回调处理逻辑必须幂等同一个支付单被回调三次不能产生三笔流水。5. 微服务商城避坑跨服务事务、会话与缓存的高频故障排查5.1 现象下单后库存表分毫没扣Redis 库存却已经变成负数这个问题不止一次出现在商城联调环境里。订单服务调库存服务预扣接口Redis 扣减成功但库存服务发消息回补库存时因为 RocketMQ 消费失败数据库里根本没有扣过库存结果展示给用户的库存越来越多。原因有两层一层是 Redis 库存和数据库库存的同步不是实时的另一层是消息消费失败后没有可靠的补偿机制。解决方式分三步。第一库存流水表里记录每一笔预扣和回补Redis 扣减成功就写一条stock_flow流水第二定时任务每隔一分钟对比 Redis 库存和数据库库存发现差异就告警第三RocketMQ 消费失败的消息进入重试队列重试 3 次仍然失败就进入死信队列由人工脚本兜底处理。库存数据是钱必须接受“最终一致”而不是“实时一致”但要保证对得上账。5.2 现象小程序偶现白屏或 401网关日志提示 token 解析失败问题通常不是出在 token 本身而是出在微服务各自持有的密钥不一致。线上环境有四个服务跑在同一套 JWT 校验逻辑里如果每个服务环境变量里配的jwt.secret不一样网关签发 token 用 secret A商品服务校验用 secret B签名验签必然失败接口表现就是随机性 401。解决方式是统一配置管理。把jwt.secret放到 Nacos 配置中心而不是写死在每个服务的 application.yml 里。还要注意另一个坑网关校验完 token 后把用户信息放到 header 里向下游传递但 Feign 默认不会传递原始请求的 header导致订单服务拿到请求后不知道当前用户是谁。需要加一个 Feign 拦截器把用户 header 透传下去Bean public RequestInterceptor userHeaderInterceptor() { return template - { ServletRequestAttributes attrs (ServletRequestAttributes) RequestContextHolder.getRequestAttributes(); if (attrs ! null) { String userId attrs.getRequest().getHeader(X-User-Id); if (userId ! null) { template.header(X-User-Id, userId); } } }; }这段代码本质上是把当前请求上下文里的X-User-Id复制到 Feign 请求的 header 里。需要注意RequestContextHolder在 Hystrix 线程池模式下默认拿不到所以如果开了线程池隔离要么配hystrix.shareSecurityContext要么直接把用户 ID 作为 Feign 方法入参往下传后者更直观也更推荐。5.3 现象促销开始前缓存刚过期商品服务数据库连接池被打满商城上线第一天就出现过这个情况。运营在后台批量改了商品价格管理员手动清空了商品缓存结果一瞬间所有用户请求都穿透到 MySQL数据库连接数直接打满商品服务宕机。原因是缓存集中失效也就是常说的缓存雪崩。解决思路有两个层面。首先是缓存过期时间不要设置为固定值比如统一设置 30 分钟应该加一个随机扰动改为30分钟 random(0, 10分钟)让每个 SKU 的过期时间错开。其次是服务里做多级缓存商品列表和详情先用本地 Caffeine 缓存再查 Redis最后才落到 MySQL。Caffeine 可以用 5 分钟有效期Redis 用 30 分钟本地缓存的过期时间永远早于 Redis就算 Redis 中某些 key 失效了也只是部分请求穿透到 Redis不会直接打到数据库。如果商品信息变更需要立即生效接 MySQL binlog 同步更新 Redis 缓存而不是简单清掉所有缓存这个成本可控收益立竿见影。5.4 现象发版时支付回调打到正在关闭的实例导致部分订单支付状态丢失微服务滚动更新时旧实例还在处理支付回调新实例已经开始注册网关负载均衡可能把请求派发给一个正在执行 shutdown 的实例这个实例处理到一半进程退出支付单状态没落库。原因是没有做优雅下线。解决方式有两个关键点。第一在 Nacos 控制台先把该实例下线让它从服务列表摘除等存量请求处理完再停止进程第二Spring Cloud 服务里配置server.shutdowngraceful配合 Spring Boot 2.3进程收到 SIGTERM 信号后停止接收新请求但继续处理旧请求。Kubernetes 部署时还要给 Pod 加preStopSleep比如睡 10 秒再真正退出给注册中心留出下线传播时间。我用 k8s 部署时会在 deployment 里加lifecycle: preStop: exec: command: [sh, -c, sleep 10]这样 Nacos 能及时感知实例下线网关就不会再把新请求转发到正在终止的 Pod。6. 上线前压测与调优定位慢接口和热点库存的两个技巧6.1 压测链路与预期水位小程序商城上线前至少要压三个核心链路首页接口带商品缓存、商品详情带库存查询、下单带预扣库存和订单创建。压测工具我用 JMeter 模拟并发线程组设计成阶梯加压从 50 并发到 200 并发再到 500 并发每档跑 10 分钟观察错误率上升拐点。接口预期水位可以按这个表定目标接口目标 P95 响应时间目标错误率最大并发首页 Banner 分类 推荐商品300ms0.1%500商品详情命中 Redis 缓存200ms0.1%500提交订单含库存预扣800ms0.5%200微信支付回调500ms0.1%100压测前数据要贴近真实SKU 至少造 1 万条用户 10 万条历史订单 50 万条否则 MySQL 执行计划跑出来的性能和线上差别很大压测通过上线后照样出问题。6.2 慢查询定位从网关时间到 MySQL 慢日志逐层拆压测出现超时时我的排查顺序是固定的先看网关日志里每个接口的响应时间分布定位是哪一个服务拖慢再进服务查看慢调用链路最后打开 MySQL 慢日志。MySQL 慢日志默认是关闭的压测前先开SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 0.5;long_query_time0.5表示超过 500ms 的 SQL 都会被记录到慢查询日志中。压测跑完看慢日志前几个出现频率高的 SQL 基本就能定位到问题。商城最常见的慢 SQL 是订单列表按用户分页查询订单表数据量上来后ORDER BY create_time DESC LIMIT offset, size非常容易慢优化方式是在create_time和user_id上建联合索引并且使用覆盖索引只查需要的字段避免回表。6.3 热点 SKU 的库存隔离分段预扣加 Sentinel 热点限流最后一个技巧是处理促销爆款。商品详情页里的库存查询如果每次走 Redis 都行但秒杀场景下同一个 SKU 的扣减请求会瞬时暴增。我会在库存服务里对秒杀 SKU 做热点识别预热时把库存拆成两段一段是日常库存一段是秒杀专用库存。秒杀库存独立预扣到 Redis同时用 Sentinel 给同一个 SKU 加热点参数限流按照商品 ID 维度限制每秒不超过 100 次扣减请求超出的直接返回“抢购太火爆”不继续往下压数据库。Sentinel 热点限流的配置不用写代码控制台里就能配但要在服务里引入依赖并且接上 Nacos 持久化。核心规则是resource指定为库存服务扣减接口名参数索引 1 对应 SKU ID单机阈值 100统计窗口 1 秒。这套配置上线前一定要在压测环境验证很多人把阈值拍脑袋填了 10结果秒杀刚开始用户就看到“活动太火爆”投诉反而不降反升。压测时根据实际场景调这个数字逐步放开。做微服务商城之后的感受是每次发布前都过一遍“登录态、库存扣减、支付回调”这条主链路总能在细节里救回一次线上故障。希望这些整理对你有帮助也欢迎你带着踩坑记录再来交流。本文还有配套的精品资源点击获取