把SpringBoot、SpringCloud、Vue和小程序这四样东西拧成一个完整的疫苗预约平台听上去像是一场技术栈的“全家桶”聚会但实际上手之后你会发现真正难的从来不是把某个框架跑起来而是搞清楚服务之间怎么划分、预约的库存怎么保证不超卖、小程序端怎么和后端优雅地对上话。我在做这类微服务项目时最深的感受是骨架搭对了后面写业务代码就是在填空骨架搭错了光服务之间的调用链就能把你绕晕。这篇文章我会从架构拆解、核心业务闭环、关键实现细节到排坑实录完整梳理这套疫苗预约管理平台的落地过程适合正在做微服务项目、准备用SpringCloud重构单体应用或者需要用小程序做C端入口的团队参考。1. 整体设计与微服务架构拆分思路1.1 为什么选微服务而不是一个单体应用搞定疫苗预约平台表面上看是一个预约系统但它实际承载的业务域比名字要宽得多用户端有微信小程序登录、疫苗查询、预约下单、接种记录管理端有疫苗库存管理、排期设置、预约审核、数据统计后台还有消息通知、文件存储、权限控制。这些逻辑如果全塞进一个SpringBoot单体项目里开发初期确实爽但到了后期几乎必然面临几个问题某个模块一升级就要整个应用重新发版并发预约时数据库压力和业务逻辑耦合在一起互相拖累不同团队改代码时在同一个工程里冲突不断。微服务架构的核心价值不在于“拆了看起来高级”而在于把不同的业务域变成独立部署、独立扩展的单元。比如预约高峰期来了我可以只对预约服务做横向扩容不需要把用户服务和通知服务一起拖着跑。这个平台我把整体拆成了五个核心服务用户服务、疫苗服务、预约服务、订单服务、通知服务再加上一个网关和几个基础设施组件。这样的粒度对于团队规模在5到10人左右的项目来说是最舒服的——既能体现微服务的独立性又不至于像某些大型互联网公司那样拆出几十个服务导致运维成本失控。1.2 服务拆分逻辑与边界定义拆分服务最忌讳的是按“页面”拆比如做一个“小程序端服务”和一个“管理后台服务”这样拆完以后你会发现公共的业务逻辑根本不知道放哪里。正确的拆法应该是按领域边界拆也就是围绕业务能力来划分。拿这个疫苗预约平台来说用户服务负责C端用户的注册登录、个人信息维护包括微信小程序授权登录的整套逻辑对外暴露用户信息查询、openid绑定等接口。疫苗服务负责疫苗的基础信息管理比如疫苗名称、生产厂家、适用年龄段、库存总量、当前库存余量以及管理员维护的排期计划。预约服务是整个系统的核心负责处理预约下单、锁定库存、取消预约等动作这个服务要直接面对最大的并发压力。订单服务负责生成预约记录、保存接种凭证、对接支付如果有的话它和预约服务之间通过消息或者Feign接口协作。通知服务则负责在预约成功、接种提醒、预约取消时发送模板消息或短信这个服务可以做成异步消费不影响主链路的响应速度。这里有个很关键的取舍预约服务和订单服务之间的边界。我见过很多人把预约和订单放在同一个服务里觉得省事。但疫苗预约的订单有一个特点——它是有状态流转的从已预约到已接种到已完成而这些状态变更又伴随着库存的释放或锁定。如果把预约和订单混在一起代码层面很快就变成一锅粥。分开了以后预约服务只关心库存和时段订单服务只关心单据状态两者通过一个预约编号关联清晰很多。1.3 技术选型的取舍与组合逻辑SpringBoot SpringCloud这套组合在国内中小团队里几乎是不二之选原因很简单生态成熟、招聘市场上会的人多、出问题能找到的解决方案也多。版本选择上我踩过一次坑SpringBoot 3.x要求JDK17但很多团队的线上环境还是JDK8导致不得不推翻重来。所以如果是从零起步建议直接SpringBoot 2.7.x SpringCloud 2021.x这是一个被大量生产环境验证过的稳定组合。注册中心和配置中心我用了Nacos因为相比Eureka它多了一个配置管理的功能可以不用额外部署Config Server网关层用SpringCloud Gateway注意不要用Zuul 1.x那个性能在微服务网关里实在拿不出手服务间调用用OpenFeign加上Sentinel做限流熔断。前端这块管理后台用Vue Element UI这套组合在管理类系统里非常成熟表格、表单、弹窗组件都现成的适合快速搭后台小程序端用原生微信小程序开发没有引入uni-app因为疫情预约的场景代码量不大原生开发反而少了框架层的黑盒问题。2. 核心业务模块与关键闭环解析2.1 疫苗预约的核心流程从排期到核销整个平台的业务主链路是这样的管理员在后台录入疫苗信息并创建接种排期排期包含时间段、地点、可用疫苗批次、每个时间段的最大预约人数。用户在小程序端进入预约页面选择疫苗类型、选择接种点、选择时间段系统检查该时间段是否有余量有则创建预约记录并扣减库存。预约成功后用户会收到通知到了预约日期用户到现场工作人员在小程序或后台里核销预约码状态变更为已完成。如果用户临时有事可以在小程序里取消预约库存同步释放。这个流程看起来简单但每个环节都有坑。最典型的坑是库存扣减的时机用户在A页面选好了时间段在B页面犹豫了30秒没提交这期间别人把余量抢完了怎么办我的方案是用户选定时间段后先不扣库存而是在提交订单时用一个分布式锁包住“查余量—扣库存—生成订单”这三个动作保证原子性。同时还可以在前端做一层余量的缓存展示后端才是最终校验的地方否则用户看到有号但实际上提交时已经没了体验很差。2.2 分布式事务与数据一致性处理微服务架构下最绕不开的话题就是分布式事务。疫苗预约这个场景里一个完整的操作可能涉及预约服务锁库存和订单服务生成单据如果只用本地事务必然出现一边成功一边失败的情况。有不少人一上来就上Seata但我觉得要分场景。预约服务内部锁库存和生成预约记录是在同一个服务里的用本地事务就够了只有跨服务的操作才需要考虑分布式事务。我在这个项目里采用的是“本地消息表异步补偿”的方案。具体做法是预约服务在本地事务里完成库存扣减同时往一个消息表里插入一条待发送的消息然后通过RocketMQ把“预约成功”这个事件发给订单服务。订单服务收到消息后创建订单记录。如果订单服务处理失败消息会重试重试多次仍然失败就进入死信队列由定时任务去检查并做补偿处理。这套方案比Seata轻量很多而且对于疫苗预约这种业务来说最终一致性是完全可以接受的——用户预约成功到看到订单之间有几百毫秒的延迟根本感知不到。2.3 权限模型与数据安全设计疫苗预约平台涉及两类完全不同的用户C端的普通用户和管理端的医护人员/管理员。这两类用户的权限边界必须从架构层面就分开。我用的方案是gateway层统一鉴权 服务内部做细粒度校验。用户在微信小程序里通过wx.login拿到code后端调用微信接口换取openid生成JWT token返回给小程序管理后台则是用户名密码登录走Spring Security OAuth2的密码模式拿token。这里值得多说一句的是服务内部的接口不能因为网关已经鉴权了就裸奔。微服务架构里服务之间的调用是内网互信吗不一定。我在设计时对每个服务的接口都做了两层防护对来自网关的请求从Header里解析用户信息并校验对服务之间的Feign调用统一加一个内部调用的token只有带了正确的内部标识才能访问。这样即使某个服务不小心暴露到公网也不至于变成全网裸奔。整个系统的数据安全还涉及用户健康信息这块在数据库层面做了敏感字段加密而不是明文存储接口返回时也做了脱敏处理。3. 实操过程与核心环节实现细节3.1 基于Nacos的服务注册与配置统一管理我在项目里所有服务都接入Nacos包括网关。每个服务在启动时把自己的IP和端口注册到Nacos同时从Nacos拉取配置。这样做的好处有两个一是服务之间通过服务名调用不再写死IP实例扩缩容对调用方完全透明二是配置可以统一管理比如数据库连接、Redis地址、消息队列地址这些环境相关的配置都放在Nacos里不同环境用不同的namespace隔离发布时不需要打不同的包。Nacos的配置有个需要特别注意的地方配置变更默认是实时推送给客户端的这当然很方便但如果你在配置里改了数据库连接串客户端会立刻生效而线上连接池可能还在用旧连接极容易导致启动失败或者连接中断。我的经验是对于数据库、消息队列这类基础设施的配置变更最好在低峰期操作变更完以后通过Nacos的灰度发布功能先推给一台实例验证再推全量。另外Nacos自带的配置管理有个小毛病——历史版本保留时间是有限制的所以我养成了一个习惯重要配置在代码仓库里保留一份副本Nacos只作为运行时的配置源避免某天配置被误删后找不到原始值。3.2 前端控制台Vue Element UI的后台管理体系管理后台我用Vue2 Element UI实现但这套组合有一个比较尴尬的问题Vue2已经进入维护末期Element UI也基本停止了大版本更新。如果是新项目Vue3 Element Plus是更长远的选择。我这次用了Vue2主要是因为团队对这个技术栈最熟而且项目的生命周期内Vue2完全够用。后台的核心页面有这几个疫苗管理页用表格展示所有疫苗的信息支持增删改查和分页图片上传直接用MinIO前端上传后拿到URL存到数据库里排期管理页用日历组件选择日期然后为每个日期配置时间段和可预约人数预约记录页这是数据量最大的页面要支持按日期、疫苗名称、用户手机号筛选所以后端分页查询时一定要在SQL层面做好索引优化不能把所有数据查出来再在内存里过滤。Vue路由这块我在后台做了动态路由根据用户的角色动态生成可访问的路由表而不是一次性全部注册。实现方式也不复杂前端在登录后拿到用户角色调用后端接口获取该角色的菜单权限再通过router.addRoutes动态添加路由。这样做的好处是不同角色看到的功能入口完全不同而且前端路由和后端接口权限形成双重校验。3.3 小程序端登录、请求封装与预约交互小程序端的开发难度相比管理后台要大一些因为它有平台限制。微信小程序的request请求不同于Web的fetch或axios它没有跨域的概念但要求请求的域名必须在小程序后台配置为合法域名否则只能在小程序开发工具里勾选“不校验合法域名”才能在本地调试。第一次联调时我记得很清楚后端接口跑在局域网的一台开发机上小程序一直报ERR_NAME_NOT_RESOLVED查了半天发现是开发机的IP没有加到小程序合法域名里而且必须是HTTPS的域名开发阶段可以用IP加端口临时调试但上线必须走备案过的HTTPS域名。请求封装方面我在小程序里封装了一个统一的request方法做了几件事自动携带token在请求头里加Authorization统一处理HTTP错误码和业务错误码401时自动跳转到登录页接口请求loading的统一显示和关闭成功响应统一解包调用方直接拿data字段不需要每个页面都做一层判断。这套封装完整地对应了后端统一返回的Result结构前后端约定一致联调效率提高不少。小程序登录用的是wx.login获取code然后把code发给后端后端通过code换取openid和session_key。这里有一个常见的误区很多团队会把openid直接存到数据库里作为用户标识但openid是跟小程序AppID绑定的如果以后更换了小程序主体openid就会变。我建议在用户表里用一个自增的business_id作为用户的业务主键openid只作为一个关联字段这样以后做跨端用户体系打通时不用大规模改表结构。3.4 MinIO对象存储图片与文件管理的落地项目里涉及疫苗宣传图片、身份证照片、接种凭证等文件的上传和访问我在存储这块选了MinIO部署在一台内网服务器上。MinIO是一个开源的分布式对象存储服务接口兼容Amazon S3但部署和运维成本低得多非常适合中小型项目。后端集成MinIO很简单引入minio的Java SDK配置endpoint、accessKey、secretKey然后封装一个上传接口接收MultipartFile转存到MinIO的bucket里返回文件的访问URL。需要注意一点MinIO的默认bucket访问权限是private通过URL直接访问会报AccessDenied。我这里的图片是要在小程序里直接展示的所以把bucket的访问策略设置成了public-read但如果涉及用户身份证这类敏感文件绝对不能公开读必须通过后端接口做鉴权后再返回文件流。文件的访问URL还有个坑MinIO返回的URL默认带的是内网地址小程序端是公网环境根本访问不到。解决方式有两种要么在前端拿到URL后手动替换域名前缀要么在MinIO配置里使用外网访问地址根据实际部署环境设置MinIO的MINIO_SERVER_URL环境变量。我用了后者因为不做字符串替换就少了出错的机会。4. 常见问题与排查技巧实录4.1 微服务联调中的服务发现怪圈微服务项目第一次本地联调时碰到最多的问题就是服务注册不上或者服务注册了但调用方找不到。我的排查思路是这样的先看Nacos控制台如果服务列表里没有这个服务实例说明注册环节出了问题去服务提供方的日志里搜“register”相关的日志大概率能发现是Nacos地址配错了或者防火墙把8848端口拦了。如果服务实例在Nacos里有但调用方仍然报找不到服务那就要看调用方是不是用了正确的服务名。这里有一个特别容易犯的错误服务名在不同配置文件里写法不一致比如一个是vaccine-service另一个是vaccine_serviceNacos里下划线会被规范化导致匹配失败。还有一个值得提醒的坑本地开发时多个服务都注册到同一个Nacos如果你本机的服务也注册进去了而线上实例也在调用方负载均衡后可能打到线上实例上测试数据就会写进生产库。我后来规范了开发流程本地开发的服务在配置里加一个spring.cloud.nacos.discovery.group把本地的服务分到dev组线上是prod组调用方通过group来过滤从根源上隔离了环境。4.2 高并发预约场景下的超卖问题排查疫苗预约在放出热门疫苗时段时可能瞬间涌入大量请求。最开始我做的是先查余量再减库存结果测试时用脚本并发压测了100个请求发现成功创建了120个预约订单库存变成负数这就是典型的超卖。排查过程让我确认了一个微服务下的经典规律在分布式环境下用同步代码块或单机锁是锁不住并发的因为请求会分散到不同的实例上每个实例的锁互不感知。最终的解决方案是用Redis的分布式锁配合数据库乐观锁。预约服务在创建预约时先尝试获取一个以“疫苗批次ID时间段”为key的Redis锁拿到锁之后在事务里查询余量余量大于0才扣减并创建订单释放锁。同时在数据库层的库存表上加了库存版本的乐观锁字段UPDATE语句带version条件影响行数为0就说明有人并发修改了重试。这两层保障叠加以后压测数据是1000个并发请求成功预约数量和库存扣减数量完全一致没有超卖也没有漏减。4.3 前端跨域与小程序请求的细节问题Vue管理后台在开发环境里跑在8080端口后端网关在8080端口表面上不跨域实际上呢前端访问后端的接口是跨域的因为端口不同。我在开发环境里用Vite或Webpack的proxy代理解决把/api前缀的请求代理到网关地址这样浏览器的同源策略就绕过去了生产环境用Nginx做反向代理同一域名下通过路径区分前端静态资源和后端API。这里面出现过一次比较隐蔽的问题后端接口返回的数据里包含某些字段是null前端组件直接调用了这个字段的方法导致页面渲染报错。后端的接口返回统一包装成Result结构后data字段可能是null业务代码里一定要做空值判断或者返回一个空对象而不是null否则前端的报错排查起来非常痛苦。小程序端的请求没有浏览器跨域策略的限制但它对域名要求更严格——必须是HTTPS且在小程序管理后台配置了合法域名。我在联调阶段用了一个临时的方案开发工具里开启“不校验合法域名”真机预览时用手机抓包工具直接定向到本地IP方便调接口看返回。这里有一个小技巧微信开发者工具里可以添加自定义的条件编译模式把不同的环境地址配置成不同的编译模式切换环境时不用改代码直接选模式就行。实测下来效率能提升不少。4.4 微服务面试必问的链路追踪与日志聚合微服务跑起来以后一个请求要经过网关、预约服务、订单服务、通知服务出了问题想定位到具体是哪个服务耗时最长或者哪个环节抛了异常单靠翻阅每个服务的本地日志几乎是不可能完成的任务。我在项目里接入了Sleuth Zipkin做链路追踪每个服务在日志里打印traceId和spanId调用链可以用Zipkin的UI直观看到哪个环节耗时最长。日常排查问题时只需要记住请求的入口traceId然后去日志平台搜索这个traceId就能把整条链路的日志全捞出来。日志聚合有一点容易被忽视不同服务打印的日志格式如果不统一聚合后的搜索体验会很差。我在项目里定了一个日志规范所有服务的日志统一用JSON格式输出包含时间、级别、服务名、traceId、业务关键词、异常堆栈这几个字段。配合ELK这套日志平台按traceId搜索就能还原一次完整请求的来龙去脉。这个工作建议在项目一开始就做如果等业务跑起来再补日志格式不统一的问题会让整个平台的可观测性大打折扣。5. 项目经验总结与后续扩展建议5.1 架构演进的方向与容量规划这套疫苗预约管理平台目前的架构已经能支撑较大的并发访问但有几个方向值得继续演进。如果预约的并发量再上一个量级可以考虑把预约服务的库存扣减完全放到Redis里预热异步同步到数据库尽量减少数据库的直接写压力。市面上很多秒杀系统的做法是库存在活动开始前加载到Redis预约请求直接操作Redis的原子递减成功后再通过消息队列异步生成订单和扣减数据库库存。这个方案可以做到非常高的吞吐量但复杂度也会增加需要对账机制来保证最终一致性。另一个扩展方向是消息通知的多通道化。目前通知服务主要发微信模板消息如果增加短信、邮件等通道通知服务的职责会变得更大可以考虑按通道再拆细或者引入更成熟的通知中心组件。不过这些都是“业务压力来了才需要做的事”现阶段这套架构已经足够健康。5.2 团队协作与开发规范的沉淀做了这个项目以后我有几个非常深的体会。第一个是契约先行前后端联调最大的成本不是写代码而是接口对不上。我们在项目里坚持先用Swagger定义好接口文档前端和后端基于同一份文档开发字段名、类型、嵌套结构完全一致联调时几乎不需要来回改。第二个是环境管理要尽早规范化本地开发环境、测试环境、生产环境的配置一定要分离用Nacos的namespace或者group做隔离不然总会有人不小心把测试数据写进生产库。第三个是善用自动化测试微服务项目里最怕改动一个服务影响多个下游我在预约服务、订单服务里补了一批针对核心流程的单元测试和集成测试每次发版前跑一遍确实能拦住不少低级错误。最后说一个实操中的小建议像这种多端项目前端页面里的提示文案、按钮名称、状态枚举一定要和后端统一最好像我们一样建一份状态码字典表前后端都从这份表里取值定义前端展示和后端校验不要出现后端返回0表示成功、前端却判断1的情况。这个细节看起来不起眼但是在联调和后期维护时省下的时间比你想的多得多。
SpringBoot+SpringCloud+Vue+小程序：疫苗预约平台微服务实战全解析
把SpringBoot、SpringCloud、Vue和小程序这四样东西拧成一个完整的疫苗预约平台听上去像是一场技术栈的“全家桶”聚会但实际上手之后你会发现真正难的从来不是把某个框架跑起来而是搞清楚服务之间怎么划分、预约的库存怎么保证不超卖、小程序端怎么和后端优雅地对上话。我在做这类微服务项目时最深的感受是骨架搭对了后面写业务代码就是在填空骨架搭错了光服务之间的调用链就能把你绕晕。这篇文章我会从架构拆解、核心业务闭环、关键实现细节到排坑实录完整梳理这套疫苗预约管理平台的落地过程适合正在做微服务项目、准备用SpringCloud重构单体应用或者需要用小程序做C端入口的团队参考。1. 整体设计与微服务架构拆分思路1.1 为什么选微服务而不是一个单体应用搞定疫苗预约平台表面上看是一个预约系统但它实际承载的业务域比名字要宽得多用户端有微信小程序登录、疫苗查询、预约下单、接种记录管理端有疫苗库存管理、排期设置、预约审核、数据统计后台还有消息通知、文件存储、权限控制。这些逻辑如果全塞进一个SpringBoot单体项目里开发初期确实爽但到了后期几乎必然面临几个问题某个模块一升级就要整个应用重新发版并发预约时数据库压力和业务逻辑耦合在一起互相拖累不同团队改代码时在同一个工程里冲突不断。微服务架构的核心价值不在于“拆了看起来高级”而在于把不同的业务域变成独立部署、独立扩展的单元。比如预约高峰期来了我可以只对预约服务做横向扩容不需要把用户服务和通知服务一起拖着跑。这个平台我把整体拆成了五个核心服务用户服务、疫苗服务、预约服务、订单服务、通知服务再加上一个网关和几个基础设施组件。这样的粒度对于团队规模在5到10人左右的项目来说是最舒服的——既能体现微服务的独立性又不至于像某些大型互联网公司那样拆出几十个服务导致运维成本失控。1.2 服务拆分逻辑与边界定义拆分服务最忌讳的是按“页面”拆比如做一个“小程序端服务”和一个“管理后台服务”这样拆完以后你会发现公共的业务逻辑根本不知道放哪里。正确的拆法应该是按领域边界拆也就是围绕业务能力来划分。拿这个疫苗预约平台来说用户服务负责C端用户的注册登录、个人信息维护包括微信小程序授权登录的整套逻辑对外暴露用户信息查询、openid绑定等接口。疫苗服务负责疫苗的基础信息管理比如疫苗名称、生产厂家、适用年龄段、库存总量、当前库存余量以及管理员维护的排期计划。预约服务是整个系统的核心负责处理预约下单、锁定库存、取消预约等动作这个服务要直接面对最大的并发压力。订单服务负责生成预约记录、保存接种凭证、对接支付如果有的话它和预约服务之间通过消息或者Feign接口协作。通知服务则负责在预约成功、接种提醒、预约取消时发送模板消息或短信这个服务可以做成异步消费不影响主链路的响应速度。这里有个很关键的取舍预约服务和订单服务之间的边界。我见过很多人把预约和订单放在同一个服务里觉得省事。但疫苗预约的订单有一个特点——它是有状态流转的从已预约到已接种到已完成而这些状态变更又伴随着库存的释放或锁定。如果把预约和订单混在一起代码层面很快就变成一锅粥。分开了以后预约服务只关心库存和时段订单服务只关心单据状态两者通过一个预约编号关联清晰很多。1.3 技术选型的取舍与组合逻辑SpringBoot SpringCloud这套组合在国内中小团队里几乎是不二之选原因很简单生态成熟、招聘市场上会的人多、出问题能找到的解决方案也多。版本选择上我踩过一次坑SpringBoot 3.x要求JDK17但很多团队的线上环境还是JDK8导致不得不推翻重来。所以如果是从零起步建议直接SpringBoot 2.7.x SpringCloud 2021.x这是一个被大量生产环境验证过的稳定组合。注册中心和配置中心我用了Nacos因为相比Eureka它多了一个配置管理的功能可以不用额外部署Config Server网关层用SpringCloud Gateway注意不要用Zuul 1.x那个性能在微服务网关里实在拿不出手服务间调用用OpenFeign加上Sentinel做限流熔断。前端这块管理后台用Vue Element UI这套组合在管理类系统里非常成熟表格、表单、弹窗组件都现成的适合快速搭后台小程序端用原生微信小程序开发没有引入uni-app因为疫情预约的场景代码量不大原生开发反而少了框架层的黑盒问题。2. 核心业务模块与关键闭环解析2.1 疫苗预约的核心流程从排期到核销整个平台的业务主链路是这样的管理员在后台录入疫苗信息并创建接种排期排期包含时间段、地点、可用疫苗批次、每个时间段的最大预约人数。用户在小程序端进入预约页面选择疫苗类型、选择接种点、选择时间段系统检查该时间段是否有余量有则创建预约记录并扣减库存。预约成功后用户会收到通知到了预约日期用户到现场工作人员在小程序或后台里核销预约码状态变更为已完成。如果用户临时有事可以在小程序里取消预约库存同步释放。这个流程看起来简单但每个环节都有坑。最典型的坑是库存扣减的时机用户在A页面选好了时间段在B页面犹豫了30秒没提交这期间别人把余量抢完了怎么办我的方案是用户选定时间段后先不扣库存而是在提交订单时用一个分布式锁包住“查余量—扣库存—生成订单”这三个动作保证原子性。同时还可以在前端做一层余量的缓存展示后端才是最终校验的地方否则用户看到有号但实际上提交时已经没了体验很差。2.2 分布式事务与数据一致性处理微服务架构下最绕不开的话题就是分布式事务。疫苗预约这个场景里一个完整的操作可能涉及预约服务锁库存和订单服务生成单据如果只用本地事务必然出现一边成功一边失败的情况。有不少人一上来就上Seata但我觉得要分场景。预约服务内部锁库存和生成预约记录是在同一个服务里的用本地事务就够了只有跨服务的操作才需要考虑分布式事务。我在这个项目里采用的是“本地消息表异步补偿”的方案。具体做法是预约服务在本地事务里完成库存扣减同时往一个消息表里插入一条待发送的消息然后通过RocketMQ把“预约成功”这个事件发给订单服务。订单服务收到消息后创建订单记录。如果订单服务处理失败消息会重试重试多次仍然失败就进入死信队列由定时任务去检查并做补偿处理。这套方案比Seata轻量很多而且对于疫苗预约这种业务来说最终一致性是完全可以接受的——用户预约成功到看到订单之间有几百毫秒的延迟根本感知不到。2.3 权限模型与数据安全设计疫苗预约平台涉及两类完全不同的用户C端的普通用户和管理端的医护人员/管理员。这两类用户的权限边界必须从架构层面就分开。我用的方案是gateway层统一鉴权 服务内部做细粒度校验。用户在微信小程序里通过wx.login拿到code后端调用微信接口换取openid生成JWT token返回给小程序管理后台则是用户名密码登录走Spring Security OAuth2的密码模式拿token。这里值得多说一句的是服务内部的接口不能因为网关已经鉴权了就裸奔。微服务架构里服务之间的调用是内网互信吗不一定。我在设计时对每个服务的接口都做了两层防护对来自网关的请求从Header里解析用户信息并校验对服务之间的Feign调用统一加一个内部调用的token只有带了正确的内部标识才能访问。这样即使某个服务不小心暴露到公网也不至于变成全网裸奔。整个系统的数据安全还涉及用户健康信息这块在数据库层面做了敏感字段加密而不是明文存储接口返回时也做了脱敏处理。3. 实操过程与核心环节实现细节3.1 基于Nacos的服务注册与配置统一管理我在项目里所有服务都接入Nacos包括网关。每个服务在启动时把自己的IP和端口注册到Nacos同时从Nacos拉取配置。这样做的好处有两个一是服务之间通过服务名调用不再写死IP实例扩缩容对调用方完全透明二是配置可以统一管理比如数据库连接、Redis地址、消息队列地址这些环境相关的配置都放在Nacos里不同环境用不同的namespace隔离发布时不需要打不同的包。Nacos的配置有个需要特别注意的地方配置变更默认是实时推送给客户端的这当然很方便但如果你在配置里改了数据库连接串客户端会立刻生效而线上连接池可能还在用旧连接极容易导致启动失败或者连接中断。我的经验是对于数据库、消息队列这类基础设施的配置变更最好在低峰期操作变更完以后通过Nacos的灰度发布功能先推给一台实例验证再推全量。另外Nacos自带的配置管理有个小毛病——历史版本保留时间是有限制的所以我养成了一个习惯重要配置在代码仓库里保留一份副本Nacos只作为运行时的配置源避免某天配置被误删后找不到原始值。3.2 前端控制台Vue Element UI的后台管理体系管理后台我用Vue2 Element UI实现但这套组合有一个比较尴尬的问题Vue2已经进入维护末期Element UI也基本停止了大版本更新。如果是新项目Vue3 Element Plus是更长远的选择。我这次用了Vue2主要是因为团队对这个技术栈最熟而且项目的生命周期内Vue2完全够用。后台的核心页面有这几个疫苗管理页用表格展示所有疫苗的信息支持增删改查和分页图片上传直接用MinIO前端上传后拿到URL存到数据库里排期管理页用日历组件选择日期然后为每个日期配置时间段和可预约人数预约记录页这是数据量最大的页面要支持按日期、疫苗名称、用户手机号筛选所以后端分页查询时一定要在SQL层面做好索引优化不能把所有数据查出来再在内存里过滤。Vue路由这块我在后台做了动态路由根据用户的角色动态生成可访问的路由表而不是一次性全部注册。实现方式也不复杂前端在登录后拿到用户角色调用后端接口获取该角色的菜单权限再通过router.addRoutes动态添加路由。这样做的好处是不同角色看到的功能入口完全不同而且前端路由和后端接口权限形成双重校验。3.3 小程序端登录、请求封装与预约交互小程序端的开发难度相比管理后台要大一些因为它有平台限制。微信小程序的request请求不同于Web的fetch或axios它没有跨域的概念但要求请求的域名必须在小程序后台配置为合法域名否则只能在小程序开发工具里勾选“不校验合法域名”才能在本地调试。第一次联调时我记得很清楚后端接口跑在局域网的一台开发机上小程序一直报ERR_NAME_NOT_RESOLVED查了半天发现是开发机的IP没有加到小程序合法域名里而且必须是HTTPS的域名开发阶段可以用IP加端口临时调试但上线必须走备案过的HTTPS域名。请求封装方面我在小程序里封装了一个统一的request方法做了几件事自动携带token在请求头里加Authorization统一处理HTTP错误码和业务错误码401时自动跳转到登录页接口请求loading的统一显示和关闭成功响应统一解包调用方直接拿data字段不需要每个页面都做一层判断。这套封装完整地对应了后端统一返回的Result结构前后端约定一致联调效率提高不少。小程序登录用的是wx.login获取code然后把code发给后端后端通过code换取openid和session_key。这里有一个常见的误区很多团队会把openid直接存到数据库里作为用户标识但openid是跟小程序AppID绑定的如果以后更换了小程序主体openid就会变。我建议在用户表里用一个自增的business_id作为用户的业务主键openid只作为一个关联字段这样以后做跨端用户体系打通时不用大规模改表结构。3.4 MinIO对象存储图片与文件管理的落地项目里涉及疫苗宣传图片、身份证照片、接种凭证等文件的上传和访问我在存储这块选了MinIO部署在一台内网服务器上。MinIO是一个开源的分布式对象存储服务接口兼容Amazon S3但部署和运维成本低得多非常适合中小型项目。后端集成MinIO很简单引入minio的Java SDK配置endpoint、accessKey、secretKey然后封装一个上传接口接收MultipartFile转存到MinIO的bucket里返回文件的访问URL。需要注意一点MinIO的默认bucket访问权限是private通过URL直接访问会报AccessDenied。我这里的图片是要在小程序里直接展示的所以把bucket的访问策略设置成了public-read但如果涉及用户身份证这类敏感文件绝对不能公开读必须通过后端接口做鉴权后再返回文件流。文件的访问URL还有个坑MinIO返回的URL默认带的是内网地址小程序端是公网环境根本访问不到。解决方式有两种要么在前端拿到URL后手动替换域名前缀要么在MinIO配置里使用外网访问地址根据实际部署环境设置MinIO的MINIO_SERVER_URL环境变量。我用了后者因为不做字符串替换就少了出错的机会。4. 常见问题与排查技巧实录4.1 微服务联调中的服务发现怪圈微服务项目第一次本地联调时碰到最多的问题就是服务注册不上或者服务注册了但调用方找不到。我的排查思路是这样的先看Nacos控制台如果服务列表里没有这个服务实例说明注册环节出了问题去服务提供方的日志里搜“register”相关的日志大概率能发现是Nacos地址配错了或者防火墙把8848端口拦了。如果服务实例在Nacos里有但调用方仍然报找不到服务那就要看调用方是不是用了正确的服务名。这里有一个特别容易犯的错误服务名在不同配置文件里写法不一致比如一个是vaccine-service另一个是vaccine_serviceNacos里下划线会被规范化导致匹配失败。还有一个值得提醒的坑本地开发时多个服务都注册到同一个Nacos如果你本机的服务也注册进去了而线上实例也在调用方负载均衡后可能打到线上实例上测试数据就会写进生产库。我后来规范了开发流程本地开发的服务在配置里加一个spring.cloud.nacos.discovery.group把本地的服务分到dev组线上是prod组调用方通过group来过滤从根源上隔离了环境。4.2 高并发预约场景下的超卖问题排查疫苗预约在放出热门疫苗时段时可能瞬间涌入大量请求。最开始我做的是先查余量再减库存结果测试时用脚本并发压测了100个请求发现成功创建了120个预约订单库存变成负数这就是典型的超卖。排查过程让我确认了一个微服务下的经典规律在分布式环境下用同步代码块或单机锁是锁不住并发的因为请求会分散到不同的实例上每个实例的锁互不感知。最终的解决方案是用Redis的分布式锁配合数据库乐观锁。预约服务在创建预约时先尝试获取一个以“疫苗批次ID时间段”为key的Redis锁拿到锁之后在事务里查询余量余量大于0才扣减并创建订单释放锁。同时在数据库层的库存表上加了库存版本的乐观锁字段UPDATE语句带version条件影响行数为0就说明有人并发修改了重试。这两层保障叠加以后压测数据是1000个并发请求成功预约数量和库存扣减数量完全一致没有超卖也没有漏减。4.3 前端跨域与小程序请求的细节问题Vue管理后台在开发环境里跑在8080端口后端网关在8080端口表面上不跨域实际上呢前端访问后端的接口是跨域的因为端口不同。我在开发环境里用Vite或Webpack的proxy代理解决把/api前缀的请求代理到网关地址这样浏览器的同源策略就绕过去了生产环境用Nginx做反向代理同一域名下通过路径区分前端静态资源和后端API。这里面出现过一次比较隐蔽的问题后端接口返回的数据里包含某些字段是null前端组件直接调用了这个字段的方法导致页面渲染报错。后端的接口返回统一包装成Result结构后data字段可能是null业务代码里一定要做空值判断或者返回一个空对象而不是null否则前端的报错排查起来非常痛苦。小程序端的请求没有浏览器跨域策略的限制但它对域名要求更严格——必须是HTTPS且在小程序管理后台配置了合法域名。我在联调阶段用了一个临时的方案开发工具里开启“不校验合法域名”真机预览时用手机抓包工具直接定向到本地IP方便调接口看返回。这里有一个小技巧微信开发者工具里可以添加自定义的条件编译模式把不同的环境地址配置成不同的编译模式切换环境时不用改代码直接选模式就行。实测下来效率能提升不少。4.4 微服务面试必问的链路追踪与日志聚合微服务跑起来以后一个请求要经过网关、预约服务、订单服务、通知服务出了问题想定位到具体是哪个服务耗时最长或者哪个环节抛了异常单靠翻阅每个服务的本地日志几乎是不可能完成的任务。我在项目里接入了Sleuth Zipkin做链路追踪每个服务在日志里打印traceId和spanId调用链可以用Zipkin的UI直观看到哪个环节耗时最长。日常排查问题时只需要记住请求的入口traceId然后去日志平台搜索这个traceId就能把整条链路的日志全捞出来。日志聚合有一点容易被忽视不同服务打印的日志格式如果不统一聚合后的搜索体验会很差。我在项目里定了一个日志规范所有服务的日志统一用JSON格式输出包含时间、级别、服务名、traceId、业务关键词、异常堆栈这几个字段。配合ELK这套日志平台按traceId搜索就能还原一次完整请求的来龙去脉。这个工作建议在项目一开始就做如果等业务跑起来再补日志格式不统一的问题会让整个平台的可观测性大打折扣。5. 项目经验总结与后续扩展建议5.1 架构演进的方向与容量规划这套疫苗预约管理平台目前的架构已经能支撑较大的并发访问但有几个方向值得继续演进。如果预约的并发量再上一个量级可以考虑把预约服务的库存扣减完全放到Redis里预热异步同步到数据库尽量减少数据库的直接写压力。市面上很多秒杀系统的做法是库存在活动开始前加载到Redis预约请求直接操作Redis的原子递减成功后再通过消息队列异步生成订单和扣减数据库库存。这个方案可以做到非常高的吞吐量但复杂度也会增加需要对账机制来保证最终一致性。另一个扩展方向是消息通知的多通道化。目前通知服务主要发微信模板消息如果增加短信、邮件等通道通知服务的职责会变得更大可以考虑按通道再拆细或者引入更成熟的通知中心组件。不过这些都是“业务压力来了才需要做的事”现阶段这套架构已经足够健康。5.2 团队协作与开发规范的沉淀做了这个项目以后我有几个非常深的体会。第一个是契约先行前后端联调最大的成本不是写代码而是接口对不上。我们在项目里坚持先用Swagger定义好接口文档前端和后端基于同一份文档开发字段名、类型、嵌套结构完全一致联调时几乎不需要来回改。第二个是环境管理要尽早规范化本地开发环境、测试环境、生产环境的配置一定要分离用Nacos的namespace或者group做隔离不然总会有人不小心把测试数据写进生产库。第三个是善用自动化测试微服务项目里最怕改动一个服务影响多个下游我在预约服务、订单服务里补了一批针对核心流程的单元测试和集成测试每次发版前跑一遍确实能拦住不少低级错误。最后说一个实操中的小建议像这种多端项目前端页面里的提示文案、按钮名称、状态枚举一定要和后端统一最好像我们一样建一份状态码字典表前后端都从这份表里取值定义前端展示和后端校验不要出现后端返回0表示成功、前端却判断1的情况。这个细节看起来不起眼但是在联调和后期维护时省下的时间比你想的多得多。
