去年接手了一个市级医院的预约挂号系统重构项目。原来那套单体应用每到周一早上八点放号就会有一大批用户同时涌进来抢号源数据库连接池直接被打满接口超时、下单失败、号源超卖各种问题一起爆出来。医院信息科的同事一提到“放号”两个字就头疼。后来我们用 SpringBoot3 Vue3 把整个系统重构成一套分布式架构的医疗挂号系统才彻底把这个场景扛下来。这篇文章就把这次改造的完整思路和实现过程整理出来包含架构设计、核心代码逻辑、分布式锁和分布式事务的处理方式以及 Vue3 前端工程化的落地实践给正准备做类似系统的同学一个参考。1. 为什么挂号系统必须先考虑分布式1.1 挂号业务的特点典型的“瞬时高并发”场景挂号系统和其他业务系统最大的区别在于流量模型。它不是每分钟均匀地来请求而是集中在放号那一刻爆发。以我们接入的一家三甲医院为例周一到周五每天早上8点放未来7天的号源光是口腔科、儿科、心内科这几个热门科室同时在线抢号的用户可能就有几千甚至上万人。而真正引起问题的不只是流量大还有两个特性。第一写多读也多。挂号不只是查询它在放号那一刻会产生大量的写请求每个号票的状态要从“可预约”变成“已锁定”再变成“已支付”或者“已占用”。这种高并发写和电商秒杀是同一个量级的问题但挂号系统对数据准确性的要求一点也不低——号源绝对不能超卖这是红线。第二业务链路长。一个完整的挂号流程从用户选择科室、选择医生、选择时间段、确认挂号到生成订单、扣减号源、支付或者医保结算最后还要通知到用户的微信或者 App涉及多个环节。这些环节之间任何一个崩溃都会导致用户投诉。单体应用在流量不足的时候什么问题都没有一旦到了放号瞬间数据库连接被占满接口超时前端反复重试反而制造了更多请求最后把系统彻底打挂。超时的下单请求还有可能产生重复订单被用户反复提交的请求也会造成号源被重复锁定。所以分布式不是跟风而是这家系统在业务模型上就天然需要。1.2 分布式改造要解决的三个核心问题分布式架构不是把模块拆开就完事它本质上是用一套新的约束来解决单体在资源隔离、故障隔离、弹性扩容上的短板。对挂号系统来说核心要解决三个问题并发控制号源是全局唯一性的资源在多个服务实例同时处理挂号请求时必须保证同一个号票只会被一个请求成功扣减。这个靠数据库行锁能做但纯靠数据库扛不住放号瞬间的 QPS所以需要引入 Redis配合精细的库存扣减方案。数据一致性订单生成、号源扣减、患者信息更新通常分散在不同服务里服务间通过接口或者消息通信任何一步失败都可能造成数据对不上。分布式事务要在这里做取舍不能所有操作都去搞强一致否则性能和复杂度都会爆炸。弹性与高可用单体的扩容是“换更大的机器”分布式的扩容是“加机器”。挂号系统需要包住放号高峰、平时又不需要那么多资源所以容器化部署、服务注册发现、负载均衡是标配。说到这一步我特别想提醒一个事团队在做分布式改造之前一定要先把业务边界画清楚而不是一上来就按“技术优雅”去拆服务。我们项目里把患者、号源、订单这几个核心域拆出来了但是支付和医保相关的业务因为医院信息科的授权链路非常复杂前期反而刻意保留在同一个服务里。分布式是手段不是目的拆多了只会让事务满天飞。1.3 我们最终确定的系统边界最终我们划分了这么几个可独立部署的运行单元服务职责关键依赖user-service患者注册、登录、就诊人管理MySQL, Redisschedule-service科室/医生/排班/号源管理放号逻辑MySQL, Redis, MQorder-service挂号订单、状态机流转、取消挂号MySQL, Redis, MQgateway统一入口、路由、鉴权、限流Nginx / Spring Cloud Gateway服务之间通过 OpenFeign 做同步调用号源变动和订单事件通过 RocketMQ 做异步解耦。这个划分不是一次定死的而是从单体往里孵化的——先做模块化再逐步把核心热点的模块拆成独立服务。这一点后面会细讲。2. 技术选型复盘SpringBoot3 和 Vue3 到底带来什么2.1 SpringBoot3 的选择逻辑在 SpringBoot 2.7 还在被大量使用时选择 SpringBoot3 是需要一点勇气的。SpringBoot3 最核心的变化是基于 JDK17 构建完全拥抱了 Jakarta EE 的命名空间还记得 javax 改成 jakarta 那波迁移吗同时也默认接入了 Spring Framework 6。对挂号系统这种需要长期维护的医疗类业务我的择型标准是框架至少还有 5 年以上的维护周期。SpringBoot 2.7 在 2025 年左右会结束社区支持新项目再选它就等于一开始就欠了技术债。当然SpringBoot3 也带来一些实打实的好处基于 JDK17 的虚拟线程、switch 表达式、密封接口等新特性在后续做性能优化时会有更多手段。Spring Security 6 的配置方式大变原来 WebSecurityConfigurerAdapter 那套彻底废弃新项目必须直接使用 SecurityFilterChain 组件。这个迁移成本很痛但确实让安全配置更清晰。原生镜像GraalVM Native Image支持更完善虽然医院项目为了兼容性我们没有上原生编译但留了这个余地。实际问题中也踩了不少坑。比如 SpringBoot3 默认的路径匹配策略从 AntPathMatcher 换成了 PathPatternParser对路径中特殊字符的容忍度完全不同再比如 Spring Cloud 版本必须用 2022.x 以上才能和 SpringBoot3 兼容组件版本全都得跟着调。这些在第七节我会统一归档。2.2 为什么前端选 Vue3 而不是继续用 Vue2医院的旧系统前端是 Vue2 Element UI说实话维护到后面组件一多状态管理基本靠 this.$store复用逻辑全靠 mixin代码内聚性很差。这次重构我直接选了 Vue3 Vite TypeScript Pinia 这套组合原因很实际。Vue3 的 Composition API 让挂号这类复杂流程的代码组织方式完全不同。以前一个挂号弹窗组件data、methods、computed、watch 分散在各自区域现在可以按业务逻辑聚合一个“号源选择”的 useSchedule 逻辑做完组件里只剩薄薄一层模板。Vite 的开发体验确实快冷启动秒级热更新基本是即时的。旧项目用 webpack 开发时改一行代码重启等好几秒这种体验差距在迭代排期紧的时候感受特别明显。TypeScript 对医疗领域的价值在于数据契约。挂号系统里排班、号源、就诊人都有非常明确的字段结构用了 TS 之后前端拿到的接口返回直接有类型提示阶段性重构的安全性提高了很多。这里要说一下网上很多人问“Vue3 要不要用 setup 语法糖”“要不要用 Pinia”我的答案是新项目直接用别纠结。Composition API script setup Pinia 是 Vue3 社区演化出来的主流写法和标准实践Vue2 那套 Option API 的思维要主动切换不然你只是白学了 Vue3。2.3 中间件选型不追求时髦只看场景挂号系统的中间件选型我们是按数据特征来定的。MySQL 8.0是主存储。号源、排班、患者、订单这些核心数据都在 MySQL 里使用 InnoDB 引擎事务支持是刚需。表结构设计上要特别注意索引预约查询的条件组合科室医生日期必须建立联合索引。Redis 6.x做三件事一是做分布式锁保护号源扣减二是缓存热门科室的排班列表三是存登录态和验证码。Redis 我们用的是主从加哨兵读写分离放号高峰期读流量非常大。RocketMQ用于异步化订单状态通知、取消超时订单、放号后的消息推送。选 RocketMQ 而不是 RabbitMQ主要是团队熟悉度和事务消息能力。RocketMQ 对本地事务消息的支持对订单一致性很有帮助。Spring Cloud Alibaba这块注册中心用了 Nacos配置中心也用它服务间调用的负载均衡用 Spring Cloud LoadBalancer没有上太多重组件。熔断用的 Sentinel后面讲容灾时会提到。很多文章一上来就推荐上 K8s、上 Service Mesh我们这次落地的时候部署层面其实还只是用 Docker Compose 加多实例部署把服务注册到 Nacos 后通过网关做负载均衡。原因很直白医院项目的运维团队规模有限技术栈越复杂出问题时定位成本越高。分布式的核心是解耦业务和扩展能力不一定要把全部云原生全家桶都上齐。3. 系统架构与核心模块设计3.1 服务划分与调用链路整个系统的调用关系可以概括成一条主链路和几条支链路。主链路是用户通过网关进到前端页面然后前端去请求 order-service 下单order-service 再通过 OpenFeign 同步调用 schedule-service 扣减号源同时通过 MQ 发布订单事件发送短信或微信通知。支链路包括用户登录走 user-service顺便在 Redis 里刷新登录态管理员维护排班信息走 schedule-service 管理端接口退号操作由 order-service 完成状态流转再把释放号源的事件发给 schedule-service 去恢复可预约状态。这条链路上网关做了比较重要的一层事情统一鉴权JWT 解析、接口限流按用户在 Redis 里做令牌桶、以及简单的灰度路由。网关本身是无状态的可以水平扩容这样放号高峰时流量可以在网关这层先被削掉一部分后排服务压力能小很多。3.2 号源库存的数据模型设计号源库存是挂号系统里最需要下功夫的表。我见过很多“先写死了排班记录里剩多少号”的设计这种设计在并发一上来就会出问题。我们最终的模型是这样设计的doctor_schedule医生排班表记录医生在某一天、某个午别上午/下午、某个门诊类型下的排班核心字段包括排班日期、时段类型、总号源数、剩余号源数、排班状态。这里剩余号源数是一个“镜像字段”用于快速展示和判断是否可挂。schedule_number号源明细表每一个具体的号比如上午第 15 号都是一条记录字段包括排班 ID、号码段、状态可预约/锁定/已占用/已取消、占用订单号、占用患者 ID。order_info挂号订单表订单主表字段包括订单号、患者 ID、就诊人 ID、排班 ID、号源 ID、金额、支付状态、订单状态、创建时间、过期时间。为什么要有“总-明细”两层因为展示层需要快速知道还有没有号用排班表上的剩余字段就够了而扣减操作必须精确到一个具体的号位。如果只改排班表一个字段你就无法区分“哪些号被谁占了”退号释放也就无从谈起了。明细表每一行代表一个真实的号状态流转可以精确控制。3.3 排班管理模块的实现思路排班模块是医院运营侧最常操作的部分。我们做了一套排班管理后台医生或科室管理员可以在后台批量导入一周的排班模板。排班时几个要点。排班生成要支持批量按科室、医生、起始日期、周几模式、号源数量生成未来 N 天的排班避免医生一天一天手动建。号源生成用事务每个排班记录至少对应 N 条号源明细使用批处理插入单次批量生成可以控制在几百到几千条。放号时间要支持配置不同科室放号时间不一样通过分布式定时任务用 XXL-Job去定时把排班状态从“未放号”改成“已放号”这样 8 点放号这个动作不是靠用户请求触发而是系统主动切换到可预约状态到了时间点用户一刷新就能看到号源。有个细节容易忽略放号时刻的并发不只是用户的抢号请求还有那些“定时轮询”的脚本、前端定时器自动刷新这些请求在放号瞬间也会涌进来。所以网关限流那块我们专门对“查询排班”接口设置了宽松策略高峰期允许更高的 QPS而写接口则严格按用户维度限流。4. 后端硬骨头号源扣减、分布式锁与事务一致性4.1 号源扣减为什么不能“先查再扣”很多初写挂号功能的同学代码习惯是这样的先查排班表剩余号数判断大于 0然后生成订单再 UPDATE 剩余号数 剩余号数 - 1。这套逻辑在并发量低时没问题在并发高的时候一定出事因为“查-判断-更新”不是原子的两个请求可能同时读到剩余号数等于 1然后两个都认为自己成功占了号最后超卖。解决超卖最直接的手段是让扣减操作变成原子 SQL。我们可以写成UPDATE doctor_schedule SET remain_number remain_number - 1 WHERE id #{scheduleId} AND remain_number 0这种方式用数据库的行锁保证了“检查剩余量和扣减剩余量”是同一个原子操作。影响行数为 1 说明扣减成功否则说明没有可用号源。这是最底层的保底方案稳定性最好。但是纯靠数据库行锁有一个问题在高并发下大量请求同时阻塞在 UPDATE 这一行记录上数据库压力比较大。而且如果业务上还需要“锁定一个具体的号源明细”操作会更复杂。所以我们在实际架构上采用两层保护上层用 Redis 预扣减快速拦截大部分流量底层用数据库行锁兜底保证绝对不超卖。两层方案的好处是性能和安全都照顾到了坏处是实现复杂度高后面展开讲。4.2 Redis 分布式锁的正确姿势我们给号源预扣减设计了一套基于 Redis 的库存扣减方案核心是用 Lua 脚本原子地执行“检查扣减”逻辑-- 参数KEYS[1]号源库存keyKEYS[2]用户维度keyARGV[1]扣减数量 local remain redis.call(GET, KEYS[1]) if tonumber(remain) tonumber(ARGV[1]) then return 0 end redis.call(DECRBY, KEYS[1], ARGV[1]) redis.call(SET, KEYS[2], 1, EX, 60) return 1用户在请求下单时先去 Redis 执行这个 Lua 脚本如果 Redis 返回 0 说明号被抢完了直接提示用户失败如果返回 1再走数据库的原子扣减和订单生成。这个 Redis 预扣减解决的不是正确性问题正确性有数据库兜底而是性能问题——它用一个接近内存速度的操作把大部分没有号源的请求挡在外面避免所有请求都打到数据库。但是这里很容易踩两个坑。第一个坑是 Redis 的 Key 过期策略。如果我们给库存 Key 设置了过期时间一旦 Key 过期存量信息全部丢失Redis 和数据库的数据就不一致了。正确的做法是库存 Key 不设置过期时间只有用户维度的防重 Key 才设置过期时间。库存的清理交给定期任务或者业务结束时的归档逻辑。第二个坑是分布式锁的“坑位”到底锁什么。很多人喜欢用一个全局的“号源锁”字符串做锁比如 lock:schedule:1001然后所有请求抢同一把锁。这种设计在放号高峰时会让锁变成严重的串行瓶颈。更合理的做法是把锁的粒度缩小到具体号段或者干脆不用锁用上面的 Lua 原子扣减毕竟 Redis 本身能保证 Lua 脚本的原子性不需要再去得一把锁做互斥。实际上“Redis 分布式锁”这个词在面试和技术文章里被过度强化了。在号源扣减这个场景里最优雅的 Redis 方案往往不是 Redisson 的 lock而是用 Lua 脚本做原子操作。Redisson 分布式锁更适合那些需要“跨多个操作互斥”的场景比如订单状态机流转时防止一个订单同时被两个线程处理。4.3 分布式事务能不用强一致就不用分布式改造之后最让人头疼的就是跨服务的数据一致性。在挂号系统里最典型的事务场景是用户下单时order-service 要新增订单schedule-service 要锁定号源还要考虑预付款的扣减。这三步跨了两个服务如果其中一个失败数据就分裂了。我们在这里做的取舍是订单创建和号源锁定同步调用使用 OpenFeign。schedule-service 内部在一个本地事务里完成号源明细的状态更新和排班剩余号的扣减。如果返回失败order-service 整体抛出异常订单不会落库。这个环节要的是强一致因为号源和订单是绑定的不能让订单存在而号源没锁。支付成功后的订单状态变更与通知异步化。支付回调进来order-service 更新本地订单状态然后发送一条“订单已支付”的 MQ 消息消息里带着订单号和号源信息。schedule-service 消费消息把号源状态从“锁定”更新为“已占用”。这一步用最终一致性因为号源“已占用”这个状态稍微晚几秒更新没关系用户能接受。跨两个服务之间的同步调用如果担心对方服务执行了事务但响应超时比如网络问题导致应答丢失我们需要引入幂等和补偿。做法是每个订单都有一个唯一的幂等键schedule-service 的号源锁定接口使用这个订单号做防重同样的订单号重复调用不会重复锁号。这样即使上游重试也不会导致同一次请求被处理两次。很多人一上来就想上 Seata 做全局事务我建议谨慎。Seata 这种 AT 模式的全局锁对数据库性能影响很大尤其在高并发写场景下全局锁的开销甚至会让整个系统变慢。挂号系统里真正需要强一致的环节非常少绝大多数业务都可以通过“本地事务消息表幂等消费”来达到最终一致。能用最终一致解决的绝不强行全局事务这是分布式实践里的一个正向设计原则。4.4 缓存策略不只是把数据塞进 Redis挂号的读流量远大于写流量尤其是页面上的排班列表、科室列表这些“热点数据”如果不加缓存数据库会被查询打穿。我们做缓存时有三个点值得分享。缓存 Key 的设计要带业务维度。比如排班列表缓存 Key 设计成schedule:list:{hospitalId}:{deptId}:{date}这样不同科室不同日期的排班互相不影响。缓存过期时间设置为 60 秒左右放号前 900 秒预热核心科室排班避免放号瞬间大量缓存 Miss 全部打到数据库。缓存穿透的处理。如果有人疯狂刷一个不存在的排班 ID每次请求都会 Miss 然后打到数据库。布隆过滤器在这种场景能挡住大部分无效 key或者对“空结果”也做短暂缓存——即查询结果为 null 时也缓存一个空值过期时间短一点比如 10 秒。缓存雪崩的规避。大量缓存 Key 在同一秒过期会导致瞬间的数据库压力。处理办法很简单过期时间不是固定的每个 Key 在基础过期时间上加一个随机偏移量比如 60 秒到 180 秒之间随机避免在同一时刻集体失效。还有一个在挂号场景里特别容易踩的坑不要把缓存当作数据的唯一来源。比如用户在挂号前前端展示“剩余 5 个号”但这只是缓存的快照下单时必须以数据库的实时数据为准。如果用户看到有号但实际下单时失败要给出友好提示而不是让请求在缓存上无限重试。缓存是性能层数据库才是真相层。5. Vue3 前端工程化落地5.1 从 Vite 初始化到目录划分前端我们用 Vite 创建了 Vue3 TypeScript 项目目录结构按照“功能模块公共层”来组织src/ api/ # 接口请求封装按模块拆分user.ts, schedule.ts, order.ts assets/ components/ # 公共组件DatePicker, DeptTree, DoctorCard 等 composables/ # 业务复用逻辑useSchedule, useOrder, useAuth router/ # 路由配置 导航守卫 stores/ # Pinia 状态userStore, orderStore views/ # 页面组件hospital, schedule, order, user, admin types/ # 全局 TS 类型定义 utils/ # 工具函数request.ts, auth.ts, format.ts其中 request.ts 是基于 Axios 二次封装的统一请求层做了三件核心事情注入 JWT Token 到 Header、统一错误码处理、401 时自动跳转登录页并刷新 Token。这个统一请求层是整个前后端联调不混乱的基础。5.2 Composition API 在实际业务中的组织方式很多人觉得 Composition API 无非是把 data 换成 ref、把 methods 换成 function其实这是很大的误解。Composition API 真正的价值是“按逻辑关注点组织代码”而不是“按选项类型组织代码”。以挂号流程为例如果没有 Composition API同一个流程的状态可能分散在组件的多个选项中——data 里放排班数据、methods 里放加载函数、computed 里放可选号源判断、watch 里放医生变化后的重新加载逻辑。这些代码之间是强关联的但位置隔得很远。用 Composition API我可以把所有跟“号源选择”相关的状态和逻辑抽到一个 composable 里// composables/useSchedule.ts import { ref, watch } from vue import { getScheduleList } from /api/schedule export interface ScheduleItem { id: number date: string period: AM | PM | EVENING doctorName: string deptName: string remainNumber: number totalNumber: number } export function useSchedule() { const scheduleList refScheduleItem[]([]) const loading ref(false) const selectedDate ref() const selectedDoctorId refnumber | null(null) async function loadSchedule() { loading.value true try { scheduleList.value await getScheduleList({ date: selectedDate.value, doctorId: selectedDoctorId.value }) } finally { loading.value false } } watch([selectedDate, selectedDoctorId], loadSchedule) return { scheduleList, loading, selectedDate, selectedDoctorId, loadSchedule } }组件里直接const { scheduleList, selectedDate, loadSchedule } useSchedule()就可以用了。这套方式的好处是同一个业务逻辑可以在多个组件中复用而且测试的时候可以脱离 Vue 组件单独测这个 composable。5.3 挂号流程的前端交互细节挂号页面是用户接触最多的页面交互细节直接决定用户会不会投诉。我们总结了一套体验标准。科室选择这块左侧是科室树右侧是医生列表。选择科室后请求医生列表这个请求要用防抖加缓存避免用户频繁点击造成多余请求。排班展示方面医生卡片展示出诊日期可预约的日期高亮不可预约的置灰。每天排班按上午、下午、晚间三个时段展示号源剩余数量实时显示如果剩余为 0 则按钮禁用并提示“约满”。就诊人选择上用户下单选就诊人一个用户最多可以绑定多个就诊人选择后展示就诊人卡片信息并提供“新增就诊人”入口。订单确认页要展示患者信息、医生信息、就诊时间、挂号费用用户确认后点击“提交挂号”。提交时按钮置为 loading 状态防止重复提交。排队与结果反馈也很关键。如果放号高峰期后端处理慢前端不能直接让用户干等要做“提交中”的进度反馈。提交成功后跳到挂号成功页包含订单号、预约时间、取号方式等提交失败要能区分是“号源被抢完”还是“网络异常”分别给出不同提示。这里有个常见的坑用户连续点击提交按钮导致重复订单。我们在前端用防重复提交loading 态加禁用按钮做了第一层拦截但真正的兜底在后端——订单模块要求同一个用户同一时间段只能有一个未支付订单数据库层面做一个唯一索引或应用层做幂等校验。5.4 与后端联调的鉴权链路前端通过登录接口获取 JWT Token存到 Pinia 里同时持久化到 localStorage。Axios 请求拦截器把 Token 加到 Authorization 头网关解析并校验。这里踩过一个坑Vue Router 的导航守卫里做登录判断时不能只判断 localStorage 里有没有 Token因为 Token 可能过期。我们处理方式是导航守卫只做本地判断如果本地没有 Token 直接跳登录页如果有 Token则交给请求层的 401 拦截当后端返回未授权时清理本地 Token 并跳转登录页同时记录用户原来的路由登录成功后可以跳回。这个“跳回去”的体验细节很多系统做得不好。6. 压测、缓存与上线前的体检6.1 JMeter 压测怎么设计才贴近真实上线前我们最担心的就是放号瞬间的并发表现所以用 JMeter 做了一轮完整的压测。压测设计不能只想着“在线程组里填 5000 个线程数”而要贴近真实用户的行为模型。登录用户分布压测数据要覆盖不同就诊人、不同科室、不同时间段不能所有请求都打同一个排班 ID。请求节奏放号场景是“瞬间涌入”所以 JMeter 要设置同时启动Ramp-Up 设为 0模拟第一批用户同时抢号还要叠加一个“持续轮询”的线程组模拟老用户不断刷新查看号源。断言不能只看吞吐量还要看业务成功率。压测时我们会把“下单成功响应”和“号源已满响应”分开统计只要下单成功的响应数量加号源已满数量约等于总请求数说明没有请求是因为系统错误而失败。压测后发现的一个典型问题是数据库连接池大小设置偏小导致高并发时大量线程等待获取连接。我们把 HikariCP 的最大连接数从默认的 10 调到了 50配合数据库 max_connections同时把获取连接超时时间从 30 秒降到 3 秒快速失败比无限等待对用户体验更好。6.2 重点接口的缓存预热与降级放号前大量用户会集中在页面上等待这时候如果缓存是冷的会有一波“查询 Miss 风暴”。我们在 XXL-Job 里增加了一个定时任务在放号前 15 分钟预热核心科室的排班缓存把预计持仓量大的科室排班数据提前写入 Redis。同时要设计降级开关。比如 Redis 集群如果出现异常排班查询接口不能直接报错而是要降级到数据库直查如果数据库也扛不住那至少保证“下单”功能可用查询列表可以短暂降级为返回默认科室数据。降级开关放在 Nacos 配置中心里运维人员不用改代码重启就能切换。6.3 上线后的持续监控与日志链路分布式系统排查问题最大的困难是“定位于哪个服务”。我们给每个请求生成了一个 traceId在网关层生成后通过 MDC 写入日志Feign 调用时透传到下游服务最终在日志系统里按 traceId 串起全链路。医疗系统的业务日志尤其要记录完整责任人、医生、患者、时间点都要能从一条日志里追溯出来。监控除了基础的服务健康检查、CPU、内存指标外我们还特别关注两个业务指标号源超卖数量和订单成功率。这两个指标直接反映核心架构是否健康我们把这些做成告警一旦超卖数量大于 0 或者成功率低于阈值立刻触发响应而不是等用户投诉。7. 实战踩坑记录这些坑你们大概率也会遇到7.1 SpringBoot3 迁移的版本坑SpringBoot3 加 Spring Cloud Alibaba 的版本匹配是第一个大坑。Spring Cloud Alibaba 在 2023 年之前对 SpringBoot3 的支持并不完善当时我们使用的是 2022.x 版本系列必须对照官方版本说明逐一对齐。如果版本不对启动时会出现各种诡异的 BeanNotDefined 或者注解不识别问题排查起来非常浪费时间。第二个坑是路径匹配策略。SpringBoot3 默认使用 PathPatternParser原来 SpringBoot2 的**通配和尾斜杠兼容行为不一样。如果你们从 SpringBoot2 升级接口路径里有正则表达式或者特殊字符很可能在升级后出现 404。我们的解决方式比较简单粗暴把所有 controller 路径统一校准成不带特殊字符的简洁风格。第三个坑是 Spring Security 6 的配置变化。旧写法 HttpSecurity 配置那一套全变了SecurityFilterChain 成为标配。我们项目还在 JWT 鉴权上费了不少劲原来的 antMatchers 变成了 requestMatchers语义更准确了但迁移成本实实在在。7.2 Vue3 反模式响应式丢失与滥用 RefVue3 里最常见的坑之一是响应式丢失。比如从接口返回值里解构出一个属性然后直接改这个属性页面不会更新。因为解构出来的变量已经失去了 Proxy 的代理能力。新手经常在表单提交后想const { data } await getInfo()然后data.name xxx结果页面死活不刷新。正确的做法是全程使用响应式对象const data ref()再data.value (await getInfo()).data或者用 toRefs 保留响应式连接。另一个反模式是所有东西都塞 ref。我在 Code Review 时经常看到有人把整个表单对象拆成十几个 ref然后到处写 .value。这不但没利用好 Vue3 的优势反而比 Option API 更啰嗦。合理做法是把一组强相关的数据聚合成一个 reactive 对象或者直接使用一个 Store 管理。Composition API 给你的是组织代码的自由不是逼你把所有变量都变成 ref。7.3 关于分布式对中小团队的再思考最后想聊聊技术之外的事。这套系统上线后放号高峰期从原来的“系统瘫痪半小时”变成了“稳定撑过放号高峰”效果可以说是立竿见影。但我也必须说分布式架构带来了一套全新的运维负担——服务变多了排查链路变长了部署步骤变多了连日志都要集中收集。如果你们的团队只有两三个人业务量也远没到“单库单表扛不住”的地步我真心建议先做好单体应用内的模块化把接口设计、缓存设计、幂等设计做扎实。等用户量真的上来了再把热点模块拆出去。我们这次就是因为前期模块边界清晰后面拆服务时才没有伤筋动骨。如果一定要说点什么心得我会讲分布式不是银弹它的价值在于让系统能优雅地扛住“放号瞬间”这样的业务高峰。真正值得投入精力的是对业务并发模型的理解、对数据一致性的严谨设计以及对每一个坑都留好预案。希望这篇项目复盘能给你们正在做挂号系统的同学一些启发也欢迎交流你们在类似架构上遇到过的问题。
医院预约挂号系统重构：SpringBoot3+Vue3分布式实战
去年接手了一个市级医院的预约挂号系统重构项目。原来那套单体应用每到周一早上八点放号就会有一大批用户同时涌进来抢号源数据库连接池直接被打满接口超时、下单失败、号源超卖各种问题一起爆出来。医院信息科的同事一提到“放号”两个字就头疼。后来我们用 SpringBoot3 Vue3 把整个系统重构成一套分布式架构的医疗挂号系统才彻底把这个场景扛下来。这篇文章就把这次改造的完整思路和实现过程整理出来包含架构设计、核心代码逻辑、分布式锁和分布式事务的处理方式以及 Vue3 前端工程化的落地实践给正准备做类似系统的同学一个参考。1. 为什么挂号系统必须先考虑分布式1.1 挂号业务的特点典型的“瞬时高并发”场景挂号系统和其他业务系统最大的区别在于流量模型。它不是每分钟均匀地来请求而是集中在放号那一刻爆发。以我们接入的一家三甲医院为例周一到周五每天早上8点放未来7天的号源光是口腔科、儿科、心内科这几个热门科室同时在线抢号的用户可能就有几千甚至上万人。而真正引起问题的不只是流量大还有两个特性。第一写多读也多。挂号不只是查询它在放号那一刻会产生大量的写请求每个号票的状态要从“可预约”变成“已锁定”再变成“已支付”或者“已占用”。这种高并发写和电商秒杀是同一个量级的问题但挂号系统对数据准确性的要求一点也不低——号源绝对不能超卖这是红线。第二业务链路长。一个完整的挂号流程从用户选择科室、选择医生、选择时间段、确认挂号到生成订单、扣减号源、支付或者医保结算最后还要通知到用户的微信或者 App涉及多个环节。这些环节之间任何一个崩溃都会导致用户投诉。单体应用在流量不足的时候什么问题都没有一旦到了放号瞬间数据库连接被占满接口超时前端反复重试反而制造了更多请求最后把系统彻底打挂。超时的下单请求还有可能产生重复订单被用户反复提交的请求也会造成号源被重复锁定。所以分布式不是跟风而是这家系统在业务模型上就天然需要。1.2 分布式改造要解决的三个核心问题分布式架构不是把模块拆开就完事它本质上是用一套新的约束来解决单体在资源隔离、故障隔离、弹性扩容上的短板。对挂号系统来说核心要解决三个问题并发控制号源是全局唯一性的资源在多个服务实例同时处理挂号请求时必须保证同一个号票只会被一个请求成功扣减。这个靠数据库行锁能做但纯靠数据库扛不住放号瞬间的 QPS所以需要引入 Redis配合精细的库存扣减方案。数据一致性订单生成、号源扣减、患者信息更新通常分散在不同服务里服务间通过接口或者消息通信任何一步失败都可能造成数据对不上。分布式事务要在这里做取舍不能所有操作都去搞强一致否则性能和复杂度都会爆炸。弹性与高可用单体的扩容是“换更大的机器”分布式的扩容是“加机器”。挂号系统需要包住放号高峰、平时又不需要那么多资源所以容器化部署、服务注册发现、负载均衡是标配。说到这一步我特别想提醒一个事团队在做分布式改造之前一定要先把业务边界画清楚而不是一上来就按“技术优雅”去拆服务。我们项目里把患者、号源、订单这几个核心域拆出来了但是支付和医保相关的业务因为医院信息科的授权链路非常复杂前期反而刻意保留在同一个服务里。分布式是手段不是目的拆多了只会让事务满天飞。1.3 我们最终确定的系统边界最终我们划分了这么几个可独立部署的运行单元服务职责关键依赖user-service患者注册、登录、就诊人管理MySQL, Redisschedule-service科室/医生/排班/号源管理放号逻辑MySQL, Redis, MQorder-service挂号订单、状态机流转、取消挂号MySQL, Redis, MQgateway统一入口、路由、鉴权、限流Nginx / Spring Cloud Gateway服务之间通过 OpenFeign 做同步调用号源变动和订单事件通过 RocketMQ 做异步解耦。这个划分不是一次定死的而是从单体往里孵化的——先做模块化再逐步把核心热点的模块拆成独立服务。这一点后面会细讲。2. 技术选型复盘SpringBoot3 和 Vue3 到底带来什么2.1 SpringBoot3 的选择逻辑在 SpringBoot 2.7 还在被大量使用时选择 SpringBoot3 是需要一点勇气的。SpringBoot3 最核心的变化是基于 JDK17 构建完全拥抱了 Jakarta EE 的命名空间还记得 javax 改成 jakarta 那波迁移吗同时也默认接入了 Spring Framework 6。对挂号系统这种需要长期维护的医疗类业务我的择型标准是框架至少还有 5 年以上的维护周期。SpringBoot 2.7 在 2025 年左右会结束社区支持新项目再选它就等于一开始就欠了技术债。当然SpringBoot3 也带来一些实打实的好处基于 JDK17 的虚拟线程、switch 表达式、密封接口等新特性在后续做性能优化时会有更多手段。Spring Security 6 的配置方式大变原来 WebSecurityConfigurerAdapter 那套彻底废弃新项目必须直接使用 SecurityFilterChain 组件。这个迁移成本很痛但确实让安全配置更清晰。原生镜像GraalVM Native Image支持更完善虽然医院项目为了兼容性我们没有上原生编译但留了这个余地。实际问题中也踩了不少坑。比如 SpringBoot3 默认的路径匹配策略从 AntPathMatcher 换成了 PathPatternParser对路径中特殊字符的容忍度完全不同再比如 Spring Cloud 版本必须用 2022.x 以上才能和 SpringBoot3 兼容组件版本全都得跟着调。这些在第七节我会统一归档。2.2 为什么前端选 Vue3 而不是继续用 Vue2医院的旧系统前端是 Vue2 Element UI说实话维护到后面组件一多状态管理基本靠 this.$store复用逻辑全靠 mixin代码内聚性很差。这次重构我直接选了 Vue3 Vite TypeScript Pinia 这套组合原因很实际。Vue3 的 Composition API 让挂号这类复杂流程的代码组织方式完全不同。以前一个挂号弹窗组件data、methods、computed、watch 分散在各自区域现在可以按业务逻辑聚合一个“号源选择”的 useSchedule 逻辑做完组件里只剩薄薄一层模板。Vite 的开发体验确实快冷启动秒级热更新基本是即时的。旧项目用 webpack 开发时改一行代码重启等好几秒这种体验差距在迭代排期紧的时候感受特别明显。TypeScript 对医疗领域的价值在于数据契约。挂号系统里排班、号源、就诊人都有非常明确的字段结构用了 TS 之后前端拿到的接口返回直接有类型提示阶段性重构的安全性提高了很多。这里要说一下网上很多人问“Vue3 要不要用 setup 语法糖”“要不要用 Pinia”我的答案是新项目直接用别纠结。Composition API script setup Pinia 是 Vue3 社区演化出来的主流写法和标准实践Vue2 那套 Option API 的思维要主动切换不然你只是白学了 Vue3。2.3 中间件选型不追求时髦只看场景挂号系统的中间件选型我们是按数据特征来定的。MySQL 8.0是主存储。号源、排班、患者、订单这些核心数据都在 MySQL 里使用 InnoDB 引擎事务支持是刚需。表结构设计上要特别注意索引预约查询的条件组合科室医生日期必须建立联合索引。Redis 6.x做三件事一是做分布式锁保护号源扣减二是缓存热门科室的排班列表三是存登录态和验证码。Redis 我们用的是主从加哨兵读写分离放号高峰期读流量非常大。RocketMQ用于异步化订单状态通知、取消超时订单、放号后的消息推送。选 RocketMQ 而不是 RabbitMQ主要是团队熟悉度和事务消息能力。RocketMQ 对本地事务消息的支持对订单一致性很有帮助。Spring Cloud Alibaba这块注册中心用了 Nacos配置中心也用它服务间调用的负载均衡用 Spring Cloud LoadBalancer没有上太多重组件。熔断用的 Sentinel后面讲容灾时会提到。很多文章一上来就推荐上 K8s、上 Service Mesh我们这次落地的时候部署层面其实还只是用 Docker Compose 加多实例部署把服务注册到 Nacos 后通过网关做负载均衡。原因很直白医院项目的运维团队规模有限技术栈越复杂出问题时定位成本越高。分布式的核心是解耦业务和扩展能力不一定要把全部云原生全家桶都上齐。3. 系统架构与核心模块设计3.1 服务划分与调用链路整个系统的调用关系可以概括成一条主链路和几条支链路。主链路是用户通过网关进到前端页面然后前端去请求 order-service 下单order-service 再通过 OpenFeign 同步调用 schedule-service 扣减号源同时通过 MQ 发布订单事件发送短信或微信通知。支链路包括用户登录走 user-service顺便在 Redis 里刷新登录态管理员维护排班信息走 schedule-service 管理端接口退号操作由 order-service 完成状态流转再把释放号源的事件发给 schedule-service 去恢复可预约状态。这条链路上网关做了比较重要的一层事情统一鉴权JWT 解析、接口限流按用户在 Redis 里做令牌桶、以及简单的灰度路由。网关本身是无状态的可以水平扩容这样放号高峰时流量可以在网关这层先被削掉一部分后排服务压力能小很多。3.2 号源库存的数据模型设计号源库存是挂号系统里最需要下功夫的表。我见过很多“先写死了排班记录里剩多少号”的设计这种设计在并发一上来就会出问题。我们最终的模型是这样设计的doctor_schedule医生排班表记录医生在某一天、某个午别上午/下午、某个门诊类型下的排班核心字段包括排班日期、时段类型、总号源数、剩余号源数、排班状态。这里剩余号源数是一个“镜像字段”用于快速展示和判断是否可挂。schedule_number号源明细表每一个具体的号比如上午第 15 号都是一条记录字段包括排班 ID、号码段、状态可预约/锁定/已占用/已取消、占用订单号、占用患者 ID。order_info挂号订单表订单主表字段包括订单号、患者 ID、就诊人 ID、排班 ID、号源 ID、金额、支付状态、订单状态、创建时间、过期时间。为什么要有“总-明细”两层因为展示层需要快速知道还有没有号用排班表上的剩余字段就够了而扣减操作必须精确到一个具体的号位。如果只改排班表一个字段你就无法区分“哪些号被谁占了”退号释放也就无从谈起了。明细表每一行代表一个真实的号状态流转可以精确控制。3.3 排班管理模块的实现思路排班模块是医院运营侧最常操作的部分。我们做了一套排班管理后台医生或科室管理员可以在后台批量导入一周的排班模板。排班时几个要点。排班生成要支持批量按科室、医生、起始日期、周几模式、号源数量生成未来 N 天的排班避免医生一天一天手动建。号源生成用事务每个排班记录至少对应 N 条号源明细使用批处理插入单次批量生成可以控制在几百到几千条。放号时间要支持配置不同科室放号时间不一样通过分布式定时任务用 XXL-Job去定时把排班状态从“未放号”改成“已放号”这样 8 点放号这个动作不是靠用户请求触发而是系统主动切换到可预约状态到了时间点用户一刷新就能看到号源。有个细节容易忽略放号时刻的并发不只是用户的抢号请求还有那些“定时轮询”的脚本、前端定时器自动刷新这些请求在放号瞬间也会涌进来。所以网关限流那块我们专门对“查询排班”接口设置了宽松策略高峰期允许更高的 QPS而写接口则严格按用户维度限流。4. 后端硬骨头号源扣减、分布式锁与事务一致性4.1 号源扣减为什么不能“先查再扣”很多初写挂号功能的同学代码习惯是这样的先查排班表剩余号数判断大于 0然后生成订单再 UPDATE 剩余号数 剩余号数 - 1。这套逻辑在并发量低时没问题在并发高的时候一定出事因为“查-判断-更新”不是原子的两个请求可能同时读到剩余号数等于 1然后两个都认为自己成功占了号最后超卖。解决超卖最直接的手段是让扣减操作变成原子 SQL。我们可以写成UPDATE doctor_schedule SET remain_number remain_number - 1 WHERE id #{scheduleId} AND remain_number 0这种方式用数据库的行锁保证了“检查剩余量和扣减剩余量”是同一个原子操作。影响行数为 1 说明扣减成功否则说明没有可用号源。这是最底层的保底方案稳定性最好。但是纯靠数据库行锁有一个问题在高并发下大量请求同时阻塞在 UPDATE 这一行记录上数据库压力比较大。而且如果业务上还需要“锁定一个具体的号源明细”操作会更复杂。所以我们在实际架构上采用两层保护上层用 Redis 预扣减快速拦截大部分流量底层用数据库行锁兜底保证绝对不超卖。两层方案的好处是性能和安全都照顾到了坏处是实现复杂度高后面展开讲。4.2 Redis 分布式锁的正确姿势我们给号源预扣减设计了一套基于 Redis 的库存扣减方案核心是用 Lua 脚本原子地执行“检查扣减”逻辑-- 参数KEYS[1]号源库存keyKEYS[2]用户维度keyARGV[1]扣减数量 local remain redis.call(GET, KEYS[1]) if tonumber(remain) tonumber(ARGV[1]) then return 0 end redis.call(DECRBY, KEYS[1], ARGV[1]) redis.call(SET, KEYS[2], 1, EX, 60) return 1用户在请求下单时先去 Redis 执行这个 Lua 脚本如果 Redis 返回 0 说明号被抢完了直接提示用户失败如果返回 1再走数据库的原子扣减和订单生成。这个 Redis 预扣减解决的不是正确性问题正确性有数据库兜底而是性能问题——它用一个接近内存速度的操作把大部分没有号源的请求挡在外面避免所有请求都打到数据库。但是这里很容易踩两个坑。第一个坑是 Redis 的 Key 过期策略。如果我们给库存 Key 设置了过期时间一旦 Key 过期存量信息全部丢失Redis 和数据库的数据就不一致了。正确的做法是库存 Key 不设置过期时间只有用户维度的防重 Key 才设置过期时间。库存的清理交给定期任务或者业务结束时的归档逻辑。第二个坑是分布式锁的“坑位”到底锁什么。很多人喜欢用一个全局的“号源锁”字符串做锁比如 lock:schedule:1001然后所有请求抢同一把锁。这种设计在放号高峰时会让锁变成严重的串行瓶颈。更合理的做法是把锁的粒度缩小到具体号段或者干脆不用锁用上面的 Lua 原子扣减毕竟 Redis 本身能保证 Lua 脚本的原子性不需要再去得一把锁做互斥。实际上“Redis 分布式锁”这个词在面试和技术文章里被过度强化了。在号源扣减这个场景里最优雅的 Redis 方案往往不是 Redisson 的 lock而是用 Lua 脚本做原子操作。Redisson 分布式锁更适合那些需要“跨多个操作互斥”的场景比如订单状态机流转时防止一个订单同时被两个线程处理。4.3 分布式事务能不用强一致就不用分布式改造之后最让人头疼的就是跨服务的数据一致性。在挂号系统里最典型的事务场景是用户下单时order-service 要新增订单schedule-service 要锁定号源还要考虑预付款的扣减。这三步跨了两个服务如果其中一个失败数据就分裂了。我们在这里做的取舍是订单创建和号源锁定同步调用使用 OpenFeign。schedule-service 内部在一个本地事务里完成号源明细的状态更新和排班剩余号的扣减。如果返回失败order-service 整体抛出异常订单不会落库。这个环节要的是强一致因为号源和订单是绑定的不能让订单存在而号源没锁。支付成功后的订单状态变更与通知异步化。支付回调进来order-service 更新本地订单状态然后发送一条“订单已支付”的 MQ 消息消息里带着订单号和号源信息。schedule-service 消费消息把号源状态从“锁定”更新为“已占用”。这一步用最终一致性因为号源“已占用”这个状态稍微晚几秒更新没关系用户能接受。跨两个服务之间的同步调用如果担心对方服务执行了事务但响应超时比如网络问题导致应答丢失我们需要引入幂等和补偿。做法是每个订单都有一个唯一的幂等键schedule-service 的号源锁定接口使用这个订单号做防重同样的订单号重复调用不会重复锁号。这样即使上游重试也不会导致同一次请求被处理两次。很多人一上来就想上 Seata 做全局事务我建议谨慎。Seata 这种 AT 模式的全局锁对数据库性能影响很大尤其在高并发写场景下全局锁的开销甚至会让整个系统变慢。挂号系统里真正需要强一致的环节非常少绝大多数业务都可以通过“本地事务消息表幂等消费”来达到最终一致。能用最终一致解决的绝不强行全局事务这是分布式实践里的一个正向设计原则。4.4 缓存策略不只是把数据塞进 Redis挂号的读流量远大于写流量尤其是页面上的排班列表、科室列表这些“热点数据”如果不加缓存数据库会被查询打穿。我们做缓存时有三个点值得分享。缓存 Key 的设计要带业务维度。比如排班列表缓存 Key 设计成schedule:list:{hospitalId}:{deptId}:{date}这样不同科室不同日期的排班互相不影响。缓存过期时间设置为 60 秒左右放号前 900 秒预热核心科室排班避免放号瞬间大量缓存 Miss 全部打到数据库。缓存穿透的处理。如果有人疯狂刷一个不存在的排班 ID每次请求都会 Miss 然后打到数据库。布隆过滤器在这种场景能挡住大部分无效 key或者对“空结果”也做短暂缓存——即查询结果为 null 时也缓存一个空值过期时间短一点比如 10 秒。缓存雪崩的规避。大量缓存 Key 在同一秒过期会导致瞬间的数据库压力。处理办法很简单过期时间不是固定的每个 Key 在基础过期时间上加一个随机偏移量比如 60 秒到 180 秒之间随机避免在同一时刻集体失效。还有一个在挂号场景里特别容易踩的坑不要把缓存当作数据的唯一来源。比如用户在挂号前前端展示“剩余 5 个号”但这只是缓存的快照下单时必须以数据库的实时数据为准。如果用户看到有号但实际下单时失败要给出友好提示而不是让请求在缓存上无限重试。缓存是性能层数据库才是真相层。5. Vue3 前端工程化落地5.1 从 Vite 初始化到目录划分前端我们用 Vite 创建了 Vue3 TypeScript 项目目录结构按照“功能模块公共层”来组织src/ api/ # 接口请求封装按模块拆分user.ts, schedule.ts, order.ts assets/ components/ # 公共组件DatePicker, DeptTree, DoctorCard 等 composables/ # 业务复用逻辑useSchedule, useOrder, useAuth router/ # 路由配置 导航守卫 stores/ # Pinia 状态userStore, orderStore views/ # 页面组件hospital, schedule, order, user, admin types/ # 全局 TS 类型定义 utils/ # 工具函数request.ts, auth.ts, format.ts其中 request.ts 是基于 Axios 二次封装的统一请求层做了三件核心事情注入 JWT Token 到 Header、统一错误码处理、401 时自动跳转登录页并刷新 Token。这个统一请求层是整个前后端联调不混乱的基础。5.2 Composition API 在实际业务中的组织方式很多人觉得 Composition API 无非是把 data 换成 ref、把 methods 换成 function其实这是很大的误解。Composition API 真正的价值是“按逻辑关注点组织代码”而不是“按选项类型组织代码”。以挂号流程为例如果没有 Composition API同一个流程的状态可能分散在组件的多个选项中——data 里放排班数据、methods 里放加载函数、computed 里放可选号源判断、watch 里放医生变化后的重新加载逻辑。这些代码之间是强关联的但位置隔得很远。用 Composition API我可以把所有跟“号源选择”相关的状态和逻辑抽到一个 composable 里// composables/useSchedule.ts import { ref, watch } from vue import { getScheduleList } from /api/schedule export interface ScheduleItem { id: number date: string period: AM | PM | EVENING doctorName: string deptName: string remainNumber: number totalNumber: number } export function useSchedule() { const scheduleList refScheduleItem[]([]) const loading ref(false) const selectedDate ref() const selectedDoctorId refnumber | null(null) async function loadSchedule() { loading.value true try { scheduleList.value await getScheduleList({ date: selectedDate.value, doctorId: selectedDoctorId.value }) } finally { loading.value false } } watch([selectedDate, selectedDoctorId], loadSchedule) return { scheduleList, loading, selectedDate, selectedDoctorId, loadSchedule } }组件里直接const { scheduleList, selectedDate, loadSchedule } useSchedule()就可以用了。这套方式的好处是同一个业务逻辑可以在多个组件中复用而且测试的时候可以脱离 Vue 组件单独测这个 composable。5.3 挂号流程的前端交互细节挂号页面是用户接触最多的页面交互细节直接决定用户会不会投诉。我们总结了一套体验标准。科室选择这块左侧是科室树右侧是医生列表。选择科室后请求医生列表这个请求要用防抖加缓存避免用户频繁点击造成多余请求。排班展示方面医生卡片展示出诊日期可预约的日期高亮不可预约的置灰。每天排班按上午、下午、晚间三个时段展示号源剩余数量实时显示如果剩余为 0 则按钮禁用并提示“约满”。就诊人选择上用户下单选就诊人一个用户最多可以绑定多个就诊人选择后展示就诊人卡片信息并提供“新增就诊人”入口。订单确认页要展示患者信息、医生信息、就诊时间、挂号费用用户确认后点击“提交挂号”。提交时按钮置为 loading 状态防止重复提交。排队与结果反馈也很关键。如果放号高峰期后端处理慢前端不能直接让用户干等要做“提交中”的进度反馈。提交成功后跳到挂号成功页包含订单号、预约时间、取号方式等提交失败要能区分是“号源被抢完”还是“网络异常”分别给出不同提示。这里有个常见的坑用户连续点击提交按钮导致重复订单。我们在前端用防重复提交loading 态加禁用按钮做了第一层拦截但真正的兜底在后端——订单模块要求同一个用户同一时间段只能有一个未支付订单数据库层面做一个唯一索引或应用层做幂等校验。5.4 与后端联调的鉴权链路前端通过登录接口获取 JWT Token存到 Pinia 里同时持久化到 localStorage。Axios 请求拦截器把 Token 加到 Authorization 头网关解析并校验。这里踩过一个坑Vue Router 的导航守卫里做登录判断时不能只判断 localStorage 里有没有 Token因为 Token 可能过期。我们处理方式是导航守卫只做本地判断如果本地没有 Token 直接跳登录页如果有 Token则交给请求层的 401 拦截当后端返回未授权时清理本地 Token 并跳转登录页同时记录用户原来的路由登录成功后可以跳回。这个“跳回去”的体验细节很多系统做得不好。6. 压测、缓存与上线前的体检6.1 JMeter 压测怎么设计才贴近真实上线前我们最担心的就是放号瞬间的并发表现所以用 JMeter 做了一轮完整的压测。压测设计不能只想着“在线程组里填 5000 个线程数”而要贴近真实用户的行为模型。登录用户分布压测数据要覆盖不同就诊人、不同科室、不同时间段不能所有请求都打同一个排班 ID。请求节奏放号场景是“瞬间涌入”所以 JMeter 要设置同时启动Ramp-Up 设为 0模拟第一批用户同时抢号还要叠加一个“持续轮询”的线程组模拟老用户不断刷新查看号源。断言不能只看吞吐量还要看业务成功率。压测时我们会把“下单成功响应”和“号源已满响应”分开统计只要下单成功的响应数量加号源已满数量约等于总请求数说明没有请求是因为系统错误而失败。压测后发现的一个典型问题是数据库连接池大小设置偏小导致高并发时大量线程等待获取连接。我们把 HikariCP 的最大连接数从默认的 10 调到了 50配合数据库 max_connections同时把获取连接超时时间从 30 秒降到 3 秒快速失败比无限等待对用户体验更好。6.2 重点接口的缓存预热与降级放号前大量用户会集中在页面上等待这时候如果缓存是冷的会有一波“查询 Miss 风暴”。我们在 XXL-Job 里增加了一个定时任务在放号前 15 分钟预热核心科室的排班缓存把预计持仓量大的科室排班数据提前写入 Redis。同时要设计降级开关。比如 Redis 集群如果出现异常排班查询接口不能直接报错而是要降级到数据库直查如果数据库也扛不住那至少保证“下单”功能可用查询列表可以短暂降级为返回默认科室数据。降级开关放在 Nacos 配置中心里运维人员不用改代码重启就能切换。6.3 上线后的持续监控与日志链路分布式系统排查问题最大的困难是“定位于哪个服务”。我们给每个请求生成了一个 traceId在网关层生成后通过 MDC 写入日志Feign 调用时透传到下游服务最终在日志系统里按 traceId 串起全链路。医疗系统的业务日志尤其要记录完整责任人、医生、患者、时间点都要能从一条日志里追溯出来。监控除了基础的服务健康检查、CPU、内存指标外我们还特别关注两个业务指标号源超卖数量和订单成功率。这两个指标直接反映核心架构是否健康我们把这些做成告警一旦超卖数量大于 0 或者成功率低于阈值立刻触发响应而不是等用户投诉。7. 实战踩坑记录这些坑你们大概率也会遇到7.1 SpringBoot3 迁移的版本坑SpringBoot3 加 Spring Cloud Alibaba 的版本匹配是第一个大坑。Spring Cloud Alibaba 在 2023 年之前对 SpringBoot3 的支持并不完善当时我们使用的是 2022.x 版本系列必须对照官方版本说明逐一对齐。如果版本不对启动时会出现各种诡异的 BeanNotDefined 或者注解不识别问题排查起来非常浪费时间。第二个坑是路径匹配策略。SpringBoot3 默认使用 PathPatternParser原来 SpringBoot2 的**通配和尾斜杠兼容行为不一样。如果你们从 SpringBoot2 升级接口路径里有正则表达式或者特殊字符很可能在升级后出现 404。我们的解决方式比较简单粗暴把所有 controller 路径统一校准成不带特殊字符的简洁风格。第三个坑是 Spring Security 6 的配置变化。旧写法 HttpSecurity 配置那一套全变了SecurityFilterChain 成为标配。我们项目还在 JWT 鉴权上费了不少劲原来的 antMatchers 变成了 requestMatchers语义更准确了但迁移成本实实在在。7.2 Vue3 反模式响应式丢失与滥用 RefVue3 里最常见的坑之一是响应式丢失。比如从接口返回值里解构出一个属性然后直接改这个属性页面不会更新。因为解构出来的变量已经失去了 Proxy 的代理能力。新手经常在表单提交后想const { data } await getInfo()然后data.name xxx结果页面死活不刷新。正确的做法是全程使用响应式对象const data ref()再data.value (await getInfo()).data或者用 toRefs 保留响应式连接。另一个反模式是所有东西都塞 ref。我在 Code Review 时经常看到有人把整个表单对象拆成十几个 ref然后到处写 .value。这不但没利用好 Vue3 的优势反而比 Option API 更啰嗦。合理做法是把一组强相关的数据聚合成一个 reactive 对象或者直接使用一个 Store 管理。Composition API 给你的是组织代码的自由不是逼你把所有变量都变成 ref。7.3 关于分布式对中小团队的再思考最后想聊聊技术之外的事。这套系统上线后放号高峰期从原来的“系统瘫痪半小时”变成了“稳定撑过放号高峰”效果可以说是立竿见影。但我也必须说分布式架构带来了一套全新的运维负担——服务变多了排查链路变长了部署步骤变多了连日志都要集中收集。如果你们的团队只有两三个人业务量也远没到“单库单表扛不住”的地步我真心建议先做好单体应用内的模块化把接口设计、缓存设计、幂等设计做扎实。等用户量真的上来了再把热点模块拆出去。我们这次就是因为前期模块边界清晰后面拆服务时才没有伤筋动骨。如果一定要说点什么心得我会讲分布式不是银弹它的价值在于让系统能优雅地扛住“放号瞬间”这样的业务高峰。真正值得投入精力的是对业务并发模型的理解、对数据一致性的严谨设计以及对每一个坑都留好预案。希望这篇项目复盘能给你们正在做挂号系统的同学一些启发也欢迎交流你们在类似架构上遇到过的问题。
