Java Web 技术架构升级路径总结
一、技术架构演进全景图
第一阶段 (老牌经典) 第二阶段 (过渡主流) 第三阶段 (现代标准)
─────────────────────────────────────────────────────────────────────────────────
SSH SSM Spring Boot
(Struts + Spring + Hibernate) → (Spring MVC + Spring + MyBatis) → (Spring Boot 生态)
└─ 特点: XML驱动, 全自动ORM └─ 特点: 注解兴起, 半自动SQL └─ 特点: 约定优于配置, 微服务基石
└─ 现状: 遗留系统, 维护为主 └─ 现状: 仍在使用, 但已非首选 └─ 现状: 业界标准, 新项目首选
二、各阶段升级复杂度对比
核心结论： SSH → SSM 复杂度最高，SSM → Spring Boot 相对平滑。
| 升级路径 |
核心动作 |
业务代码改动量 |
配置改动量 |
风险等级 |
预估工作量(中型项目) |
| SSH → SSM |
Web层+持久层同时更换框架 |
极大 (Action重写, HQL转SQL) |
极大 (XML全量翻译) |
极高 |
3 - 6 个月 |
| SSM → Spring Boot |
更换启动和配置方式 |
极小 (业务注解几乎不动) |
中等 (XML转YAML/注解) |
中等 |
2 - 4 周 |
| SSH → Spring Boot (直接) |
Web层+持久层+配置全面替换 |
极大 |
极大 |
极高 |
4 - 8 个月 |
三、为什么 SSH → SSM 是最复杂的？
1. Web层：Struts → Spring MVC（"推倒重来"级）
| 对比项 |
Struts 2 |
Spring MVC |
迁移工作 |
| 请求映射粒度 |
类级别 (一个请求→一个Action类) |
方法级别 (一个Controller可处理N个请求) |
需将N个Action打散重组成M个Controller |
| 配置方式 |
struts.xml (XML配置路由) |
@RequestMapping 注解 |
XML→注解，逐条翻译 |
| 数据模型 |
ValueStack + OGNL |
Model / ModelAndView / @ResponseBody |
数据绑定逻辑全部重写 |
2. 持久层：Hibernate → MyBatis（"语法反转"级）
| 对比项 |
Hibernate |
MyBatis |
迁移工作 |
| ORM模式 |
全自动 (自动生成SQL) |
半自动 (手写SQL) |
所有CRUD操作需重写为SQL + ResultMap |
| 查询语言 |
HQL (面向对象) |
SQL (面向数据库) |
复杂查询需重新优化 |
| 缓存机制 |
一级/二级缓存自动管理 |
需手动配置 |
缓存策略需重新设计 |
四、为什么 SSM → Spring Boot 相对平滑？
核心框架没变，只是配置方式的进化
| 对比项 |
SSM |
Spring Boot |
迁移工作 |
| Web框架 |
Spring MVC |
Spring MVC |
不变 ，业务Controller基本原样复用 |
| 持久层 |
MyBatis |
MyBatis |
不变 ，Mapper接口和SQL基本不动 |
| 配置方式 |
XML为主 (web.xml, spring-*.xml) |
注解 + application.yml |
去XML化，翻译工作量可控 |
| 运行方式 |
WAR包 → 外部Tomcat |
JAR包 → 内嵌Tomcat |
新增@SpringBootApplication启动类 |
| 依赖管理 |
手动管理版本，易冲突 |
spring-boot-starter 统一管理 |
依赖大幅精简 |
⚠️ 唯一需要注意的"坑"
- JDK 8 → JDK 17 ：如果直接升级到Spring Boot 3.x，需处理
javax → jakarta包名变更。
- 稳妥建议 ：先选 Spring Boot 2.7.x (兼容JDK 8)，稳定后再升3.x。
五、推荐升级策略对比
| 策略 |
路径 |
优点 |
缺点 |
适用场景 |
| 分步走 |
SSH → SSM → Spring Boot |
每步目标清晰，风险可控 |
总周期长，两次迁移重复劳动 |
团队对新技术不熟，需逐步过渡 |
| 一步到位 |
SSH → 直接到 Spring Boot |
总工期最短，避免重复劳动 |
技术跨度大，团队抗压能力要求高 |
团队技术储备足，有充足测试资源 |
如果选择一步到位，推荐的技术组合：
Spring Boot 2.7.x + Spring MVC + MyBatis-Plus + MySQL Driver
- MyBatis-Plus：比原生MyBatis更高效，减少大量重复CRUD代码。
六、升级过程中的风险提示
| 风险点 |
说明 |
应对措施 |
| 线程安全 |
Struts2的Action是多例 ，Spring MVC的Controller是单例 |
检查Action成员变量，改为方法入参或@Scope("request") |
| 事务管理 |
Hibernate事务与MyBatis事务管理方式不同 |
统一用@Transactional注解，确认事务管理器配置正确 |
| SQL性能 |
HQL自动生成SQL可能性能差，但手写SQL同样可能写烂 |
迁移过程中同步进行SQL性能Review |
| 测试覆盖 |
大量代码重写，回归测试压力大 |
优先保证核心业务流程的测试用例覆盖 |
| 上线回滚 |
迁移失败需要快速回滚 |
采用灰度发布，新旧系统并行运行 |
七、一句话总结
SSH → SSM 是最复杂的"换心脏手术"；SSM → Spring Boot 是轻松的"保养升级"；SSH 直接到 Spring Boot 是"一步到位的大手术"，总工期最短但风险最高。
对于大多数团队，如果资源允许，建议直接走 SSH → Spring Boot 一步到位，因为SSH到SSM这一步本就是不可避免的大重构，多走一步只会增加重复劳动。