Eleny君君1. 项目背景与核心价值
校园订餐系统是当前高校信息化建设中的重要一环。我去年参与某高校后勤数字化改造时，发现传统电话订餐和窗口排队模式存在诸多痛点：高峰期订单处理效率低、人工记录易出错、学生无法实时掌握菜品信息。这正是我们开发这套系统的初衷。
SSM（Spring+SpringMVC+MyBatis）框架组合在JavaWeb开发领域占据主流地位已有多年。根据2023年Java开发者调查报告显示，超过62%的企业级应用采用SSM作为基础架构。这套技术栈的优势在于：
- Spring的IoC容器实现松耦合
- SpringMVC的请求驱动模式简化Web层开发
- MyBatis的SQL映射让数据库操作更直观
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 系统架构设计
2.1 技术选型决策
在框架版本选择上，我们经过多次测试对比后确定：
- Spring 5.3.18：平衡了稳定性和新特性
- MyBatis 3.5.9：完美支持动态SQL和二级缓存
- MySQL 8.0.28：事务性能和JSON数据类型表现优异
提示：MySQL 8.x默认使用caching_sha2_password认证插件，需在连接字符串中明确指定useSSL=false
2.2 分层架构实现
系统采用经典三层架构，但针对订餐业务做了特殊优化：
code复制表示层(JSP+AJAX)
↓
业务逻辑层(Spring)
↓
数据访问层(MyBatis)
↓
MySQL数据库
特别在业务层设计了订单状态机：
java复制public enum OrderStatus {
UNPAID(1), PAID(2),
PREPARING(3), DELIVERING(4),
COMPLETED(5), CANCELLED(6);
// 状态转换校验逻辑
public boolean canTransferTo(OrderStatus target) {
// 具体实现...
}
}
3. 数据库关键设计
3.1 表结构优化
经过三个版本的迭代，最终确定的ER图核心表包括：
| 表名 | 关键字段 | 索引策略 |
|---|---|---|
| t_user | user_id, student_id(唯一), balance | 复合索引(student_id,status) |
| t_food | food_id, category_id, current_stock | 分类ID+销量联合索引 |
| t_order | order_no(雪花算法), total_amount | 订单号哈希分区 |
| t_order_item | order_id, food_id, quantity | 订单ID外键索引 |
3.2 事务处理方案
针对并发订餐场景，我们采用多级锁策略：
- 商品库存使用乐观锁：
sql复制UPDATE t_food SET stock = stock - 1
WHERE food_id = ? AND stock >= 1
- 余额支付采用悲观锁：
java复制@Transactional
public boolean deductBalance(Long userId, BigDecimal amount) {
User user = userMapper.selectForUpdate(userId);
// 校验并扣减...
}
4. 核心功能实现细节
4.1 高并发下单处理
通过压力测试发现，原始方案在100并发时失败率达23%。优化后的流程：
- 前端采用令牌桶算法限流
- 服务端引入Redis缓存商品库存
- 订单服务独立部署，使用RocketMQ削峰
关键代码片段：
java复制// 分布式锁实现
public boolean tryLock(String key) {
return redisTemplate.opsForValue()
.setIfAbsent(key, "1", 30, TimeUnit.SECONDS);
}
4.2 实时推送方案对比
我们测试了三种方案后选择SSE(Server-Sent Events)：
| 方案 | 延迟 | 兼容性 | 开发成本 |
|---|---|---|---|
| WebSocket | <100ms | IE10+ | 高 |
| Polling | 1-3s | 全兼容 | 中 |
| SSE | 300ms | IE除外 | 低 |
实现示例：
javascript复制const eventSource = new EventSource('/order/status');
eventSource.onmessage = e => {
updateOrderUI(JSON.parse(e.data));
};
5. 部署与性能调优
5.1 生产环境配置
经过JMeter压测确定的服务器配置：
- Tomcat 9.0.65 关键参数：
xml复制<Connector
maxThreads="200"
acceptCount="100"
maxConnections="500"
connectionTimeout="20000"/>
- MySQL my.cnf优化项：
ini复制innodb_buffer_pool_size = 2G
innodb_log_file_size = 256M
table_open_cache = 2000
5.2 缓存策略
采用多级缓存架构：
- 热点数据使用Redis Cluster
- 静态菜单数据用Guava Cache
- 前端添加ETag缓存控制
缓存更新策略对比：
| 策略 | 一致性 | 复杂度 | 适用场景 |
|---|---|---|---|
| 定时过期 | 弱 | 低 | 非关键数据 |
| 写时删除 | 强 | 中 | 订单状态 |
| 消息队列同步 | 最终 | 高 | 分布式系统 |
6. 安全防护措施
6.1 常见攻击防护
在安全测试阶段发现并修复的漏洞：
- SQL注入：全部使用MyBatis参数绑定
- XSS攻击：集成Spring Security的Content-Type检查
- CSRF：添加Token验证过滤器
安全过滤器配置示例：
java复制http.addFilterBefore(new XssFilter(), UsernamePasswordAuthenticationFilter.class);
6.2 支付安全方案
与校园一卡通对接时的加密流程：
- 使用SM4加密请求数据
- 每个请求附带时间戳和签名
- 敏感字段额外RSA加密
签名生成逻辑：
java复制String sign = DigestUtils.md5Hex(
appId + timestamp +
nonce + body + secretKey);
7. 项目交付与扩展
7.1 文档规范
LW（毕业论文）结构建议：
- 系统分析：包含UML用例图和活动图
- 设计部分：类图+时序图要完整
- 测试章节：需包含覆盖率报告
注意：数据库文档应包含PDM文件和变更记录
7.2 二次开发建议
根据实际运营数据，建议后续扩展：
- 智能推荐算法（协同过滤）
- 骑手路径规划（GIS集成）
- 语音订餐接口（ASR技术）
扩展架构示意图：
code复制[微信小程序] → [API Gateway] → [Recommendation Service]
↓
[Core System]
在项目部署到某高校的实际运行中，系统日均处理订单量达到3200+，高峰期QPS稳定在85左右。最大的收获是认识到：校园系统的特殊之处在于要同时考虑性能需求和教务管理规则，比如需要处理学期切换时的班级数据迁移，这是商业系统很少遇到的场景。