1. 项目背景与核心需求
2020年以来的全球公共卫生事件让校园疫情防控系统成为高校信息化建设的刚需。传统的人工登记方式存在效率低下、数据孤岛、追溯困难等问题,而基于SpringBoot+Vue的全栈解决方案能够完美应对这些挑战。
这个系统需要实现的核心功能包括:
- 师生健康信息每日填报
- 校内场所出入扫码登记
- 疫情数据可视化分析
- 异常情况自动预警
- 防疫物资库存管理
关键设计考量:系统需要同时满足高并发填报(早高峰时段)和复杂数据分析需求,这决定了我们选择SpringBoot作为后端框架的技术路线。
2. 技术栈选型解析
2.1 后端技术组合
SpringBoot 2.7.x作为基础框架,主要基于以下优势:
- 内嵌Tomcat容器,部署简便
- 自动配置特性大幅减少XML配置
- 完善的健康检查机制适合防疫系统监控
- 与MyBatis的整合体验优秀
数据库选用MySQL 8.0,关键考虑:
- 校园场景下数据关系明确,适合关系型数据库
- 事务支持完善,确保打卡记录等关键操作的ACID特性
- JSON类型支持,便于存储动态防疫表单
// 典型MyBatis映射文件示例 @Mapper public interface HealthReportMapper { @Insert("INSERT INTO health_report(user_id, temperature, symptoms) " + "VALUES(#{userId}, #{temp}, #{symptoms})") @Options(useGeneratedKeys = true, keyProperty = "id") int insert(HealthReport report); }2.2 前端技术方案
Vue 3.x + Element Plus的组合提供了:
- 响应式表单构建能力(每日健康填报)
- 丰富的图表组件(ECharts集成)
- 良好的TypeScript支持
- 路由守卫实现权限控制
// 典型扫码登记组件 const scanQR = () => { QRScanner.scan() .then(data => { if (validLocations.includes(data)) { checkIn(data); } else { ElMessage.error('无效场所码'); } }) }3. 核心功能实现细节
3.1 健康打卡模块设计
采用分布式锁解决并发提交问题:
public Result submitReport(HealthReport report) { String lockKey = "lock:report:" + report.getUserId(); try { // 使用Redis分布式锁 boolean locked = redisTemplate.opsForValue() .setIfAbsent(lockKey, "1", 30, TimeUnit.SECONDS); if (!locked) { return Result.fail("操作过于频繁"); } // 业务处理... } finally { redisTemplate.delete(lockKey); } }3.2 场所码管理实现
采用GeoHash算法优化地理位置查询:
- 将校园区域划分为多个GeoHash网格
- 用户扫码时计算所在网格
- 只加载相邻网格的场所数据
-- 场所表设计 CREATE TABLE location ( id BIGINT PRIMARY KEY, name VARCHAR(100), geo_code CHAR(12), -- Geohash编码 qr_code VARCHAR(100), capacity INT );4. 系统安全与性能优化
4.1 安全防护措施
- 接口防刷:Guava RateLimiter实现API限流
- 数据加密:敏感字段使用AES加密存储
- XSS防护:前端DOMPurify过滤+后端Jackson转义
- 权限控制:基于RBAC模型的动态权限方案
4.2 性能调优实践
- 热点数据缓存:
@Cacheable(value = "userStatus", key = "#userId") public UserHealthStatus getCurrentStatus(Long userId) { // 数据库查询 }- 批量导入优化:
- 使用MyBatis的BatchExecutor
- 调整rewriteBatchedStatements=true
- 每500条提交一次事务
- 前端懒加载:
<template> <el-table :data="tableData" v-infinite-scroll="loadMore"> <!-- 表格内容 --> </el-table> </template>5. 典型问题排查实录
5.1 打卡高峰期超时问题
现象:每日8:00-9:00出现接口超时
排查过程:
- 通过Arthas监控发现MySQL连接池耗尽
- 检查连接配置:初始连接数=10,最大=50
- 分析连接泄漏:未关闭的ResultSet导致
解决方案:
# 调整Druid配置 spring: datasource: druid: initial-size: 20 max-active: 100 validation-query: SELECT 1 test-on-borrow: true5.2 扫码定位漂移问题
现象:室内场所定位偏差达500米
解决步骤:
- 改用高德地图室内定位SDK
- 增加蓝牙信标辅助定位
- 实现WIFI指纹匹配算法
关键代码:
function getIndoorPosition() { return new Promise((resolve) => { AMap.IndoorMap.getFloor((floor) => { const bleData = processBeaconSignals(); resolve(calculatePosition(floor, bleData)); }); }); }6. 部署与运维方案
6.1 持续集成流水线
Jenkins多阶段构建配置:
pipeline { agent any stages { stage('Build') { steps { sh 'mvn clean package -DskipTests' } } stage('Docker Build') { steps { script { docker.build("epidemic-system:${env.BUILD_ID}") } } } stage('Deploy') { when { branch 'master' } steps { sshPublisher( transfers: [ sshTransfer( execCommand: 'docker-compose up -d --no-deps backend' ) ] ) } } } }6.2 监控告警配置
Prometheus监控指标示例:
- 应用层:JVM内存、GC次数、接口QPS
- 数据层:MySQL连接数、慢查询数
- 业务层:每日打卡完成率、异常体温占比
Grafana看板关键图表:
- 实时在线人数趋势图
- 各场所人流热力图
- 系统响应时间百分位图
7. 项目演进方向
在实际运行三个月后,我们规划了以下优化方向:
- 智能预测功能
- 基于历史数据预测疫情风险
- 使用LSTM神经网络模型
- 集成TensorFlow Serving
- 移动端深度优化
- 开发React Native跨平台应用
- 实现离线填报功能
- 加入人脸识别核验
- 大数据分析增强
- 搭建Flink实时计算管道
- 师生行为模式分析
- 防疫措施效果评估
这个项目让我深刻体会到,一个好的校园防疫系统需要在技术严谨性和用户体验之间找到平衡点。比如在实现扫码功能时,我们最初采用的标准GPS定位在室内场景完全不可用,后来通过结合多种定位技术才解决问题。另外,在处理晨间打卡高峰时,单纯的增加服务器配置并不能根本解决问题,最终是通过引入本地缓存+异步提交的方案才稳定了系统性能。