简介：这是一份基于 Java 语言开发的门诊服务聚合系统设计源码，面向医疗信息化方向的后端开发者和计算机相关专业学习者，定位在门诊服务场景的聚合管理与流程优化。该系统采用 Spring Boot、Spring MVC、MyBatis 等主流技术栈，包含用户管理、预约挂号、排队叫号、医疗记录管理等模块，采用模块化、服务化设计，前后端分离，便于扩展和维护。压缩包共 51 个文件，约 220KB，其中以 34 个 Java 源文件、8 个 XML 配置文件和 1 个 YAML 配置文件为主，分别承担业务逻辑实现、Spring 框架参数配置和运行环境定义，另有 Maven 构建配置及少量文档，结构清晰。已有 246 人学习，适合需要参考完整医疗业务系统设计的开发者。通过源码可深入理解 Java 企业级应用的项目分层与依赖管理，学习 Spring Security 认证授权、MyBatis 持久化处理以及基于 Maven 的多模块构建方式，为独立开发类似信息系统提供可复用的设计思路和实现参考。
1. 门诊服务聚合系统：把挂号和缴费的分散接口收成一个Java服务
早上八点的门诊大厅，患者在一楼挂号、二楼缴费、三楼取报告，每个窗口背后都是一套独立系统：HIS管挂号、支付网关管缴费、LIS管检验报告、叫号系统管排队。患者端的App要完成一次“挂号+缴费”，后端至少要串四五个接口，任何一个超时都会导致页面转圈、用户骂街。基于Java语言的门诊服务聚合系统设计源码，解决的就是这个问题：用一层Java后端服务，把散落的门诊业务接口编排成统一入口，对外提供“一次调用、一次追踪、一次对账”的聚合API。这篇文章写给医疗信息化从业者、医院信息科工程师，以及准备拿医疗场景做Java课程设计的开发者——你能照着这里的实体模型、聚合代码和参数配置直接落地。
2. 拆开门诊聚合系统的边界：数据模型与技术选型怎么定
很多团队拿到“门诊服务聚合系统”这个需求时，第一反应是做一堆接口转发，把HIS、LIS、支付网关的接口包一层再抛给前端。这样做出来的东西只能叫网关，不叫聚合。真正的聚合系统要解决三个问题：接口收口、数据合并、流程编排。本节先把这三个问题拆清楚，再给出Java实体模型和选型理由。
2.1 门诊聚合到底“聚合”了什么：接口、数据、流程三个层面的收口
接口收口是最容易理解的一层：前端不再直接面对HIS的挂号接口、支付网关的预下单接口、短信服务商的验证码接口，而是统一请求聚合服务的/api/clinic/appointment，由聚合层按顺序调用下游。这一层的价值在于下游系统更换接口协议时，前端代码不需要改动。
数据合并是聚合服务和普通网关的分水岭。患者首页要展示“今日号源余量、最近三条就诊记录、当前排队人数”，这三个数据分别来自HIS、EMR（电子病历）、叫号系统。网关只能把三个接口的原始响应透传，聚合服务则要把它们合并成一个结构化的AggregatedPatientView返回。合并过程中还包含数据清洗——例如HIS返回的“医生职称”是编码值，聚合层要翻译成前端可读的中文。
流程编排是门诊场景最特殊的部分。一次“预约挂号+在线缴费+签到取号”操作，涉及锁号、下单、支付、确认、发码五个步骤，失败发生在哪一步，决定了订单应该回滚、重试还是转入人工。这一步必须在聚合服务里用状态机显式管理，而不是在下游接口的返回值里碰运气。
2.2 把挂号、缴费、报告串成一条线：聚合订单的数据模型
门诊聚合系统的核心表不是用户的挂号记录，而是一张聚合订单表。它把一次门诊操作涉及的所有业务项串联起来，每一条记录对应患者的一次完整操作链路。下面这个Java实体直接对应数据库表clinic_order，是整套源码最核心的部分。
@Data @TableName("clinic_order") public class ClinicOrder { @TableId(type = IdType.ASSIGN_ID) private Long id; private String orderNo; // 聚合订单号，对外暴露的业务主键，格式：CLI + yyyyMMdd + 6位序列 private String patientId; // 患者ID，来自HIS的患者主索引 private String scheduleId; // 号源排班ID，挂号时锁定的具体时段 private Integer orderStatus; // 订单状态：0=创建 1=已锁号 2=已支付 3=已完成 4=已取消 5=退费中 private String bizItems; // 业务组合项，JSON数组，如 ["REGISTER","PAYMENT","TICKET"] private Integer totalAmount; // 聚合支付金额，单位：分 private Integer refundAmount; // 累计退费金额，单位：分 private LocalDateTime createTime; private LocalDateTime payTime; private LocalDateTime finishTime; }bizItems字段是聚合系统区别于普通挂号系统的关键设计。字段里存的是本次操作的业务项组合，支付网关回调时需要逐一核对哪些业务项已扣款、哪些业务项等待确认，配合下面的明细表实现。明细表clinic_order_item记录每个业务项的状态，一个聚合订单对应多条明细，这样退挂号费时不会误退检查费。
聚合系统的订单状态机只有五个状态能落库：创建、已锁号、已支付、已完成、已取消、退费中。状态流转方向固定，不允许从“已支付”直接跳回“已锁号”，所有反向流转必须走退费流程。这个约束在代码层面通过枚举的canTransferTo方法强制校验，避免业务人员手工改库造成对账不平。
2.3 技术选型：Spring Boot + MyBatis-Plus + Redis 为什么是稳妥组合
门诊聚合系统的技术选型不需要花哨，重点是稳定和可维护。常见做法是 Spring Boot 提供接口骨架，MyBatis-Plus 操作聚合订单表，Redis 承担分布式锁和号源余量缓存。这套组合在医疗信息化项目里的优势是招人容易、踩坑资料多、出了问题能在社区快速找到答案。
| 组件 | 在聚合系统里的职责 | 选型理由 |
|---|---|---|
| Spring Boot | 提供HTTP接口、管理Bean生命周期 | 生态环境成熟，Feign、Redis、MQ都有成熟starter |
| MyBatis-Plus | 聚合订单CRUD、状态机查询 | 避免手写大量ResultMap，分页和条件构造器省时间 |
| Redis | 号源余量原子扣减、分布式锁、热点缓存 | 扣减用Lua脚本保证原子性，替代数据库行锁 |
| RabbitMQ / RocketMQ | 支付回调异步对账、退费状态通知 | 支付确认不能同步阻塞主流程，异步解耦 |
如果你是在校生，想拿这个题目做Java课程设计案例源码，这套选型还有一个好处：不需要部署微服务全家桶，一台2核4G的云服务器就能跑通。选型时唯一要注意的是，不要在这个项目里引入Seata或分布式事务中间件。门诊聚合系统的下游是医院内网的老系统，接口既不支持XA协议，也不会给你实现TCC的回滚接口，分布式事务框架在这里派不上用场，反而会让系统启动时依赖额外的协调者服务，增加部署难度。
3. 用Java把聚合服务跑起来：门面模式与接口编排的落地代码
上一章解决了“聚合什么”和“表怎么设计”，这一章直接进入源码层面。聚合服务的核心是一个门面（Facade）Controller加一个编排Service，前端只感知一个入口，后端按顺序和并发维度编排下游调用。代码会给出可运行的最小闭环，同样适用于入职后的第一个迭代版本。
3.1 聚合Controller：患者端只调一次，后端编排一串
Controller层只做参数校验和结果包装，不允许写业务逻辑。下面这段代码是聚合服务的入口，前端App调用一次即可完成挂号、缴费、取号的组合操作。
@RestController @RequestMapping("/api/clinic") @RequiredArgsConstructor public class ClinicAggregateController { private final ClinicOrderService clinicOrderService; @PostMapping("/appointment") public Result<String> createAppointment(@RequestBody AppointmentRequest request) { // 基础参数校验：必填项缺失直接返回，避免无效请求打到下游 if (StringUtils.isBlank(request.getPatientId()) || StringUtils.isBlank(request.getScheduleId())) { return Result.error("患者ID和号源排班ID不能为空"); } // 这里不catch异常，由全局异常处理器统一转换错误码 String orderNo = clinicOrderService.createAggregatedOrder(request); return Result.success(orderNo); } }Controller的返回是聚合订单号而不是挂号成功的提示，这一点对排障非常重要。前端拿到orderNo后，后续的轮询查状态、下载电子票据、打印挂号凭证全部用这个订单号关联，不再需要患者ID加上身份证号拼凑查询条件。
参数校验放在Controller而不是Service里，是为了避免无意义的分布式锁抢占。所有请求先过一遍必填项校验，再进入锁号和扣减流程，能减少约30%的无效Redis操作。对于门诊高峰期的并发场景，这直接影响锁的等待时间。
3.2 并行聚合还是串行编排：线程池参数怎么定
聚合服务中有些步骤必须串行，比如先锁号才能支付；有些步骤可以并行，比如患者首页的号源余量、排队人数、预约记录三个查询互不依赖。并行能显著降低接口总耗时，但线程池参数设置不当，反而会让系统在高峰期更快崩溃。下面是聚合查询的并行实现。
@Service @RequiredArgsConstructor public class PatientPortalAggregateService { private final HisClient hisClient; private final EmrClient emrClient; private final QueueClient queueClient; private final ThreadPoolTaskExecutor clinicAggregateExecutor; public AggregatedPatientView getPatientPortalData(String patientId) { CompletableFuture<List<ScheduleInfo>> scheduleFuture = CompletableFuture.supplyAsync(() -> hisClient.getAvailableSchedules(), clinicAggregateExecutor); CompletableFuture<List<MedicalRecord>> recordFuture = CompletableFuture.supplyAsync(() -> emrClient.getRecentRecords(patientId), clinicAggregateExecutor); CompletableFuture<Integer> queueFuture = CompletableFuture.supplyAsync(() -> queueClient.getCurrentQueueCount(patientId), clinicAggregateExecutor); try { List<ScheduleInfo> schedules = scheduleFuture.get(1500, TimeUnit.MILLISECONDS); List<MedicalRecord> records = recordFuture.get(1500, TimeUnit.MILLISECONDS); Integer queueCount = queueFuture.get(1000, TimeUnit.MILLISECONDS); return new AggregatedPatientView(schedules, records, queueCount); } catch (TimeoutException e) { // 超时的数据源不影响主流程：返回空列表或默认值，而不是让整个接口500 return new AggregatedPatientView( scheduleFuture.isDone() ? scheduleFuture.join() : List.of(), recordFuture.isDone() ? recordFuture.join() : List.of(), queueFuture.isDone() ? queueFuture.join() : 0); } catch (Exception e) { throw new AggregateException("聚合患者门户数据失败", e); } } }get方法里的超时参数是关键。给HIS的号源查询1500毫秒，给EMR的记录查询1500毫秒，给排队系统的查询1000毫秒，超时后不等结果，直接降级返回。如果不加超时，一个下游接口的故障会让整个线程池的线程全部阻塞，这些线程又持有数据库连接和HTTP连接，最终拖垮整个应用。
线程池的参数配置需要结合医院的实际并发量估算。核心线程数设为8，等于门诊高峰期挂号请求的平均并发数；最大线程数设为16，不能超过数据库连接池的上限；队列容量200，队列满后执行CallerRunsPolicy，让请求线程自己执行任务，而不是把请求直接拒绝掉。医疗场景里，慢一点比失败好，CallerRunsPolicy是比AbortPolicy更稳妥的选择。
3.3 用状态机盯住订单流转：避免“支付成功但订单在原地不动”
订单状态是所有下游接口调用结果的汇总，状态不对，对账一定不对。下面用枚举实现状态机的流转约束，防止代码里出现非法跳转。
public enum ClinicOrderStatus { CREATED(0), LOCKED(1), PAID(2), FINISHED(3), CANCELED(4), REFUNDING(5); private final int code; public boolean canTransferTo(ClinicOrderStatus target) { switch (this) { case CREATED: return target == LOCKED || target == CANCELED; case LOCKED: return target == PAID || target == CANCELED; case PAID: return target == FINISHED || target == REFUNDING; case REFUNDING: return target == CANCELED; default: return false; } } }这段状态机解决了聚合系统里最常见的“状态跳变”问题。实际项目里经常出现场景：支付网关回调显示扣款成功，但本地订单仍停留在“已锁号”，原因是确认状态的代码在异常分支里没有执行状态更新。有了canTransferTo约束，任何非法跳转会直接抛异常，开发阶段就能暴露流程漏洞，而不是上线后靠对账脚本补救。
状态更新持久化时使用乐观锁：UPDATE clinic_order SET order_status = 2 WHERE order_no = ? AND order_status = 1。这样在并发场景下，只有一条更新能成功，失败的那条会进入补偿队列，由异步任务重新拉起支付确认流程。状态机和乐观锁配合，是聚合系统在并发环境下“不掉单”的双保险。
4. 数据一致性与并发扣减：聚合系统的核心参数与设计代价
门诊聚合系统最容易被问到的技术问题就是：Java怎么保证数据一致性？在单体应用里答案是@Transactional，在聚合系统里答案要复杂得多——因为调用链路上有HTTP接口、有Redis、有支付网关，数据库事务管不到这些外部资源。这一章讨论事务边界、号源扣减和重试策略的参数取舍。
4.1 @Transactional 的边界：哪些地方能加事务，哪些地方加了反而翻车
聚合服务里最常见的错误，就是在一个编排方法上直接加@Transactional，期望所有下游调用失败时自动回滚。但这在门诊场景里行不通：HIS的锁号接口一旦锁成功，不会因为你本地事务回滚就释放号源；支付网关的扣款也不会因为你抛出异常就自动退款。事务只能管理本地数据库操作。
下面这个代码片段是正确的使用方式：事务只包裹本地订单表的插入和更新，下游调用放在事务方法外面。
public String createAggregatedOrder(AppointmentRequest request) { // 1. 先调HIS锁号，成功后才进入本地事务 boolean locked = hisClient.lockSchedule(request.getScheduleId(), request.getPatientId()); if (!locked) { throw new BusinessException("号源锁定失败，请更换时段"); } // 2. 本地事务：只处理聚合订单表的落库 String orderNo = clinicOrderMapper.insertAggregatedOrder(request, ClinicOrderStatus.LOCKED); // 3. 调支付网关下单，失败时取消HIS锁号并返回 try { String payToken = paymentClient.prePay(orderNo, request.getTotalAmount()); clinicOrderMapper.updatePayToken(orderNo, payToken); return orderNo; } catch (Exception e) { hisClient.cancelLock(request.getScheduleId()); throw new BusinessException("支付下单失败，已为您释放号源"); } }注意锁号成功之后、本地事务插入订单之前，存在一个时间窗口。在这个窗口里，患者手机关机或应用崩溃，HIS侧已经锁号，但本地没有订单记录。解决这个问题需要在锁号接口里带上聚合系统的幂等键，HIS根据幂等键保证“同一患者同一时段多次锁号只生效一次”，超时后由定时任务调HIS的查询接口回收悬挂的锁号。这是聚合系统跟单体CRUD项目最大的差异：必须假设外部系统随时可能崩溃。
4.2 防止重复挂号与号源超卖：Redis Lua脚本的原子扣减
号源余量通常放在Redis里做热点缓存，但余量的扣减必须保证原子性。用Java的get再set会超卖，用数据库行锁会把压力全部压在MySQL上。正确方案是Redis执行Lua脚本，扣减和判断在Redis内部原子完成。
// 扣减号源余量：余量不足返回-1，成功返回扣减后的余量 String luaScript = "local remain = tonumber(redis.call('GET', KEYS[1]) or '0') " + "if remain < tonumber(ARGV[1]) then " + " return -1 " + "end " + "redis.call('DECRBY', KEYS[1], ARGV[1]) " + "return remain - tonumber(ARGV[1])"; DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>(luaScript, Long.class); Long remain = redisTemplate.execute(redisScript, List.of("clinic:schedule:remain:" + request.getScheduleId()), request.getCount()); if (remain == null || remain < 0) { throw new BusinessException("号源余量不足"); }这里两个参数需要重点说明：Redis Key的过期时间设为排班结束时间之后的30分钟，避免排班结束后余量残留在内存里；每次扣减的ARGV[1]传的是挂号数量而不是固定1，支持同一个患者给家人代挂号。Lua脚本返回的remain不只是判断依据，还应该被写进审计日志，用于高峰结束后跟HIS侧的号源余量做比对，排查两条链路之间有没有出现差数。
期扣减号源余量之后，如果后续支付超时，需要把余量加回来。这里要小心一个坑：不能直接调INCR，要判断这个号源是否真的被扣减过。否则会出现“扣减失败但业务继续”或者“重复回补”的账目错误。比较稳妥的做法是回补时也走Lua脚本，先检查聚合订单表里的订单状态是否处于“已锁号未支付”，再执行回补。
4.3 超时与重试策略：哪些接口能重试，哪些重试等于重复扣费
门诊聚合系统的重试策略必须分接口制定，不能用一个全局的超时时间统一处理。下面是不同下游接口的重试参数参考表。
| 下游接口 | 超时时间 | 重试次数 | 重试间隔 | 备注 |
|---|---|---|---|---|
| HIS锁号 | 800ms | 1次 | 200ms | 锁号接口必须幂等，重试前确认锁号状态 |
| 支付网关预下单 | 1000ms | 0次 | 无 | 重试会导致重复下单，靠订单号幂等 |
| 支付网关状态查询 | 900ms | 2次 | 500ms | 查询类接口可以重试，不产生副作用 |
| 短信通知 | 600ms | 1次 | 1s | 失败不阻塞主流程，异步补偿 |
| 排队叫号查询 | 500ms | 0次 | 无 | 降级返回0，不要重试 |
支付网关预下单绝对不能重试。很多止血线下的血泪经验来自这里：第一次预下单超时，但网关侧已经生成了订单号；业务系统没收到响应就重试，网关返回“重复订单”。聚合系统的做法是本地生成聚合订单号，预下单时把订单号作为幂等键传给网关，网关侧匹配到相同订单号时直接返回原订单信息，而不是创建新订单。
重试间隔不要写成固定值。同一时刻大量请求超时，固定间隔重试会让下游接口在恢复瞬间再次被打满。常见的做法是使用指数退避：第一次失败后等待200ms、第二次等待400ms、第三次等待800ms，并带上随机抖动。缓解下游压力，也降低自己系统被拖入雪崩的概率。
5. 门诊聚合系统的高频踩坑现场：五个真实翻车记录
这一章不讲理论，全是实际项目里见过、修过、优化过的问题。面试八股文里背过的“分布式事务”“幂等设计”在门诊场景下有完全不同的表象，下面的每一条记录都按照“现象→原因→解决”展开，建议直接存成团队的排障手册。
5.1 支付成功但HIS侧查不到订单
现象：患者App端显示扣款成功，但医生工作站里找不到该患者的挂号记录。对账时发现医院财务系统里有一笔“已收患者钱、但未产生门诊记录”的差异账。
原因：聚合服务先调支付网关扣款、再调HIS确认挂号。支付网关返回成功，但HIS确认接口因网络超时抛异常，本地回滚了数据库事务，支付网关侧的扣款却没有逆向操作。
解决：把调用顺序改为“先HIS锁号→再支付网关扣款→最后HIS确认”，确认失败时订单停留在“已锁号”状态，由定时任务每30秒扫描一次状态为“已锁号”且超过2分钟的订单，调用HIS查询接口确认实际挂号情况，补偿流转到“已完成”或“退费中”。支付成功不是终点，确认成功才是。
5.2 号源库存被扣成负数
现象：早高峰挂号并发冲上来后，号源余量显示-1，但HIS侧排班记录显示实际预约人数已经超过号源总数。
原因：余量扣减用的是SELECT remain FROM schedule WHERE id = ?再在Java代码里减一，再加UPDATE，两步之间存在并发窗口。三个请求同时读到余量为0，各自判断“还有号”，同时执行扣减。
解决：余量扣减从数据库搬到了Redis，用Lua脚本一次性完成“判断余量是否充足”和“扣减余量”两个操作，原子执行。同时把数据库里的号源总数改成UPDATE schedule SET used = used + 1 WHERE used < total，作为Redis扣减成功后的二次校验，双保险防止超卖。
5.3 聚合查询超时拖崩主流程
现象：患者首页的聚合接口从平均300ms膨胀到3秒，随后挂号主流程也开始超时，整个聚合服务CPU不高但线程池队列被打满。
原因：并行聚合的线程池没有设置合理的拒绝策略和超时时间，一个下游接口故障，所有线程阻塞在get()上，后续请求全部排队。连接池和线程池同时被耗尽的系统，看起来CPU不高，但已经失去了处理能力。
解决：所有并行get调用强制带超时时间；医院内网接口和公网接口拆成两个独立线程池，避免一个慢接口拖累另一个；线程池拒绝策略改为CallerRunsPolicy，队列满时让请求线程直接执行，保证主链路不因为线程池耗尽而全部失败。
5.4 退款回调与本地订单状态对不上
现象：患者退号后，HIS侧记录已退，但支付网关的退款确认迟迟没有回调，本地订单卡在“退费中”；另一边是患者连续收到两条退款到账短信，财务侧出现重复退款。
原因：退款是异步链路，支付网关退款成功通知和HIS退号状态更新是两个独立的动作，没有统一的状态仲裁。重复退款是因为定时补偿任务没有做幂等，扫描到“退费中”的订单就再次发起退款申请。
解决：退款申请落本地clinic_refund表，每条记录有唯一的refund_no，支付网关以refund_no作为幂等键；补偿任务执行前先查退款表确认该refund_no没有成功的退款记录。网关的状态通知到达后，再依据通知里的refund_no回写状态，而不是依据金额模糊匹配。
5.5 跨科室聚合把医生排班数据串了
现象：聚合页面上某医生的简介、所属科室和号源时段跟分诊台的大屏不一致，患者按挂号时段来就诊，发现医生当天根本不在这个科室出诊。
原因：聚合服务同时接入了HIS的医生主数据、排班系统的排班信息、EMR的门诊记录，三个系统里医生ID不是同一个含义——HIS用的是工号，排班系统用的是排班医生主键，EMR用的是院内人员ID。直接用ID关联，数据就对不齐。
解决：聚合层维护一张doctor_mapping映射表，以排班系统的schedule_doctor_id为关联主键，统一转换后再合并数据。每次聚合结果返回前，额外校验“号源时段所属科室”与“医生简介所属科室”是否一致，不一致时丢弃医生简介，只返回号源时段，同时记录一条数据质量告警。
6. 从能跑到抗压：缓存降级与聚合接口的压测验证
系统上线后，面对的第一个真实压力场景是周一的早高峰。这个阶段不需要新功能，而是对现有聚合接口做三件事：缓存热点数据、建立降级开关、跑一轮面向并发的压测。这三件事做完，聚合系统才算是从“能跑”进入“敢在门诊高峰开着”的状态。
缓存的第一个对象是科室列表和医生排班简介，这类数据一天只变化几次，却每次都被患者首页的聚合查询重复拉取。用Redis的Cache Aside模式缓存，缓存过期时间设为30分钟，每天早上排班发布后主动清除一次缓存。缓存命不中时，回源HIS查询并回填缓存，回填时带一个随机过期时间（30分钟加上0-60秒的随机值），避免缓存同时失效把HIS突然打满。
降级开关配置在配置中心，不要写死在代码里。每个聚合数据源对应一个开关：schedule.enabled、record.enabled、queue.enabled。开关关闭时，聚合接口直接返回默认值而不是调用下游。例如排队人数查询关闭时返回0，同时在前端页面隐藏排队模块。这个开关的价值在于：下游系统故障时，聚合服务可以选择“带伤运行”，而不是整个接口全部失败。
压测验证建议用JMeter或wrk模拟门诊高峰请求。压测时重点看两个指标：聚合接口的TP99是否低于1.5秒，以及线程池活跃线程数是否长时间超过最大线程数的70%。第一个指标决定患者体验，第二个指标决定系统还能扛多大的突发流量。压测过程中人为停掉HIS模拟接口，观察降级开关是否在30秒内生效，这一条往往比并发数更早暴露问题。
我现在的习惯是，每一个聚合接口上线前都要回答三个问题：依赖的下游接口如果超时，返回什么给患者；同一个聚合订单被重复请求，结果是否一致；高峰期线程池满了以后，新请求是等待还是快速失败。这三个问题答不上来的代码我会直接打回重写，因为门诊场景不允许用“重启就好”来搪塞。希望这些落地的参数、代码和坑位判断能帮你在做门诊聚合系统时少走几趟弯路，也欢迎你把这篇文章分享给正在做医疗信息化的同事。
本文还有配套的精品资源，点击获取
