广坤妹妹1. 项目背景与核心价值
这个诊疗预约平台的设计初衷源于当前基层医疗机构的实际需求。我在参与某社区卫生服务中心信息化改造时发现，传统电话预约方式存在诸多痛点：患者排队时间长、医生档期管理混乱、就诊数据难以统计。一个轻量级的预约系统能显著提升30%以上的接诊效率。
Spring Boot作为技术选型的优势在于其"约定优于配置"的理念。我们曾用传统SSM框架开发类似系统，仅环境配置就耗费2人天，而Spring Boot通过starter依赖和自动配置，让团队在半天内就搭建好了基础环境。对于资源有限的小型医疗机构而言，这种快速开发特性尤为重要。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 系统架构设计
2.1 技术栈选型
基础框架采用Spring Boot 2.7.18（避开了存在安全漏洞的3.x初期版本），配合以下核心组件：
- 持久层：MyBatis-Plus 3.5.3（简化CRUD操作）
- 数据库：MySQL 8.0（社区版，节省授权成本）
- 缓存：Redis 6.2（处理高频查询）
- 安全：Spring Security + JWT（门诊数据需加密）
特别注意：我们测试发现国产中间件宝蓝德在替代Tomcat时，需要额外配置Servlet容器适配器。对于资源受限项目，建议保持默认Tomcat以降低维护成本。
2.2 微服务划分
虽然项目规模较小，但仍采用模块化设计：
code复制clinic-booking
├── booking-core // 核心业务逻辑
├── booking-admin // 管理后台(Spring Security)
├── booking-api // 患者端REST API
└── booking-scheduler // 定时任务(Quartz)
这种结构在后期扩展互联网医院功能时，只需新增模块而无需重构。
3. 核心功能实现
3.1 预约业务流设计
采用状态机模式管理预约生命周期：
java复制public enum BookingStatus {
PENDING, // 待确认
CONFIRMED, // 已确认
CANCELLED, // 已取消
COMPLETED // 已完成
}
关键实现技巧：
- 使用Redis的ZSET实现号源排队，score值为时间戳
- 医生排班表采用位图存储（1小时为最小粒度）
- 微信支付回调与预约状态自动同步
3.2 高并发场景应对
在疫情挂号高峰期我们遇到的核心问题：
- 超卖问题：使用MySQL乐观锁+Redis原子递减
- 重复预约：患者维度24小时分布式锁
- 性能瓶颈：Nacos配置动态调整线程池参数
实测数据：单服务器（4C8G）可支撑800+ TPS，满足日均3000人次的门诊需求。
4. 安全防护方案
4.1 接口安全
针对CVE-2025-22235等漏洞的防护措施：
- 禁用不必要Actuator端点
- 自定义EndpointRequest.to()的安全校验
- 所有API增加签名验证（参考阿里云签名算法）
关键代码片段：
java复制public boolean verifySign(HttpServletRequest request) {
String clientSign = request.getHeader("X-Sign");
String serverSign = DigestUtils.md5Hex(
appKey + timestamp + nonce + secretKey);
return clientSign.equals(serverSign);
}
4.2 数据安全
医疗数据特殊保护方案：
- 字段级加密：身份证号等使用国密SM4加密
- 审计日志：记录所有敏感数据访问
- 脱敏展示：前端统一使用@JsonSerialize注解处理
5. 典型问题排查实录
5.1 Quartz任务异常
现象：定时释放过期号源任务偶发失效
排查过程：
- 检查数据库锁等待（show processlist）
- 发现任务节点时间不同步（NTP校时解决）
- 最终定位到Spring Boot自动配置冲突
解决方案：
properties复制spring.quartz.overwrite-existing-jobs=true
spring.quartz.wait-for-jobs-to-complete-on-shutdown=true
5.2 缓存一致性问题
医生临时停诊时的处理流程：
- 先更新数据库再删除缓存
- 引入本地缓存标记（Guava Cache）
- 通过消息队列通知各节点
我们采用Redisson的分布式锁确保原子性：
java复制RLock lock = redissonClient.getLock("doctor:"+doctorId);
try {
lock.lock();
// 业务处理
} finally {
lock.unlock();
}
6. 性能优化实践
6.1 数据库优化
针对预约查询的特定优化：
- 建立复合索引（科室+日期+时段）
- 使用覆盖索引避免回表
- 大文本字段（病历摘要）单独分表
执行计划分析示例：
sql复制EXPLAIN SELECT * FROM booking
WHERE dept_id=101 AND book_date='2024-03-20'
AND status='CONFIRMED';
6.2 JVM调优
根据阿里云ARMS监控进行的调整：
- 年轻代大小调整为堆的1/3
- 使用G1垃圾回收器
- 添加OOM时HeapDump参数
关键配置：
properties复制-server -Xms2g -Xmx2g
-XX:+UseG1GC
-XX:+HeapDumpOnOutOfMemoryError
7. 部署实施建议
7.1 容器化方案
使用Docker Compose的典型部署：
yaml复制version: '3'
services:
app:
image: clinic-booking:1.0
ports:
- "8080:8080"
depends_on:
- redis
- mysql
7.2 监控体系
必备的监控指标：
- 预约成功率（Prometheus）
- 接口响应时间（Grafana）
- 数据库连接池使用率（Druid内置监控）
我们在生产环境发现：当连接池使用率持续>80%时，需要调整maxActive参数。
8. 项目演进方向
当前系统已稳定运行2年，后续计划：
- 接入医保结算接口（需改造签名验证模块）
- 增加智能分诊功能（NLP算法集成）
- 开发微信小程序原生版本
特别提醒：升级Spring Boot版本时，务必检查Nacos客户端兼容性。我们曾在2.4升2.7时遇到配置读取异常，最终通过重写PropertySourceLoader解决。