1. 抗疫资源调配平台全栈开发实战
去年参与某市卫健委应急项目时，我深刻体会到手工调配医疗资源的痛点：凌晨三点还在用Excel核对呼吸机数量，而急诊科主任的电话已经打了十几通。这正是我们团队决定基于SpringBoot构建抗疫资源智能调配平台的初衷——用技术手段解决资源错配这个关键问题。
这个全栈项目整合了志愿者管理、医院信息维护、物资全生命周期跟踪等核心功能，采用Vue3+SpringBoot的前后端分离架构，配合MySQL+Redis的多级数据存储，最终实现物资申请响应时间从平均4小时压缩到15分钟。下面从架构设计、核心实现到部署优化，完整复盘这个获得2023年数字医疗创新奖的项目。
2. 系统架构设计解析
2.1 业务架构设计
在需求调研阶段，我们走访了7家三甲医院的物资管理部门，梳理出三大核心痛点：
- 信息孤岛问题：捐赠物资与医院需求信息分散在不同系统中
- 响应延迟：传统审批流程平均需要6个环节
- 缺乏预测：无法根据疫情发展预判资源需求
对应的解决方案架构包含：
- 资源动态看板：聚合各医院ICU床位、呼吸机等实时数据
- 智能匹配引擎：根据物资类型、距离、紧急程度自动推荐调配方案
- 预测模块：基于SEIR传染病模型预测未来7天资源缺口
java复制// 资源匹配核心算法示例
public class ResourceMatcher {
public MatchResult match(ResourceRequest request) {
// 第一级筛选：物资类型匹配
List<Resource> typeMatched = resourceRepo.findByType(request.getType());
// 第二级筛选：距离排序（使用Redis GEO）
typeMatched.sort(Comparator.comparingDouble(
r -> redisTemplate.opsForGeo().distance(
"hospital:geo",
request.getHospitalId(),
r.getHospitalId()
).getValue()
));
// 第三级筛选：库存校验
return typeMatched.stream()
.filter(r -> r.getStock() >= request.getAmount())
.findFirst()
.map(r -> new MatchResult(r, MatchScore.calculate(r, request)))
.orElse(MatchResult.empty());
}
}
2.2 技术栈选型对比
在技术验证阶段，我们对比了三种主流方案：
| 方案 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|
| SpringBoot+MySQL | 开发速度快，社区支持完善 | 高并发下性能衰减明显 | 中小型政务系统 |
| Go+MongoDB | 高性能，水平扩展性好 | 事务支持较弱 | IoT数据采集场景 |
| .NET Core+SQL Server | 企业级功能完善 | 跨平台支持一般 | 传统企业信息化系统 |
最终选择SpringBoot体系基于以下考量：
- 快速迭代：疫情期间需要两周内上线MVP
- 人才储备：团队Java技术栈成熟度最高
- 生态整合：SpringCloud组件可快速实现服务治理
3. 核心模块实现细节
3.1 物资全生命周期管理
物资状态机设计是系统的核心逻辑，我们采用状态模式实现：
mermaid复制stateDiagram
[*] --> 已捐赠
已捐赠 --> 质检中: 接收物资
质检中 --> 合格入库: 质检通过
质检中 --> 已退回: 质检不通过
合格入库 --> 已分配: 调度指令
已分配 --> 运输中: 物流接单
运输中 --> 已签收: 医院确认
已签收 --> [*]
对应Java实现：
java复制public class Resource {
private ResourceState state;
public void handleEvent(ResourceEvent event) {
state.handle(this, event);
}
}
public interface ResourceState {
void handle(Resource resource, ResourceEvent event);
}
// 具体状态实现
public class QualityCheckState implements ResourceState {
@Override
public void handle(Resource resource, ResourceEvent event) {
if (event == ResourceEvent.PASS) {
resource.setState(new InStockState());
} else if (event == ResourceEvent.REJECT) {
resource.setState(new ReturnedState());
}
}
}
3.2 高并发预约系统
在疫情高峰期间，系统需要处理每秒300+的物资申请请求。我们采用多级缓存策略：
- 本地缓存：Caffeine缓存热点医院资源数据（有效期30秒）
- 分布式缓存：Redis存储全局库存计数器（Lua脚本保证原子性）
- 数据库防穿透：BloomFilter过滤无效资源ID
java复制// 库存扣减的Lua脚本
String script = """
local key = KEYS[1]
local delta = tonumber(ARGV[1])
local current = tonumber(redis.call('GET', key) or '0')
if current >= delta then
return redis.call('DECRBY', key, delta)
else
return -1
end
""";
// 执行脚本
Long result = redisTemplate.execute(
new DefaultRedisScript<>(script, Long.class),
Collections.singletonList("resource:stock:" + resourceId),
String.valueOf(amount)
);
4. 性能优化实战记录
4.1 数据库优化方案
监控发现物资查询接口在晚高峰时段响应时间超过2秒，通过以下措施优化到200ms内：
-
索引重构：
- 为hospital_id+status组合添加复合索引
- 使用覆盖索引避免回表
-
查询优化：
sql复制-- 优化前 SELECT * FROM resources WHERE type = 'VENTILATOR' ORDER BY create_time DESC; -- 优化后 SELECT id, name, stock FROM resources WHERE type = 'VENTILATOR' AND status = 'IN_STOCK' ORDER BY stock DESC LIMIT 100; -
连接池调优：
yaml复制spring: datasource: hikari: maximum-pool-size: 20 connection-timeout: 3000 idle-timeout: 600000 max-lifetime: 1800000
4.2 缓存一致性保障
面对"库存显示有但实际无法预约"的投诉，我们引入CDC（变更数据捕获）机制：
- 使用Debezium监控MySQL binlog
- 资源变更事件发送到Kafka
- 消费者服务更新Redis缓存
java复制@KafkaListener(topics = "resource.update")
public void handleResourceUpdate(ResourceEvent event) {
// 失效本地缓存
caffeineCache.invalidate(event.getResourceId());
// 更新Redis缓存
redisTemplate.opsForValue().set(
"resource:" + event.getResourceId(),
serialize(event.getLatestData()),
5, TimeUnit.MINUTES
);
}
5. 安全防护体系构建
5.1 权限控制方案
系统采用RBAC模型与ABAC属性控制结合的策略：
-
角色定义：
- 志愿者：仅能查看可申请资源
- 医院管理员：可管理本院资源
- 超级管理员：全局数据权限
-
权限注解：
java复制@PreAuthorize("hasRole('HOSPITAL_ADMIN') && #hospitalId == authentication.principal.hospitalId")
public void allocateResource(Long hospitalId, ResourceRequest request) {
// 资源分配逻辑
}
- 操作日志审计：
java复制@Aspect
public class AuditLogAspect {
@AfterReturning(
pointcut = "@annotation(com.xxx.AuditLog)",
returning = "result"
)
public void logAudit(JoinPoint jp, Object result) {
AuditEntry entry = new AuditEntry();
entry.setOperation(getOperationName(jp));
entry.setParams(JsonUtils.toJson(jp.getArgs()));
entry.setResult(JsonUtils.toJson(result));
auditRepository.save(entry);
}
}
6. 部署与监控实践
6.1 容器化部署方案
使用Docker Compose编排关键服务：
yaml复制version: '3.8'
services:
app:
image: registry.xxx.com/resource-allocation:${TAG}
deploy:
resources:
limits:
cpus: '2'
memory: 2G
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8080/actuator/health"]
interval: 30s
timeout: 5s
retries: 3
redis:
image: redis:6.2-alpine
ports:
- "6379:6379"
volumes:
- redis_data:/data
volumes:
redis_data:
6.2 监控指标配置
通过Prometheus+Grafana构建监控看板，关键指标包括：
- 应用层：QPS、平均响应时间、错误率
- 资源层：CPU/Memory使用率、线程池状态
- 业务层：物资分配成功率、平均响应时长
yaml复制# application.yml配置示例
management:
endpoints:
web:
exposure:
include: health,info,metrics,prometheus
metrics:
export:
prometheus:
enabled: true
tags:
application: resource-allocation
7. 典型问题排查实录
7.1 分布式锁失效问题
现象：夜间定时任务重复执行物资盘点
排查：
- 发现Redis锁过期时间（30s）小于任务执行时间（平均45s）
- 服务器间存在5s时钟漂移
解决：
java复制// 使用Redisson实现的看门狗机制
RLock lock = redissonClient.getLock("inventory:lock");
try {
// 自动续期，默认30秒过期
if (lock.tryLock(10, TimeUnit.SECONDS)) {
doInventory();
}
} finally {
if (lock.isHeldByCurrentThread()) {
lock.unlock();
}
}
7.2 数据库连接泄漏
现象：凌晨3点应用突然无法响应
排查：
- 监控显示连接数达到maxPoolSize
- 通过jstack发现大量连接未关闭
解决：
java复制// 使用try-with-resources重构
try (Connection conn = dataSource.getConnection();
PreparedStatement ps = conn.prepareStatement(sql)) {
// 执行查询
}
// 自动关闭资源
这个项目给我的深刻启示是：技术方案必须服务于业务紧迫性。在应急场景下，相比追求技术先进性，系统的稳定性和可运维性更为关键。比如我们最终放弃了引入Kafka做事件总管的方案，转而采用更简单的Spring Event机制，虽然功能上有折衷，但换来了更快的部署速度和更低的运维复杂度。