简介本资源是一套基于Java语言开发的门诊服务聚合系统完整源码面向医疗信息化开发者、Java后端工程师及高校计算机专业学生旨在解决医疗机构门诊流程分散、服务协同效率低等实际问题。压缩包共51个文件总大小220KB包含34个Java源文件覆盖用户管理、预约挂号、排队叫号、电子病历等核心模块、8个XML配置文件用于Spring框架集成与MyBatis映射、1个YAML配置文件统一管理环境参数、2个.gitignore规范版本控制、1个pom.xmlMaven依赖与构建定义及readme.txt等辅助文档结构清晰、模块解耦便于学习Spring Boot微服务架构在医疗场景中的落地实践。已有246人学习下载读者可直接导入IDE运行调试获取完整可执行项目、标准化配置模板、前后端分离接口设计范式及医疗系统安全机制如认证授权实现参考。 大清早七点半到医院挂号窗口前已经排了二十多个人自助机旁边也有不少人在排队手机挂号小程序反而没什么人用。但越是没人用的渠道越容易出问题——有人明明在App上显示有号到窗口取号却被告知这个号源已经被自助机挂走了。这种各渠道数据不一致的混乱就是门诊信息化碎片化最典型的症状。HIS系统管挂号收费自助机厂商有自己的协议小程序又调另一个接口第三方平台再对接一套渠道一多网状连接就变成灾难。门诊服务聚合系统要解决的就是把这些服务能力收敛到一个统一的中间层让业务方对上层渠道暴露一套稳定、完整、可复用的门诊服务API。这篇文章从Java后端开发的视角拆解门诊服务聚合系统的设计思路和源码实现涵盖核心模块划分、号源并发控制、支付状态一致性、排队消息推送、工程组织方式以及部署压测中的实战踩坑。适合需要做医疗信息化平台、聚合类中间层系统或者对高并发业务设计感兴趣的Java开发者参考。1. 门诊业务线的碎片化现状聚合系统到底在聚合什么门诊业务看起来不复杂挂号、缴费、查报告、看排队进度就这几件事。但真正落地的时候每一件事背后都牵扯着不同的系统、不同的协议、不同的数据标准这才是麻烦的根源。1.1 一个挂号的完整链路要经过多少个系统拿挂一个普通内科号来说。患者在小程序上点了挂号前端调用小程序后端小程序后端要调医院的号源接口号源接口从HIS系统查医生排班排班数据可能来自医院的排班管理系统然后要锁号、扣费费用要经过支付渠道支付成功要同步到财务管理挂号结果要通知到排队叫号系统。这还只是最顺利的情况。如果患者用的是第三方平台比如某度健康、某信城市服务那就还要经过第三方平台的转接层第三方平台对接医院的方式五花八门有的用HL7标准报文有的用WebService有的干脆就是HTTP接口加自定义JSON格式。医院HIS的供应商不同接口风格也完全不同。我之前接手过一个项目医院原来有四个挂号渠道每个渠道单独对接HIS的号源接口。四个渠道各自的字段映射、异常处理、重试机制都是各写各的。后来新加一个支付宝渠道开发排期两周实际上大部分时间都花在折腾各种接口差异上。这就是典型的没有聚合层的苦果——渠道越多对接成本越高出问题的概率也越大。1.2 聚合层引发的架构变化引入门诊服务聚合系统之后架构从网状变成星型。改造之前渠道A直接对接HIS接口渠道B直接对接HIS接口渠道C直接对接HIS接口渠道D直接对接HIS接口新增一个渠道就要重新写一遍和HIS的对接逻辑医院所有渠道的服务质量完全取决于每个渠道各自的实现质量。改造之后渠道A、B、C、D统一对接聚合层聚合层统一对接HIS接口新增渠道只需要对接聚合层不用再碰HIS这是架构层面的核心变化。聚合层成为一个独立的服务向上屏蔽HIS的复杂性向下屏蔽渠道的多样性。但聚合层不是简单加一层代理它要做的事情比转发要多得多统一所有渠道的API规范定义一套标准的门诊服务接口管理号源的本地缓存和实时同步处理支付回调的幂等和对账维护排队叫号的长连接通道记录全链路的调用日志和监控数据聚合层成了门诊业务的中枢神经系统这也就意味着它的可用性要求非常高——它挂了所有渠道的门诊服务都挂了。所以在设计阶段就要想清楚哪些东西放聚合层哪些东西不要放。1.3 聚合的边界什么该聚合什么不该聚合这是我做了几年聚合系统之后体会最深的一点。聚合层最怕什么都往里面塞最后变成一个无数业务逻辑纠缠的巨型单体。门诊服务聚合系统的边界原则是聚合流程不聚合业务。什么意思挂号流程是跨系统的编排这个流程的调度放在聚合层但号源的锁定规则、退费的业务判定、医保的分担计算这些都是领域业务逻辑应该留在HIS侧或者由专门的业务服务处理聚合层只负责调用。举例来说聚合层收到挂号的请求之后要做的事情是校验参数、检查本地号源缓存、调用HIS锁号、创建订单、发起支付、处理支付结果、通知排队系统。这些都是流程编排的事。至于这个号该不该放出来、医生的号源配额怎么分配、什么情况下能退费这些规则聚合层不碰。2. 系统模块划分与技术选型先定边界再写代码架构设计阶段最重要的事情就是划清楚模块边界。边界划得清楚后面写代码就是填充细节边界划不清楚越写越乱最后只能推倒重来。2.1 三个核心层级的职责分配门诊服务聚合系统分成三层适配层、聚合层、基础服务层。适配层负责接收各种渠道的请求把不同渠道的协议转成统一标准。小程序渠道传的JSON字段是patientName自助机厂商传的是name适配层要把它们统一成一样的。这个层不处理业务只做协议转换和数据清洗。聚合层是核心负责业务流程的编排。挂号、缴费、退号、查询这些业务动作的完整流程都由聚合层来调度。这一层也是源码实现最复杂的地方后面第3章会详细拆解。基础服务层包含和外部系统的集成客户端。HIS客户端、支付网关客户端、短信服务客户端、医保接口客户端都封装在这一层。聚合层不直接拼接HTTP请求调HIS而是调基础服务层提供的客户端方法客户端内部处理连接、超时、重试、签名这些技术细节。这个分层的逻辑类比一下就是餐厅——适配层是门口迎宾不同国家的人来了先转换语言换成餐厅内部统一沟通方式聚合层是后厨和传菜之间的调度台一个订单该先做什么菜、哪个桌子先上都由调度台安排基础服务层就是后厨的几个灶台各有各的擅长菜系调度台只管下单不关心灶台怎么做。2.2 选型清单和取舍理由基于门诊业务的并发量级——一般三甲医院高峰期的门诊TPS在几百到一两千我选择了成熟稳定的单体分层架构而不是一上来就搞微服务。核心选型清单组件选型选型理由JDK17长期支持版本虚拟线程在后续项目里可以考虑框架Spring Boot 3.x生态成熟社区活跃度高ORMMyBatis-Plus单表操作效率高复杂SQL手写可控缓存Redis 7.x号源缓存、分布式锁、排队状态都依赖它数据库MySQL 8.x业务数据存储性价比高消息队列RocketMQ事务消息方案能处理支付对账这种场景长连接WebSocket Netty排队叫号和报告通知的实时推送接口文档SpringDoc OpenAPI 3让渠道方对接联调省力为什么不用微服务门诊聚合系统的核心诉求是稳定和可维护单体分层在几百TPS的性能区间内完全没压力。微服务带来的注册发现、链路追踪、分布式事务这些问题在这个场景下全是负担。如果未来业务量增长到几千TPS单体可以通过堆机器加负载均衡来解决再不行就按模块拆分成几个有限的微服务从单体分拆比一上来就分布式要容易得多。2.3 源码工程的模块划分我把工程分成了几个Maven模块不是单模块一把梭clinic-aggregation ├── clinic-aggregation-adapter // 渠道适配层接口定义、参数转换 ├── clinic-aggregation-core // 聚合核心层业务流程编排 ├── clinic-aggregation-client // 基础服务层外部系统客户端 ├── clinic-aggregation-common // 公共组件工具类、常量、异常定义 └── clinic-aggregation-start // 启动模块配置、入口这样拆的好处是依赖关系清晰。adapter依赖corecore依赖clientcommon被所有人依赖start把一切组合起来。任何一层都不会反向依赖代码就不会乱。3. 核心模块源码设计与实现不只是接口加实现这一章挑四个最能体现聚合系统设计思路的模块来拆解每个模块都有实际的源码设计考量。3.1 号源缓存与多渠道同步聚合层不能每次挂号都穿透到HIS查号源。HIS系统的数据库承载能力有限高频次查询会拖垮HIS而HIS是医院的核心系统绝对不能崩。所以号源信息必须先同步到聚合层的本地缓存。号源同步的思路是时间片快照加增量更新。每天凌晨聚合层从HIS拉取未来七天的排班计划和号源总数存到Redis里。白天运行期间每一次挂号成功本地扣减Redis中的剩余号数每过一段时间聚合层用增量接口向HIS核对消耗的号量修正两边的偏差。Redis的key设计成这样clinic:schedule:{doctorId}:{date}:{period}value是一个Hash包含totalCount、usedCount、remainCount、status这些字段。这样设计的好处是可以很方便地支持按照医生、日期、时段这三个维度去查询号源。核心的号源扣减逻辑用Redis的Lua脚本来保证原子性。这里放一个简化的版本-- KEYS[1]: 号源Redis key -- ARGV[1]: 本次要扣减的数量 local remain tonumber(redis.call(HGET, KEYS[1], remainCount)) local total tonumber(redis.call(HGET, KEYS[1], totalCount)) if remain nil or remain tonumber(ARGV[1]) then return -1 end redis.call(HINCRBY, KEYS[1], usedCount, ARGV[1]) redis.call(HINCRBY, KEYS[1], remainCount, -ARGV[1]) return remain - ARGV[1]Redis单线程执行Lua脚本是原子操作不用加分布式锁也能避免超卖。这是整个挂号链路里最关键的并发控制点。但Redis缓存和HIS真实数据之间存在一个时间窗口的偏差为了解决这个问题还需要一个定时对账任务每隔一段时间把Redis的号源消耗情况同步给HIS并且以HIS的返回结果为准修正缓存。这样一来Redis层抗住了高并发查询HIS的压力控制在安全的范围。3.2 统一支付模块状态机与幂等设计支付是聚合系统里最容易出问题的模块因为支付流程涉及外部渠道的回调回调的时序不可控还可能重复。我的设计思路是引入订单状态机。一条挂号订单的状态流转如下待支付 - 支付中 - 已支付 - 已退费 - 已取消状态机用枚举加接口的方式实现避免散落一地的if-else判断。核心代码如下public enum OrderStatus { WAITING_PAYMENT(0, 待支付) { Override public boolean canTransferTo(OrderStatus target) { return target PAYING || target CANCELLED; } }, PAYING(1, 支付中) { Override public boolean canTransferTo(OrderStatus target) { return target PAID || target CANCELLED; } }, PAID(2, 已支付) { Override public boolean canTransferTo(OrderStatus target) { return target REFUNDED; } }, REFUNDED(3, 已退费) { ... }, CANCELLED(4, 已取消) { ... }; public abstract boolean canTransferTo(OrderStatus target); }状态迁移统一走一个OrderStateMachine非法迁移直接抛出异常从代码层面就杜绝了状态乱跳的问题。另一个关键点是支付回调的幂等。支付渠道的回调接口可能因为网络原因重复调用多次聚合层必须保证处理一次和处理十次的结果一致。实现方式是在回调处理入口做唯一键校验用支付渠道的流水号作为唯一约束查到了就不重复处理。同时用数据库的唯一索引做兜底的约束双保险。3.3 排队叫号推送WebSocket会话管理门诊的排队叫号是实时性要求最高的场景患者在小程序上就能看到当前排队到多少号了。这个模块的实现核心是WebSocket长连接和消息推送管理。聚合层维护一个会话管理器用Netty的ChannelGroup来管理连接。每个连接建立的时候绑定患者的就诊卡号和门诊号。当医生的出诊进度变化时聚合层从HIS同步叫号状态然后向对应的患者连接推送排队进度。public class QueueSessionManager { private final ConcurrentHashMapString, Channel patientChannels new ConcurrentHashMap(); public void bindPatient(String patientCardNo, Channel channel) { Channel oldChannel patientChannels.put(patientCardNo, channel); if (oldChannel ! null oldChannel.isActive()) { oldChannel.close(); } } public void pushQueueMessage(String patientCardNo, QueueMessage message) { Channel channel patientChannels.get(patientCardNo); if (channel ! null channel.isActive()) { channel.writeAndFlush(new TextWebSocketFrame(JSON.toJSONString(message))); } } }这里有个容易踩坑的点患者可能在多个设备上同时登录小程序、App都连着。处理方式是每个患者CardNo只保留一个有效连接新的连接建立后自动踢掉旧的连接。这样消息只会推送到最近活跃的终端不会出现消息重复推送的问题。3.4 报告结果通知异步事件模型检验检查报告出来的时候患者往往已经离开医院了这时候需要有消息推送服务主动通知。这个场景的特点是报告出来的时间不确定对实时性要求不如排队叫号那么极端但一定要可靠送达。实现上用了事件驱动的方式。聚合层监听HIS发出的报告结果事件把事件转成内部领域事件然后交给事件处理器。事件处理器负责以下动作给患者推送App/小程序通知给患者发送短信提醒更新报告查询接口的缓存数据这里选择RocketMQ做事件的异步解耦而不是直接同步调用是因为HIS推送报告的峰值可能很集中比如上午十一点集中出报告这时候如果聚合层同步处理所有推送响应就会堆积。放到消息队列之后消费者按照自己的节奏消费削峰填谷系统就稳定了。4. 高并发与一致性聚合层最考验功力的两个难点聚合层一天要处理几万笔挂号、缴费、查询请求高并发下的一致性问题是设计之初就要想清楚的。这一章拆解两个我在实际开发中花了最多精力的问题。4.1 号源扣减的并发控制方案号源扣减是整个系统里并发冲突最激烈的操作。同一个医生的号源同一时间可能有几百个人在抢必须保证不超卖也尽量不能让用户体验到锁等待太久。很多团队的第一反应是用分布式锁Redis的SETNX加锁锁住了再查库存、扣库存、释放锁。这个方案的问题有两个一是拿到锁之后要查询数据库加锁时间太长吞吐量上不去二是分布式锁本身的可靠性就有讲究锁超时时间设置不好就可能导致锁提前释放造成并发问题。我最终采用的是Redis预扣加Lua脚本原子操作加异步对账的方案。用户请求进来先用Redis的Lua脚本在缓存层面完成号源扣减这一步是原子的速度快扛住了绝大多数流量。扣减成功后把一条异步消息发到消息队列后端服务消费消息真正去HIS核销号源。如果HIS核销失败再走补偿流程回滚Redis中的号源。这个方案的本质是把热点的并发控制从数据库前移到缓存数据库操作全部异步化。实测下来相同配置下用纯数据库乐观锁方案大概能扛到300TPS换成Redis预扣之后同样的机器配置能到2000TPS以上而且对HIS的冲击小得多。4.2 分布式事务的现实选择门诊场景里有一个绕不开的分布式事务问题挂号要在聚合层创建订单要在HIS系统锁号要在支付渠道扣款这三个操作分布在三个系统里任何一步失败了整体的数据怎么保持一致教科书上会给很多方案两阶段提交、TCC、Saga、本地消息表。但在真实医疗项目里强一致性的成本很高——HIS系统是第三方厂商的你不可能要求HIS去实现两阶段提交的prepare和commit接口。TCC也需要业务流程里每个参与者都实现try、confirm、cancel三个方法让第三方系统做这种改造基本不现实。现实的做法是最终一致性加对账补偿。挂号锁定号的流程设计成这样的状态记录聚合层创建挂号单初始状态是待确认调用HIS锁号成功状态变为号源已锁发起支付成功状态变为已支付。每一步操作都记录操作流水流水表里包含当前状态、关联单号、操作类型。当发生异常或者超时的时候有独立的定时任务扫描这些超时未完成的挂号单根据当前所处的状态做补偿。比如支付超时但号源已经锁了就自动解锁号源并通知HIS释放号源同时把挂号单标记为失败。补偿任务和实时流程配合保证整个挂号链路的最终一致性。踩坑提示千万不要在聚合层尝试做同步的分布式事务那会让你的挂号接口响应时间从200毫秒变成3秒。用户体验差不说大量的同步等待还会把线程池拖死一个医院的渠道稍微波动一下整个聚合层就雪崩了。异步化加补偿是医疗系统里更稳妥的选择。5. 源码工程组织核心类设计与渠道扩展机制很多聚合系统写着写着就变成一个巨大的util类集合所有逻辑都堆在Service里后面加一个渠道要改十几个文件。这一章说说怎么从源码层面把扩展点设计好。5.1 分层后的核心类职责按前面说的三层模块划分每一层的核心类职责要清晰。我在实际项目里的核心类列表大致如下// adapter层 RegisterController // 挂号相关API入口 PaymentController // 支付相关API入口 QueryController // 查询类API入口 ChannelRequestConverter // 渠道请求统一转换器 // core层 RegisterOrchestrator // 挂号流程编排 PaymentOrchestrator // 支付流程编排 OrderStateMachine // 订单状态机 TicketPoolManager // 号源池管理器 // client层 HisServiceClient // HIS系统集成客户端 PaymentGatewayClient // 支付网关客户端 SmsServiceClient // 短信服务客户端看到没core层的几个类都是Orchestrator和Manager结尾它们的职责是编排和调度不是具体干活的。具体干活的是client层的各种ServiceClient。所以核心业务流程的代码会非常清晰一个RegisterOrchestrator把这个流程该调什么按顺序写好只是每一步都不落地实现细节而是调对应的客户端。5.2 策略模式封装渠道差异不同支付渠道的适配差异很大。微信支付用统一下单接口支付宝用支付宝预下单接口聚合支付的流程又完全不同。如果用if-else写每加一个渠道都要改动现有代码极易引发回归。我把支付渠道差异封装成策略接口public interface PaymentChannelStrategy { PayChannelEnum getChannel(); PayResult createPayment(PaymentRequest request); PayResult handleCallback(CallbackRequest request); RefundResult refund(RefundRequest request); }每个渠道一个实现类比如WechatPayStrategy、AlipayStrategy、UnionPayStrategy。策略的注册用一个Map来完成Spring启动的时候自动收集所有的策略实现放进Map里key对应渠道编码Component public class PaymentChannelRegistry { private final MapString, PaymentChannelStrategy channelStrategyMap new HashMap(); public PaymentChannelRegistry(ListPaymentChannelStrategy strategies) { for (PaymentChannelStrategy strategy : strategies) { channelStrategyMap.put(strategy.getChannel().getCode(), strategy); } } public PaymentChannelStrategy getStrategy(String channelCode) { return channelStrategyMap.get(channelCode); } }以后新增一个支付渠道只要新增一个实现类实现接口里的方法注册Map会自动包含它主流程一行代码都不用改。这就是开闭原则在实战中的体现。5.3 扩展点与SPI机制的配套使用除了Spring的注入方式我还预留了SPI扩展机制。这个设计对应的是那些不适合写死在应用里的场景——比如不同医院HIS厂商的接口协议差异太大代码里不需要直接依赖这些实现。在META-INF/services目录下放扩展点配置运行时使用ServiceLoader动态加载。这样聚合系统可以作为一个分发出去的框架不同的医院部署在本地各自提供自己的HIS适配器实现核心代码不用动。6. 部署落地与压测中的经验教训源码写完不算完部署上去能稳定跑才是真的完成。最后分享一些我在门诊聚合系统落地过程中踩过的坑这部分经验比代码本身更值钱。6.1 关键配置的参数选择几个重中之重的配置参数每一项背后都有真实的教训。JVM参数方面我的建议是-Xms和-Xmx设为相同值避免运行中动态扩容导致停顿。具体的大小根据机器内存来定一般是机器内存的一半到三分之二。重点是GC选择对于响应时间敏感的聚合层来说ZGC在这个场景下表现不错能显著减少单次GC停顿。数据库连接池方面连接数不是越大越好。MySQL默认连接数有限HikariCP最大连接数设置20到50之间表现最好。连接数设太多反而会导致数据库线程切换开销增大系统吞吐量下降。Redis连接池参数容易被忽视。lettuce在高并发下如果超时时间设置不合理会频繁抛出连接异常。我给的是3000毫秒的连接超时5000毫秒的命令执行超时这个配置在压测里表现稳定。6.2 压测发现的三个真实问题第一次做全链路压测的时候系统只扛到了预期的三分之一就出问题了排查过程记忆深刻。第一个问题是Redis连接耗尽。当初缓存配置用的是默认的lettuce配置没有设置合理的池大小。压测一上来连接创建速度跟不上请求速度大量请求在获取Redis连接时超时。排查的方式是压测时同时看Redis的服务端连接数发现连接数冲到了好几千立即调整了lettuce池参数同时加了Redis连接数的监控告警。第二个问题是MySQL的慢查询。挂号流水表的操作频繁但索引设计没有跟上导致一个按订单号查询的SQL在数据量涨上去之后变成了全表扫描。压测期间这个SQL耗时一度超过2秒把数据库连接池拖满了。定位之后在订单号列上加了一个唯一索引慢查询从2秒降到几毫秒。经验是上线之前一定要用真实数据量跑一遍压测索引设计好不好压测才能暴露出来。第三个问题是锁的粒度太粗导致的性能瓶颈。最开始写号源扣减的时候用了synchronized锁整个方法压测10个并发就出现大量等待。后来先用Redis Lua脚本替代了进程内锁又细化了锁的粒度从锁医生改成锁医生加时段并发度提升非常明显。如果代码中存在锁或者事务压测场景一定要设计好并发比例先用小并发试逐步往上加观察系统拐点在哪里。6.3 监控报警体系的三板斧门诊聚合系统上线后我配了三层监控每一层干不同的事。第一层是基础资源监控包括CPU、内存、磁盘IO、网络带宽。这一层解决的问题是服务器本身有没有异常资源满了系统性能必然下降。第二层是应用性能监控包括接口响应时间、TPS、错误率、JVM GC耗时。每一个API接口都要有独立的监控曲线这样渠道反馈慢的时候能快速定位是哪个接口叫慢。第三层是业务监控包括挂号成功率、支付回调延迟、号源同步延迟、消息队列积压量。这是最贴近业务的一层也是运维最容易忽略的一层。比如号源同步延迟超过5分钟那就说明和HIS的同步链路出问题了可能引起患者看到有号但挂不了的情况这个告警必须在问题影响到患者之前就响起来。监控告警不能光有指标还要有明确的分级和响应动作。我的做法是P0级别的告警比如挂号接口错误率超过5%直接电话报警P1级别的告警比如消息队列积压量超阈值推送到工作群P2级别的告警比如某个渠道回调延迟升高只需要看板展示。告警级别定合理了运维才不会天天被无效警报骚扰。根据个人经验聚合系统的稳定性不是写出来的是压出来和盯出来的。上线后的第一个月监控告警群里每天都会响几次每一次告警背后都是代码或者配置上的一个盲点。把这些盲点一个个补上系统才能逐渐稳定下来。本文还有配套的精品资源点击获取