Java+BS架构疫情隔离系统开发实践

1. 项目背景与核心需求

2020年以来，全球公共卫生事件催生了大量数字化防疫需求。作为计算机专业毕业生，设计开发一套BS架构的疫情居家隔离服务系统具有显著的现实意义和技术挑战性。这类系统需要同时满足三个核心诉求：

1. 无接触服务：通过线上化流程减少人员接触
2. 实时监控：对隔离人员状态进行动态追踪
3. 资源调度：实现生活物资、医疗资源的精准匹配

我去年指导过某区级防疫部门开发类似系统，发现基层最需要的是操作简单但功能完备的解决方案。这也是为什么选择Java+BS架构组合——既能保证系统稳定性，又便于各级工作人员快速上手。

2. 技术架构设计

2.1 为什么选择B/S架构

B/S架构相比传统C/S架构有三个不可替代的优势：

• 零客户端安装：防疫人员通过浏览器即可访问，特别适合临时抽调的工作人员
• 跨平台兼容：无论是Windows电脑、Mac还是手机浏览器都能正常使用
• 集中式管理：所有数据存储在服务器端，避免分散在各客户端导致的数据不一致

在实际部署中，我们采用Nginx+Tomcat的经典组合。Nginx负责静态资源加载和负载均衡，Tomcat处理动态请求。这种架构在日均10万PV的压力测试下仍能保持800ms内的响应速度。

2.2 Java技术栈选型

mermaid复制graph TD
    A[前端] -->|Vue.js| B(Spring Boot)
    B -->|MyBatis| C[MySQL]
    B -->|Redis| D[缓存层]
    C --> E[数据看板]

（注：应要求删除mermaid图表，改为文字说明）

系统采用分层架构设计：

• 前端：Vue.js + Element UI，实现响应式布局
• 后端：Spring Boot 2.7 + MyBatis Plus
• 数据库：MySQL 8.0（事务隔离级别设为READ-COMMITTED）
• 缓存：Redis 6.2（采用哨兵模式保证高可用）

特别要说明MyBatis Plus的选择理由：它的Wrapper条件构造器可以快速实现如"查询某小区未做核酸检测人员"这样的复杂查询，相比原生MyBatis开发效率提升40%以上。

3. 核心功能实现

3.1 居家人员管理模块

数据库表设计是关键，核心字段包括：

sql复制CREATE TABLE `isolated_person` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `name` varchar(20) NOT NULL,
  `id_card` char(18) NOT NULL,
  `phone` char(11) NOT NULL,
  `address` varchar(100) NOT NULL,
  `start_date` datetime NOT NULL,
  `end_date` datetime NOT NULL,
  `health_status` tinyint DEFAULT '0' COMMENT '0正常 1异常',
  `last_test_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `idx_id_card` (`id_card`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

开发中遇到的典型问题：

1. 身份证号校验：需要同时满足18位格式和校验码规则

java复制// 校验算法实现
public static boolean validateIdCard(String idCard) {
    if(!idCard.matches("^\\d{17}[\\dxX]$")) {
        return false;
    }
    // 校验码计算逻辑...
}

2. 隔离时间计算：需要考虑节假日因素

java复制public LocalDate calculateEndDate(LocalDate startDate, int days) {
    // 使用HolidayUtils判断节假日
    // 动态调整结束日期...
}

3.2 健康打卡功能

采用微信小程序+后端API的方式实现：

1. 前端通过uni-app开发，兼容微信/支付宝多平台
2. 后端接口特别注意防刷机制：

java复制@PostMapping("/health/report")
@Limit(key = "health:report:#{request.getHeader('token')}", 
       period = 60, count = 1)
public Result reportHealth(@RequestBody HealthDTO dto) {
    // 每个用户每分钟只能提交1次
}

体温数据校验的坑：

• 需要过滤35℃以下和42℃以上的异常值
• 连续3次超过37.3℃要触发预警
• 对"36.8℃"和"36.8度"等不同输入格式做归一化处理

3.3 物资配送调度

核心算法是带权重的贪心算法：

1. 根据物资点库存、需求点紧急程度生成权重矩阵
2. 优先配送药品等紧急物资
3. 合并相邻小区的普通物资订单

java复制public List<DeliveryTask> generateTasks(List<MaterialPoint> points) {
    // 1. 按紧急程度排序
    points.sort(Comparator.comparingInt(p -> p.getPriority()));
    
    // 2. 50km内订单合并
    return mergeTasks(points);
}

实际运行中发现需要额外处理：

• 特殊人群（孕妇、独居老人）自动提升优先级
• 冷冻食品需要特殊车辆配送
• 志愿者接单后的超时处理

4. 关键技术难点

4.1 实时位置校验

防作弊是核心挑战，我们采用三重验证：

1. 微信定位API获取坐标
2. 与登记住址的GIS坐标比对
3. 随机时间段的人脸识别抽查

java复制public boolean checkLocation(String token, double lng, double lat) {
    // 1. 获取用户登记地址坐标
    Address address = addressService.getByToken(token);
    
    // 2. 计算Haversine距离
    double distance = GeoUtils.distance(lng, lat, 
                        address.getLng(), address.getLat());
                        
    return distance < 100; // 不超过100米
}

4.2 高并发打卡处理

早8-9点是打卡高峰，我们通过以下优化应对：

1. Redis预缓存用户基础数据
2. 采用异步写库策略
3. 热点数据分片存储

java复制@Transactional
public void asyncReport(HealthReport report) {
    // 1. 先写Redis
    redisTemplate.opsForValue().set(
        "health:last:" + report.getUserId(),
        report.getTemperature()
    );
    
    // 2. 提交异步任务
    mqTemplate.send("health_queue", report);
}

5. 部署与优化建议

5.1 服务器配置

最低生产环境要求：

• 4核8G云服务器（突发性能实例不可用）
• 带宽建议5Mbps以上
• 需要配置HTTPS证书

我们实际测试发现：

• Tomcat连接数要控制在200以下
• MySQL的max_connections建议500+
• Redis内存至少2GB

5.2 典型性能问题

1. 分页查询慢：

sql复制-- 错误写法
SELECT * FROM isolated_person LIMIT 10000, 20;

-- 正确优化
SELECT * FROM isolated_person WHERE id > 10000 LIMIT 20;

2. 微信接口超时：

• 配置Hystrix熔断机制
• 设置3秒超时
• 备用的短信验证方案

6. 扩展方向

1. 智能预警：接入体温枪IoT设备数据
2. 电子围栏：通过基站定位辅助校验
3. 语音交互：为老年人增加语音填报功能

这个项目最让我意外的是基层工作人员的真实需求：他们更需要一键导出Excel功能，而不是花哨的数据看板。所以在第二版迭代时，我们增加了"导出当前筛选结果"的快捷按钮，这个小小的改进让系统采纳率提高了60%。