最近把一个电子数码产品租赁系统从单体架构拆成了微服务技术栈是 SpringBoot SpringCloud Vue 微信小程序。这套系统主要服务的是数码产品的在线租赁场景覆盖手机、平板、相机、无人机、游戏机这类高价值设备。用户在微信小程序里浏览、下单、支付押金管理员在 Vue 管理后台处理订单、管理库存、跟踪设备状态。整体拆分为用户服务、商品服务、订单服务、支付服务、库存服务、消息服务等核心模块用 SpringCloud 做服务治理Nacos 做注册与配置中心前端管理端用 Vue3 Element Plus小程序端用微信原生框架。算下来从需求确认到第一版上线前后大概用了三个多月。其中最折腾人的不是业务逻辑本身而是微服务拆分后的数据一致性、小程序端与后端的联调、以及本地与线上环境的配置管理。这篇就把这套系统的架构思路、核心模块拆解、关键实现和踩坑过程完整梳理一遍准备做类似系统的朋友可以直接拿来参考。1. 项目整体设计与技术选型思路1.1 为什么数码租赁系统需要微服务架构说实话一个租赁系统如果只服务一个小门店单体架构完全够用SpringBoot 加一个 MySQL 就解决了。但电子数码租赁有几个天然特点决定了它值得上微服务第一设备品类多、SKU 维度复杂。手机有品牌、型号、存储、颜色、成色等级每台设备有唯一序列号。租出去一台就要锁库存归还后要检测、维修、重新上架。这个生命周期比普通电商复杂得多。第二订单流程特别长。从下单、押金支付、发货、签收、使用中、归还、检测、退款、开票状态节点多而且涉及库存锁定、租金计算、逾期费用、损坏赔偿等多套规则。第三业务场景天然分离。商品浏览和搜索面向 C 端用户压力集中库存管理面向运营人员操作频繁支付和财务对稳定性要求高设备追踪和风控是独立逻辑。这些模块放在一起任何一个出问题都会互相牵连。第四团队协作和后续维护。微服务拆分后每个服务独立部署、独立扩缩容。商品服务挂了不影响订单服务运营后台的高频操作不会干扰用户端浏览。第五押金与支付安全要求很高。押金不是最终收入涉及冻结、退还、抵扣多步操作资金流程一旦混乱代价非常大。微服务的隔离性让资金相关服务可以单独监控、单独预警出现问题可以快速定位到具体服务。当然微服务不是银弹它带来的复杂度也是实实在在的服务间通信、分布式事务、配置管理、日志追踪、环境一致性这些在单体时代根本不需要操心。选择微服务的前提是团队对 SpringCloud 生态比较熟悉或者愿意投入时间去搭建基础设施。如果只是验证业务模型建议先从模块化单体做起等业务量上来了再拆分也不迟。1.2 技术栈选型的组合逻辑这套系统的核心技术栈是 SpringBoot 3.x SpringCloud 2023 Nacos Vue3 Element Plus 微信原生小程序 MySQL Redis MinIO。SpringBoot 负责业务服务的快速搭建内置容器、自动配置、健康检查减少大量样板代码。SpringCloud 负责服务治理层包括注册发现、负载均衡、熔断降级、网关路由。Nacos 同时承担注册中心和配置中心两个角色避免再引入一套外部依赖。前端管理端选 Vue3 Element Plus是因为 Vue 组件生态成熟后台管理的表格、表单、弹窗、权限菜单都有现成组件Element Plus 的中文文档和社区案例非常丰富做运营后台这类 CRUD 密集型的系统效率很高。新项目直接用 Vue3组合式 API 写起来比 Options API 舒服很多数据响应式也更可控。小程序端选了微信原生框架没有引入 uni-app 这类跨端框架。原因是我们只需要服务微信生态原生框架性能最稳微信登录和支付能力接入最简单。如果后续要扩展抖音小程序、支付宝小程序再考虑用 uni-app 重构现阶段不做过度设计。文件存储用了 MinIO 自建存放设备图片、用户上传的凭证图片、租赁合同 PDF。电商类系统图片量很大MinIO 支持桶权限控制和预签名 URL配合 Nginx 可以做静态资源加速成本比直接上云 OSS 低不少尤其适合中小团队。这里说明一下为什么没用 RabbitMQ而是先用 Redis Stream 做消息队列。租赁系统的消息量不算大主要是订单状态变更后的通知类事件Redis Stream 完全够用而且少维护一套中间件。但如果你预计业务量会快速增长订单创建、支付回调、库存扣减这些链路建议直接上 RabbitMQ有完整的消息确认和重试机制省得后面再迁移。2. 微服务拆分与核心业务模块设计2.1 服务拆分边界与领域模型按业务能力维度拆分这套系统分成了六个核心服务user-service用户注册登录、会员等级、实名认证、押金账户管理product-service设备 SKU 管理、库存管理、上下架、分类、产品图片order-service租赁订单、订单状态流转、续租、归还登记payment-service押金支付与退还、租金支付、退款、账单流水settlement-service财务结算、平台与商户分成涉及合作方租赁场景notification-service短信通知、小程序订阅消息、邮件发送每个服务对应一个独立的数据库这是微服务拆分中最重要的一条原则数据库不能共享。如果服务之间共用同一个库表面上是微服务实际还是单体服务治理的优势完全发挥不出来。我在项目初期踩过这个坑一开始为了省事让订单服务和支付服务共用一个库结果订单表膨胀之后支付查询也变慢两个服务互相影响后面才拆库迁移代价不小。跨服务查询的场景比如查某个用户的订单列表常见方案是在订单服务里冗余一份 userId 和用户快照信息昵称、头像而不是每次实时调用用户服务。订单服务在创建订单时从用户服务获取用户信息做冗余存储后续展示订单列表时零跨服务调用性能好很多。商品与订单之间也是同样思路订单里保存下单那一刻的商品快照——商品名称、规格参数、日租金、图片 URL、押金金额直接存在订单表里。设备归还后商品信息变了订单快照不受影响这对租赁系统的财务审计非常重要。服务间通信方面同步调用用 OpenFeign异步事件用 Redis Stream。比如下单流程里的库存锁定是异步的但必须保证最终一致性。创建订单后发一个 StockLock 事件到 Redis Stream商品服务消费后锁定库存如果锁定失败会发回滚事件取消订单。2.2 核心业务链路与数据一致性方案租赁系统的核心链路是用户提交订单 - 锁定库存 - 创建租赁订单 - 计算押金和首期租金 - 发起支付 - 支付成功 - 推送订单通知 - 仓库发货这条链路跨了商品、订单、支付三个服务绝对不能用一个大的本地事务包住必须用分布式事务方案。实际实践中我没有选用 Seata 的 AT 模式因为租赁系统的资金环节更倾向于可靠消息 本地消息表这个模式简单可控理解成本低依赖也少。具体做法是这样的订单服务在创建订单的本地事务里同时写一条待确认消息到本地消息表然后把库存锁定事件发布到 Redis Stream。商品服务消费事件后锁定库存并写本地记录处理成功后发送确认消息。订单服务的定时任务会扫描本地消息表超过一定时间没有收到确认的事件就重新发送配合人工兜底排查。这套方案不需要额外部署事务协调器出问题时也容易定位。库存锁定与真实扣减要做严格区分。用户下单时锁库存支付成功后真正扣减。如果用户超时未支付订单自动取消并释放库存。归还流程则是用户提交归还申请 - 仓库收货 - 设备检测 - 根据检测结果计算费用是否有损坏、是否超期- 退还押金。整个归还链路同样是异步事件驱动的每一步都写审计日志方便后续追溯。还有一个容易忽略但非常重要的点租金计算。日租金乘以租赁天数看似简单实际要处理首日不满一天、取整规则、节假日活动价、会员折扣、逾期费率阶梯超过 1 天按双倍日租金超过 7 天按买断价处理这些情况。这部分的规则逻辑我抽成了一个独立的 PriceCalculator 组件放在 order-service 内部所有价格计算集中管理避免散落在各个业务方法里。每一条价格规则的变更都走配置中心下发不需要重启服务。3. 小程序端与 Vue 管理端的双端联动实现3.1 小程序端租赁流程与核心页面拆解小程序承担的是 C 端用户的完整闭环登录、浏览商品、查看详情、下单、支付、租赁中管理、申请归还、押金进度查询。首页设计没有做复杂的东西顶部搜索框 分类导航手机、平板、相机、无人机、游戏机 推荐设备流。设备卡片突出显示日租金、押金、设备成色标签用户最关心的就是这三个信息其他信息先不展示。详情页核心是设备的参数列表、租金价格区间按租期长度分段计价、押金规则、租后服务说明。下单流程里的关键细节是押金计算和租赁时间选择。押金不等于商品价格它是商品价值的某个比例由运营后台按 SKU 灵活配置通常在 10% 到 30% 之间。租赁时间以天为单位用户选择开始日期和结束日期前端实时计算租期和总费用。后端在提交订单时会重新计算一次防止用户篡改前端请求参数。支付环节走微信小程序支付这里有一个值得注意的设计决策押金和租金需要分开支付还是合并支付。我们的方案是押金单独一笔支付首期租金单独一笔支付后续续租租金按周期扣。押金单独支付的原因是押金走的是退还流程和租金账户完全隔离财务对账更清晰。如果混在一起退还部分押金时账目会很难看。用户中心模块里我的租赁页面展示当前租赁状态的设备列表包括已发货、运输中、使用中、待归还、已完成几个状态每个状态对应不同的可操作项。比如使用中状态可以申请续租待归还状态可以提交归还申请并填写快递单号。小程序的登录用微信授权登录后端通过 code 换 session_key 再换自定义 token所有请求头带 token网关统一鉴权。这里要注意 code 只能使用一次session_key 不要下发到前端敏感信息一律留在后端。小程序端还有一个很实用的小技巧在 onShow 生命周期里做登录态检查token 过期时静默刷新避免用户操作到一半突然跳登录页。3.2 Vue 管理后台的运营支撑功能Vue 管理端服务的是内部运营人员核心页面包括控制台、设备管理、订单管理、用户管理、财务管理、风控管理、系统设置。设备管理是整个系统最重的模块。数码产品有唯一的 IMEI 或序列号每台设备都是独立实体状态机包括在库、已锁定、租出、维修中、检测中、已报废。运营人员上架设备时可以批量导入序列号、设置租金价格、押金比例、可租赁状态。设备入库后生成唯一设备码扫码枪或手动输入都可操作。这个模块对表格性能要求很高设备数量到万级以后必须做服务端分页和筛选前端不能一次性加载全部数据。订单管理页面重点做订单流转的可视化。列表展示所有订单每个订单有一个时间线组件展示下单、支付、发货、签收、归还申请、检测完成、退款完成的时间点和操作人。运营人员可以直接在订单详情页完成发货操作接入快递 API 填写运单号、登记归还、录入检测结果。检测结果会直接影响押金退还金额这块的交互设计要特别小心需要二次确认弹窗。财务管理页面展示当日营收、押金余额、待退款押金、逾期收入等核心指标。数据来自支付服务和结算服务的数据库Vue 端通过网关调用聚合接口获取。这个页面的数据不允许前端计算所有指标都从后端接口直接拿保证口径统一。权限管理用的是 Vue Router 动态路由 后端权限码方案。登录后根据用户角色超级管理员、运营、财务、客服返回菜单权限和按钮权限前端动态生成路由表。这个方案比静态路由加按钮 v-if 的方式灵活得多角色多了以后维护成本明显更低。首页路由需要用字典表做映射后端返回的权限码和前端路由表一一对应。4. 实操过程与核心环节实现4.1 从零搭建 SpringCloud 微服务骨架搭建过程的核心思路是先把基础设施跑通再填充业务代码。第一步创建父工程管理 Spring Boot 3.2.x 和 Spring Cloud 2023.0.x 的版本号所有子模块继承父工程的依赖管理避免版本冲突。这一步特别重要SpringCloud 和 SpringBoot 的版本是强绑定的版本不对服务直接启动不起来。出现过一次因为引入的 SpringCloud Alibaba 版本和 SpringCloud 版本不匹配Nacos 注册一直失败排查了整整一天。第二步搭建 Nacos。我用 Docker 方式部署 Nacos 2.3.0单机模式起步配置了 MySQL 作为持久化存储。服务注册中心里注册用户服务、商品服务等配置中心管理各服务的 application.yml 中的动态配置比如数据库连接池大小、Redis 地址、业务开关配置。配置修改后通过 Nacos 的监听机制动态刷新不需要重启服务。第三步搭建网关服务 gateway-service作为所有请求的统一入口路由转发到各个微服务。网关里做了统一的 CORS 处理、token 鉴权过滤器、请求日志记录、限流过滤器。小程序端和 Vue 管理端的所有请求都走网关不直接暴露微服务地址。网关还有一个作用是把公共的请求头信息处理掉比如从 token 中解析出来的 userId统一放到请求头里传给下游服务下游服务不需要再解析 token。第四步搭建公共模块 common-core包含统一返回结果 Result、全局异常处理器、常用工具类、BaseEntity。每个业务服务都依赖这个模块。注意不要在公共模块里放数据库实体和 Mapper避免模块间耦合。全局异常处理器要覆盖业务异常、参数校验异常、服务间调用异常几类返回结构统一前端处理错误逻辑会简单很多。第五步配置 OpenFeign。在需要跨服务调用的服务里引入 openfeign 依赖定义 FeignClient 接口。比如 order-service 需要调用 user-service 查询用户信用等级定义 UserClient 接口即可。Feign 的超时时间一定要单独配置默认超时时间很短跨服务查询数据库超过一秒就会报超时。我的配置是连接超时 2 秒、读取超时 5 秒根据业务接口实际耗时调整。第六步配置 Sentinel 限流与熔断。核心接口比如支付、下单设置 QPS 限流商品服务配置熔断规则当商品服务的错误率超过阈值时订单服务的 FeignClient 快速失败并返回兜底数据。兜底数据的设计很关键比如用户信用等级查不到时返回默认等级不能让整个链路因为一个非核心服务拖死。4.2 创建租赁订单的核心接口实现详解以创建租赁订单为例看看完整的代码链路。客户端提交的参数包括商品 ID设备规格如果有规格选择租赁开始日期、结束日期数量通常租赁设备数量为 1但支持同一商品多台用户收货地址后端处理流程分七步通过 userId 从 token 中解析校验用户状态是否为正常从 product-service 获取商品基础信息、日租金、押金比例业务规则校验设备是否可租、租赁天数是否符合最小天数要求、地址是否有效调用 PriceCalculator 组件传入商品信息、租期、用户会员等级计算押金和总租金创建订单记录状态为 PENDING_PAYMENT写本地消息表发库存锁定事件到 Redis Stream返回订单号前端拿订单号发起微信支付价格计算里要注意日期边界的处理。开始日期到结束日期按自然日计算开始当天就算一天结束当天不算。这个规则一定要在前后端统一否则会出现用户看到的金额和订单实际金额不一致的情况。处理过几次这种投诉之后我把金额计算逻辑完全收敛到后端前端只做展示不做任何费用计算。支付回调处理是另一个关键点。微信支付回调是异步的回调里带着订单号和支付结果。支付服务的回调处理逻辑必须做到幂等微信回调可能重复发送回调方法必须用订单号加状态做防重不能因为重复回调产生两次库存扣减。我的做法是在支付回调入口先查本地订单状态如果已经是 PAID 状态直接返回成功不再重复处理。订单查询接口的缓存策略也值得一提。订单列表页是访问频率最高的接口但订单数据实时性要求高不能简单缓存整个列表。我的方案是缓存当前用户的订单 ID 列表和订单详情快缓存时间 5 分钟涉及订单状态变化的写操作主动清除缓存。这样既保证了数据基本实时又减轻了数据库压力。4.3 MinIO 文件存储与图片访问方案设备图片、用户凭证、合同 PDF 都放 MinIO。集成方式很简单引入 minio-java 依赖配置 endpoint、accessKey、secretKey、bucket 名称。上传时生成对象名用 UUID 加文件后缀避免文件名冲突。图片访问走预签名 URL设置过期时间敏感合同类文件不公开读。这里说一下桶的规划。我建了三个桶device-images设备图片公开读、user-certificates用户实名凭证私有、rental-contracts租赁合同私有。不同权限级别的文件放在不同桶里管理起来清晰很多。MinIO 的预签名 URL 功能很实用后端生成一个带过期时间的 URL小程序端直接拿这个 URL 上传上传流量不经过后端服务减小后端压力。Vue 管理端上传图片的完整流程是先通过后端接口请求一个预签名地址前端直传 MinIO上传完成后再把对象名回传给后端落库。这个方式能避免大图片经过业务服务中转效率高很多。生产环境里我用 Nginx 做了 MinIO 的反向代理配了静态资源缓存图片加载速度提升明显。小程序端加载图片有一个必须注意的坑微信小程序的 image 组件对网络图片的域名要求在后台配置合法域名否则本地预览能显示、线上体验版就是空白。这个坑我踩过在微信公众平台后台的开发管理-服务器域名里把图片域名加到 downloadFile 合法域名列表同时在代码里用 CDN 域名而不是 IP 加端口的方式不然小程序端也会拦截。5. 常见问题与排查技巧实录5.1 微服务环境下的典型问题与定位思路微服务模式下本地开发最痛苦的就是环境问题。一个服务依赖另一个服务本地改的接口别的服务在调用多个人一起改代码环境经常打架。解决方式是我们约定每个开发者在本地启动一个 Nacos注册到同一个测试环境配置中心但服务实例名加上开发者标识比如 product-service-zhangsan。前端联调时通过网关路由指定版本避免互相干扰。这个方案实测最稳缺点是本地启动的服务多内存占用大需要 16G 以上的开发机才能流畅跑起来。SpringCloud 2023 版本对 JDK 版本有要求必须 JDK 17 及以上Spring Boot 3.x 也是强要求 JDK 17。老项目代码如果用了 JDK 8 的写法迁移过来会出现各种奇怪问题。新项目直接 JDK 17 起步不要有历史包袱。如果碰到 Java 8 时间类与新版本 Jackson 序列化的兼容问题建议统一采用 Java Time API 配合全局日期格式配置而不是依赖默认序列化。配置管理也出过不少问题。最典型的是本地配置和 Nacos 配置不一致服务启动时本地配置覆盖了 Nacos 配置导致线上行为与本地不一致。排查思路是查看服务启动日志中的配置加载记录确认是从哪个配置源加载的。我后来规定所有环境相关配置一律放 Nacos本地 application.yml 只保留服务名和端口减少出错面。5.2 小程序端抓包排查请求问题实录小程序线上环境的请求无法直接看到网络包这是所有小程序开发者都会遇到的问题。排查方式是在微信开发者工具里勾选不校验合法域名在工具的控制台 Network 面板查看网络请求。如果要看更细节的数据包内容我用 Charles 配置 SSL 代理截取 HTTPS 包。实际排查过一个典型问题小程序端传的日期格式是 2026-03-15后端用 LocalDate 解析正常但通过 Feign 传递到结算服务时序列化格式变成了时间戳导致结算服务解析失败。根因是服务间 JSON 序列化的日期格式不统一。解决方式是统一在 common-core 里配置 Jackson 的全局日期格式所有服务用同一套序列化规则。这是微服务项目中非常隐蔽但高发的问题。还遇到过小程序端请求头丢失的问题。小程序的基础库在部分版本下自定义请求头会被自动过滤导致后端网关解析不到 token。解决方式是排查确认后改用 query 参数传递 token或者在业务侧接受这个限制把小程序的 token 放在请求体的公共字段里传。这类问题如果不抓包看实际请求头单看代码很难发现。5.3 分布式日志追踪与数据一致性排查微服务下一个请求跨多个服务排查问题时没有统一 traceId 会非常痛苦。我在网关层生成了 TraceId放在 MDC 里通过 Feign 的 RequestInterceptor 把 TraceId 传递到下游服务下游服务同样写入 MDC。这样全链路日志可以按 TraceId 搜索一个请求从网关到商品服务再到订单服务的完整链路都能拉出来。实际排查中最耗时间的往往是数据不一致问题。比如订单显示已支付但支付服务没有回调记录。我总结的排查思路是先看订单服务的支付回调日志确认是否收到微信回调再看支付服务的回调处理日志确认处理是否成功最后看本地消息表的投递记录确认事件是否被正确消费。三条链路对齐基本就能定位问题出在哪个环节。配套做法是给消息处理加失败重试和死信队列同一消息消费失败超过三次就进入死信人工后台处理。另一个经验是定时任务别乱用分布式锁。微服务下每个服务可能有多个实例定时任务如果每个实例都执行会出现重复处理。我用的方案是引入 Redisson 的分布式锁持锁节点执行任务其他节点跳过。这个方案简单可靠不需要额外的任务调度中心。经验总结与实用技巧整套系统从拆模块到上线我最大的体会是微服务不是终点它把业务的复杂性问题变成了系统的复杂性问题你得有足够能力和工具去承接这部分复杂性。如果你只做一个小型租赁门店单体加个消息队列可能更合适如果目标是多城市多门店、设备量几万台的运营规模微服务就是值得投入的方向。最后分享一个实用小技巧在 Nacos 配置中心里给每个服务配置一个 isMock 开关开启后服务返回模拟数据不需要依赖下游服务即可独立开发联调。这个小开关在团队并行开发时能省掉大量相互等待的时间。另外配置中心里的开关尽量用布尔值或数字不要用字符串避免代码里到处比较字符串值时的大小写错误。我在本地开发时也会把网关配置指向本机服务配合 Nacos 的命名空间隔离环境体验会好很多。