Spring Boot+Vue.js云原生微服务门诊系统架构与容器化部署实践

要说门诊系统我最深的体会就是架构选型搞不好后期运维天天熬。前几年医院信息化建设普遍是单体应用挂号、缴费、医生工作站全塞在一个 WAR 包里高峰期一并发就卡死数据库连接池被打爆更别说新需求上线还要整个服务重启患者排队排到走廊。后来我们团队决定用“云原生微服务”思路重构这套门诊系统技术栈选了 Spring Boot Vue.js容器化部署直接上 Docker 和 Kubernetes。这篇文章就把我实际踩过的坑、整理过的架构方案、还有部署细节全拿出来分享给正在做医疗信息系统改造或者准备入行医疗信息化的朋友做个参考。这个项目要解决的问题很实在把门诊核心业务从单体拆成多个可独立部署的微服务前端用 Vue.js 做单页应用后端用 Spring Boot 快速构建服务然后全部容器化编排让系统具备弹性扩容、故障隔离、持续交付的能力。适合三类人看一是刚接触微服务想找真实案例的 Java 工程师二是要做前后端分离管理系统的前端开发三是负责医疗系统运维和部署的同事。我这篇不会讲太多虚的全部是能落地的方案和代码思路。1. 项目背景与架构设计思路1.1 传统门诊系统的痛点分析我在做这套系统之前看过太多旧门诊系统的真实状态。代码是十几年积累下来的挂号模块和收费模块写在同一个业务类里数据库表结构纠缠在一起甚至连患者信息和医生排班都混在一个库。这种单体结构在最开始上线的时候其实还不错毕竟业务量小一台服务器就能跑。但门诊系统的特点是典型的高并发短事务工作日早上 8 点到 11 点是就诊高峰挂号、收费、候诊叫号全部集中在这个时间段。单体应用一旦碰到这种流量尖峰问题就全暴露出来。首先是资源无法隔离。挂号模块把 CPU 和内存吃满了导致缴费模块跟着变慢医生开处方也卡。以前我们试过在代码里做各种缓存、加数据库连接池大小但治标不治本。其次是发布风险大。改一个挂号的 bug 也要重新打包整个系统稍不注意就会影响其他功能经常凌晨发布第二天早上又出问题。第三是扩展性差。想让挂号模块多跑几个实例来扛流量但因为是单体要么整体复制要么就只能在数据库层面去分库分表复杂度非常高。更现实的一个问题是团队协作。前端和后端如果耦合在一个工程里前端改个页面也需要后端发版。我们当时七八个人的小组天天为版本冲突发愁。后来下定决心做微服务其实就是被这几个痛点逼的。必须把系统拆开让每个模块能独立开发、独立测试、独立部署同时用容器化把环境标准化才能彻底解决这个问题。1.2 为什么选 Spring Boot Vue.js后端选 Spring Boot其实没什么好犹豫的。门诊系统核心是 Java 生态Spring Boot 2.x 之后的自动配置、starter 机制、内嵌 Tomcat让搭一个微服务项目像填空一样简单。配合 Spring Cloud Alibaba 的 Nacos 做服务发现和配置中心再配合 Sentinel 做限流熔断几乎就是国内做微服务的标准配置。我不用花大量时间在 XML 配置上专心写业务代码就行。选 Spring Boot 还有个考虑是生态。医疗系统需要对接医保接口、HIS 系统、各种检验设备这些厂商的 SDK 大部分都是 Java 的。比如我们对接的医保结算接口官方给的就是 JAR 包Spring Boot 里直接用依赖引入省了很大力气。如果换 Go 或者 Python这种对接成本就会高很多。前端用 Vue.js核心原因是团队上手快而且和 Spring Boot 的 JSON 接口天然合拍。Vue 的单文件组件结构特别适合门诊系统这种大量表单 列表 弹窗的交互场景。用 Vue 3 组合式 API 可以把挂号的逻辑拆得很干净用 Element Plus 组件库做界面也快不需要从头画 UI。另外 Vite 的开发服务器响应速度极快医生工作站给门诊医生用体验好很多。更重要的是前后端分离。Spring Boot 后端只暴露 RESTful APIVue 前端独立部署在 Nginx 里两边通过 Token 认证通信。这样前端团队不用管后端的负载均衡后端团队也不用管前端资源打包发布互不干扰。实际上这套结构也符合云原生的理念应用拆小容器部署前后端各自伸缩。1.3 微服务拆分与云原生的关系先说云原生。这个概念被炒了很多年但落到实际项目上我觉得核心就是四件事微服务架构、容器化、DevOps 流程、自动化运维。门诊系统作为业务系统不需要自己造云平台但我们要按云原生的方式把自己的应用改造成“云原生友好”的样子。微服务拆分是第一步。我们按业务域把门诊系统拆成了这样几个服务用户服务维护患者基本信息、医生信息、账号与登录。挂号服务处理号源排班、预约挂号、现场挂号、取消号。就诊服务门诊候诊、医生接诊、开立处方和检验检查申请。缴费服务处方费用计算、支付单创建、对接微信/支付宝/医保。排班服务医生排班规则、出诊计划、号源池管理。网关服务统一入口、路由转发、认证鉴权、限流。每个服务都独立数据库互不直接查表服务间只通过 API 或者消息通信。这样做的好处是数据边界清晰。比如挂号服务只管号源缴费服务只处理账单意图很明确。容器化部署是我们和云原生对齐的第二步。把 Spring Boot 服务打成镜像放入 Docker再通过 Kubernetes 编排。这一步做完之后每个服务的实例数量可以动态调整。挂号高峰期我们直接把挂号服务扩容到 6 个副本门诊结束后缩回 2 个整个过程不需要停服。这就是云原生微服务带来的最大价值。我一直跟同事说微服务本身不是目的容器化也不是目的目的是让系统具备快速迭代、资源弹性、故障自治的能力。从单体改成微服务最优先考虑的永远是业务边界而不是技术炫技。下面我分后端和前端两条线把具体实现步骤讲透。2. 后端微服务实践Spring Boot2.1 服务拆分与模块划分的实操方案拆服务不能拍脑袋要按业务能力来找边界。我们在拆的时候参考了一个原则高内聚低耦合数据私有化。每个服务自己拥有独立数据库表别的服务要用数据只能通过调用 API。比如用户服务里存着患者主索引挂号服务产生号源记录但挂号记录不直接读 users 表而是调用用户服务的接口获取患者姓名和身份证号。下面是我们最终落地的模块清单列出来方便你参考服务名核心职责独立表核心内容主要端口gateway统一入口、鉴权、路由无8080user-service患者/医生账号、基础档案user, doctor_profile8081schedule-service排班、号源池管理schedule, slot8082registration-service挂号和退号registration_order8083consultation-service候诊、接诊、诊断处方medical_record, prescription8084payment-service费用计算、支付单、对账fee_item, payment_order8085每个服务都是一个独立的 Spring Boot Maven 模块父工程用spring-boot-starter-parent统一管理依赖版本。我们直接使用了 Spring Cloud Alibaba 全家桶中的 Nacos 做注册中心和配置中心网关用 Spring Cloud Gateway服务间调用用 OpenFeign。启动的时候每个服务先连 Nacos把自己的实例信息注册上去网关从 Nacos 拉取服务列表做路由转发。这里有一个我之前踩过的坑第一个版本把 user-service 和 schedule-service 拆开之后挂号服务要同时查用户和排班信息。我们当时图省事在挂号服务里直接引了这两个服务的数据源结果微服务边界被破坏后面耦合越来越严重。正确的做法是不允许跨服务查数据库必须通过 Feign 调用。如果你现在也在做拆分一开始就要定死这条规则不然后患无穷。2.2 服务间通信与数据一致性的实现细节服务拆开之后最棘手的问题就是怎么通信。我们的原则是简单的同步查询用 OpenFeign异步不要求立即返回的操作用消息队列最终一致性优先。挂号这个场景非常适合用异步消息。患者挂号成功后用户服务和就诊服务都需要知道这次挂号事件。如果让挂号服务同步去调其他服务链路太长失败概率会增加。所以我们用 RocketMQ 发一个REGISTRATION_CREATED事件就诊服务监听这个事件把患者加入候诊队列用户服务更新患者的就诊状态。这样挂号服务只是把订单落库、发消息、返回成功请求时间非常短。数据一致性我们要重点看支付和挂号的状态。正常情况下患者先挂一个号生成待支付订单支付成功后挂号订单状态变成“已支付”同时号源要锁定。这里有个典型的分布式事务问题。我们没选择 Seata 这种强一致方案原因有两个一是医疗场景里跨服务调用链路长强事务会把系统拖慢二是我们最终能通过定时任务对账来兜底保证一致性。具体实现是支付服务创建订单后先冻结支付单。支付回调成功后支付服务更新支付单状态为“已支付”同时发送PAY_SUCCESS消息。挂号服务监听消息将对应挂号单置为“预约成功”。如果消息丢失我们有一个定时任务每 5 分钟比对一次支付服务里的成功支付单和挂号服务里的预约单自动补单。我自己实践下来这种“消息驱动 定时对账”模式应对门诊这个业务量完全够。不要一上来就上分布式事务框架那是给状态机特别复杂的业务准备的很多小团队用了反而坑更多。2.3 关键业务实现要点挂号、候诊、缴费这里挑几个最核心的业务实现讲一讲因为门诊系统能不能好用就看这几个点。挂号防重复与号源锁。 号源池表是slot里面有字段remaining_count和version。我们用了乐观锁来防止超挂SQL 上使用update slot set remaining_count remaining_count - 1, version version 1 where id ? and remaining_count 0更新行数等于 1 才算成功。如果不是 1就说明号源被抢完了直接返回“号源不足”。这个方案比分布式锁简单可靠因为数据库的行锁本身就是最安全的并发控制手段。候诊排队用 Redis。 挂号成功后并不代表马上能看诊患者要进入候诊队列。我们用 Redis 的 List 结构实现一个 FIFO 队列key 是clinic:queue:{doctorId}患者签到之后会在队尾追加patientId。医生点击“叫下一个”时从列表头部取出一个患者标记就诊中同时通过 WebSocket 推送消息到大屏幕和医生工作站。这块要注意的是不要让 Redis 里的队列变成唯一数据源数据库里的候诊状态表才是准的Redis 队列只当作加速层万一 Redis 宕机了从数据库也能重新构建队列。缴费服务幂等。支付回调是最容易出问题的地方。微信和支付宝回调可能不止一次我们的处理方法很简单每次回调拿到payment_order的order_id和transaction_id先查支付单状态如果已经支付成功直接返回成功不再处理。同时支付成功后发送事件的逻辑必须放在一个事务里避免状态更新了但消息没发出去。这些代码量都不大但都是实打实踩坑总结出来的。如果你在后面自己写的时候能记住“用数据库行锁防并发、用队列加速读、用状态机控制支付”这几点门诊上线的平稳度就有保障了。3. 前端实践Vue.js3.1 前端项目结构设计与工程化配置前端我们选了 Vue 3 Vite Element Plus这套组合对我这种主要写 Java 的人来说也很友好。Vite 的依赖预构建快到离谱和以前的 Webpack 相比开发体验提升不是一点半点。项目结构上我们按“模块 页面”的方式组织而不是单纯按页面放文件。src/ |-- api/ # 按服务拆封装的请求模块 |-- router/ # 路由配置 |-- store/ # Pinia 状态管理 |-- views/ # 页面级组件 |-- components/ # 业务公共组件 |-- utils/ # 工具函数 |-- layouts/ # 布局组件api目录是最重要的这里放着对后端 REST 接口的封装。比如api/registration.js里写了挂号和退号相关的axios请求页面里只调用函数不直接写axios。这样做的好处是后端接口一旦调整我们只需要改这一个文件不用全项目搜上下文。Vite 配置里我们做了两件重要的事设置开发代理解决前后端接口跨域问题配置别名避免丑陋的相对路径。关键配置如下// vite.config.js export default defineConfig({ plugins: [vue()], resolve: { alias: { : fileURLToPath(new URL(./src, import.meta.url)) } }, server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true, rewrite: path path.replace(/^\/api/, ) } } } })这里面有个细节为什么开发环境用代理而不是 CORSCORS 配置在后端也能做但在前端代理更省心而且开发环境和后端地址不绑定。生产环境我们直接通过 Nginx 把/api转发到网关前端浏览器永远只访问同源地址根本碰不到跨域问题。3.2 API 对接与状态管理Axios 封装和 Pinia 实战后端所有接口都挂在/api路径下由网关统一转发。前端的 Axios 实例必须做三层封装请求拦截器、响应拦截器、错误处理。请求拦截器最重要的事是往 header 里塞 Token。门诊系统用户登录后后端签发一个 JWT前端存到localStorage和 Pinia 中。每个请求发出前从 store 里取 Token拼成Authorization: Bearer token。响应拦截器里我们统一处理返回体约定后端返回的 JSON 结构是{ code: 0, message: success, data: {} }如果code不是 0直接弹出 ElMessage 提示页面不用重复处理错误。另一个关键点是 401 处理当 Token 过期或者无效时响应拦截器自动跳转登录页并清掉本地登录状态。这样用户在操作中如果会话超时不至于卡在一个半死不活的页面里。Pinia 我们只用来管理“跨页面共享的状态”主要就是用户信息、当前就诊患者、医院基础数据。医生工作站里“当前选中患者”这个状态必须放在全局 store 里因为医生在写病历、开药、查看检验报告时几个页面都要读取同一个患者 ID。如果不放 Pinia就得靠路由参数传非常容易丢。有一个我特别想提醒的点Token 不要放在 sessionStorage 里。以前我们试过 sessionStorage结果用户新开一个浏览器标签页就丢了登录状态就医场景里很多患者会自己开新窗口不出 bug 才怪。后来统一改成localStorage问题立刻消失。你如果在前端做认证务必注意这一点。3.3 门诊典型页面与组件拆解挂号页和医生工作站前端真正开发起来复杂度主要集中在几个页面里。门诊挂号页看起来就是几个筛选框加一个号源列表但内部逻辑不少。患者要先选科室再选医生然后看到剩余号数。这里有个实时刷新问题号源数据会被后台挂号操作改掉。我们做法是挂号页在展示号源列表时加了一个“5 秒自动轮询”因为医院内网环境网络稳定轮询比 WebSocket 简单可靠。同时号源不足时按钮直接置成禁用状态防止患者死等。医生工作站是门诊系统里最复杂的单页。它包含左侧候诊列表、中间病历录入区、右侧开方区三个区域之间数据联动。候诊列表显示当前科室所有排队患者点击某个人之后中间区域加载该患者的历次就诊记录和当前主诉右侧可以检索药品并添加到处方里。这里最关键的组件拆分是把“处方明细”封装成一个独立组件包含药品信息、用法用量、数量增删改都在组件内部完成由父组件维护处方数组。因为 Vue 的响应式很灵活你很容易把组件之间的状态写乱。我的建议是一个页面只允许有一个“状态源”。医生工作站里当前患者 ID 放在 Pinia处方数组放在页面级reactive药品列表从接口预加载放到页面级全局子组件只负责展示和触发事件不做深层次的数据修改。这样才能让代码在后续迭代中保持可维护性。4. 容器化部署Docker 与 Kubernetes 实践4.1 Spring Boot 和 Vue 的 Docker 镜像构建后端和前端我都用了多阶段构建目标是把最终镜像体积压到最小。后端服务因为要用 OpenJDK 环境基础镜像选eclipse-temurin:17-jre-alpine不要选 JDK因为运行只需要 JRE。一个典型的后端 Dockerfile 是这样的# 构建阶段 FROM maven:3.8.4-eclipse-temurin-17 AS builder WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn clean package -DskipTests # 运行阶段 FROM eclipse-temurin:17-jre-alpine WORKDIR /app COPY --frombuilder /app/target/registration-service.jar app.jar ENV TZAsia/Shanghai EXPOSE 8083 ENTRYPOINT [java,-jar,/app/app.jar]这里有个细节RUN mvn dependency:go-offline这一步很关键它把依赖下载单独做了一层缓存后续只改源代码重新构建时不会每次都重新下载全部依赖包。我们刚开始没写这一层每次改一行代码整个构建要跑上十分钟后来加上之后基本压缩到 1 分钟以内。前端镜像更简单但也更容易出错。因为 Vue 打包后是纯静态资源需要 Nginx 来服务。我们用两层构建第一层用 Node 镜像执行npm run build第二层把 dist 拷贝进 Nginx 镜像里。重点在于 Nginx 的配置前端是单页应用必须把所有非 API 的路径都重定向到index.html否则刷新二级页面直接 404。核心配置如下server { listen 80; server_name localhost; root /usr/share/nginx/html; index index.html; location /api/ { proxy_pass http://gateway-service:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location / { try_files $uri $uri/ /index.html; } }location /api/的反向代理是容器编排时的核心服务名gateway-service在 Docker 网络中会被解析到对应的容器 IP。如果不用 Docker这里就得写具体 IP换环境就凉了。这也是容器化带来的一个好处环境标准化配置不用到处改。4.2 容器编排与 K8s 部署的完整过程我们在测试环境先用 docker-compose 把整套系统串起来跑通再迁移到 Kubernetes。docker-compose 最大的价值是本地一键起全套所有服务定义在一个 YAML 里方便开发机调试。但是 compose 解决不了生产环境的问题比如副本自动伸缩、滚动更新、节点故障迁移。所以我们最终的生产环境部署在 Kubernetes 上。每个 Spring Boot 服务对应一组 Deployment 和 Service。以一个服务为例Deployment 关键片段如下apiVersion: apps/v1 kind: Deployment metadata: name: registration-service spec: replicas: 2 selector: matchLabels: app: registration-service template: metadata: labels: app: registration-service spec: containers: - name: registration-service image: registry.example.com/hospital/registration-service:1.0.0 imagePullPolicy: Always ports: - containerPort: 8083 env: - name: SPRING_PROFILES_ACTIVE value: prod - name: NACOS_ADDR value: nacos-headless:8848 resources: requests: cpu: 500m memory: 1Gi limits: cpu: 2 memory: 2Gi livenessProbe: httpGet: path: /actuator/health port: 8083 initialDelaySeconds: 60 periodSeconds: 10 readinessProbe: httpGet: path: /actuator/health port: 8083 initialDelaySeconds: 30 periodSeconds: 5这里有两个关键点。一是resources的 limits 和 requests 必须设置。我们最早没设置流量一高服务把节点内存吃满直接被 OOM Kill重启再被 Kill恶性循环。设置 limits 可以避免单个服务拖垮整个节点。二是一定要接 Spring Boot Actuator 的/actuator/health作为探针。K8s 通过这个判断容器是否存活、是否就绪。服务启动慢的话initialDelaySeconds要留足太短会导致前几十秒一直重启我们就踩过这个坑服务从启动到能处理请求需要 40 秒探针设 5 秒延迟结果它一直被 kill。数据库和 Redis 我们选择部署在 K8s 之外用云供应商的托管实例。原因是医疗数据需要更可靠的备份和运维能力自建数据库在 K8s 里运维成本太高。应用容器是无状态的但数据要有状态托管这是我们在生产环境的一条铁律。4.3 云原生配套组件注册中心、网关与配置管理微服务容器化之后不能忽略的配套组件是Nacos、网关、配置中心。我们在容器环境里把 Nacos 单独部署了一套但由于 Nacos 自身需要存储我们也将其作为有状态服务部署在 K8s 中使用外部 MySQL 作为后端存储。所有服务启动时通过环境变量NACOS_ADDR指向 Nacos 地址。这里有一个容易踩的坑K8s 集群内服务名是nacos-headless但是容器里 Java 应用的 DNS 解析有时会慢我们在环境变量里写的是完整访问地址避免依赖默认 DNS 搜索域。另外Nacos 本身的 nacos 命名空间和 group 要在所有项目里统一否则服务注册到不同的命名空间里网关根本发现不了。网关是整个流量的入口我们用 Spring Cloud Gateway 实现。网关容器化后需要暴露一个端口前面挂一个 Ingress。Ingress 定义外部访问域名与网关服务的映射例如apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: hospital-ingress spec: rules: - host: outpatient.hospital.example.com http: paths: - path: /api pathType: Prefix backend: service: name: gateway-service port: number: 8080配置管理这一块我们不仅仅是把配置放 Nacos还把 Spring Cloud 的bootstrap.yml改成了从 Nacos 拉取。项目里有开发、测试、生产三个环境Nacos 上用 group 区分。生产环境要求配置变更后能动态刷新我们用RefreshScope注解每次调整限流阈值或者开关直接通过 Nacos 控制台发布网关和业务服务会自动感知不需要重新发版。这个能力对门诊系统来说太实用了比如需要在高峰期临时关闭某个非关键接口直接在配置中心改一个布尔值十秒内生效。5. 常见问题与排查技巧实录5.1 服务间调用失败的定位方法微服务化之后最让人头大的就是链路变长失败以后不知道问题出在哪。我整理了一套自己的排查口诀先看注册中心再看网关日志最后看服务调用链。服务间调用失败第一步去 Nacos 控制台看服务是否在线。容器化环境中服务可能因为健康检查失败被 K8s 重启在注册中心里表现为服务列表漂移。如果注册中心里显示服务在线那基本不是注册问题就要看调用超时和日志。排第二的是网关层。Spring Cloud Gateway 的日志里能看到每一次路由转发的状态码和耗时。我们当时有一个问题挂号服务偶尔返回 500但去看挂号服务日志并没有异常。后来才发现是网关对/api/registration/**路由的 StripPrefix 配置错误路径多了一段请求打到网关后被转发到了不存在的接口返回 404被浏览器识别成 500 的网络错误。第三步是看调用链。我们早期还没上 SkyWalking排查问题只能一个服务一个服务翻日志效率极低。后来引入链路追踪组件所有服务把 traceId 打到日志里问题搜索直接按 traceId 查几秒钟就能定位到是 MySQL 慢查询还是 Redis 连接池不够。建议你在做微服务的第一天就接入链路追踪不要等到出事故再补。5.2 容器化后日志收集与排障的实战经验容器一旦跑起来日志是标准输出不能像以前一样直接 tail 某个文件。我们需要把日志收集到统一平台。最早我们用的方案是 ELK但太重后来换成轻量化的 Loki Promtail把各个 Pod 的日志集中检索。每个服务在 Nacos 配置里统一 logback 格式日志里包含 traceId、timestamp、service 名。关键信息如下pattern%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg %X{traceId} %n/pattern排障时的另一个体验K8s 里用 kubectl logs 一定要加 -f同时用 --previous 看重启前的日志。有时候调试半天发现容器已经被重启了几轮当前日志里根本找不到以前的异常堆栈必须用kubectl logs pod --previous去看上一个实例的日志。如果你不想费这个劲就一定要配置好集中日志。还有一个小坑容器里的时区默认不是中国标准时间。我们所有 Dockerfile 都加了ENV TZAsia/Shanghai否则日志时间和业务时间对不上查问题的时候误差八个小时非常痛苦。5.3 性能与资源监控让系统在高并发下稳稳运行门诊系统的高峰流量通常只有几个小时所以性能优化的核心是保证高峰期不宕机低谷期省资源。我们用的是 Kubernetes 的 HPA 自动伸缩结合压测数据来设定指标。先压测。我们用 JMeter 模拟 100 个并发用户同时挂号观察各个服务的 CPU、内存和响应时间。挂号服务因为涉及数据库行锁瓶颈一般在数据库连接池。我们调整过几个关键参数数据库连接池最大连接数maximum-pool-size50等待获取连接超时connection-timeout3000msRedis 连接池最大数200另外限流熔断也非常重要。我们使用 Sentinel 在网关层配置规则对/api/registration/**接口设置 QPS 阈值为每秒 500超出直接返回“当前人数较多请稍后重试”保护后端服务不被打崩。这是我从“挂号系统崩了”的惨痛教训中总结的门诊系统绝对不能让后端服务过载宁可挡掉一部分请求也不能让数据库被击穿。容器层面的监控我们部署了 Prometheus Grafana。采集指标包括 CPU、内存、JVM 堆、线程数。告警规则设置的是CPU 使用率超过 70% 持续两分钟内存使用率超过 85%或者服务健康检查失败。每次告警都跟真的一样提前处理了不少潜在问题。最后再分享一点个人操作心得这套门诊系统从架构设计到上线运维我最大的体会就是“拆分要克制上线要走稳”。微服务确实解决了很多单体架构的老问题但也会带来新的复杂度。如果团队没有做好容器化和链路追踪的基础设施不要为了微服务而微服务。我们在拆分时始终坚持业务驱动每个服务都有明确的业务负责人和边界不搞那种十几个服务满天飞的“表面微服务”。还有一个实际建议所有服务和前端配置都要保持“环境无关”。把数据库连接串、Redis 地址、Nacos 地址全部放到配置中心或者环境变量里代码里只写占位符。这样无论本地、测试还是生产构建出来的镜像都可以直接用不需要为不同环境打不同的镜像。这条习惯一旦养成你会发现部署新环境的成本几乎为零。如果你也开始做类似的门诊系统改造个人建议从挂号服务入手它业务边界清晰并发特征明显非常适合作为第一个拆分的实验对象。跑通之后再逐步把缴费、就诊等服务迁移进来。这套路我已经验证过确实能降低团队的学习门槛和项目风险。