背景
最近在做一个事:下线一个超级大单体服务。单一统计代码行数其实不够全面,反正项目 git clone 下来文件就有这么大:
这是一个已经存在了十年以上的服务,随着业务的发展,这个服务已经无法满足我们的需求。
我们统计了一下,有近 400 个页面菜单需要迁移到已经划分好领域的各个微服务之中。
其实最麻烦的还是前端页面,因为页面重写是比较麻烦的,涉及到大量的细节梳理,可能还需要前端、设计和产品同学的介入,想在 1 年甚至几个月全部重写完成在有限的资源情况下是不可能完成的任务。所以我提出了一个方案,低改动迁移 + 按需重写:
- 低改动迁移
- 设计一套机制,能够快速、便捷地将单体服务的页面迁移至微服务 Web 工程。
- 保持页面几乎无改动,无需前端介入,以确保迁移过程的高效性。
- 不可避免的,后端代码需要进行改造,以适应新的 MVC 框架。
- 按需重写
- 结合实际业务需求和质量优化的工作,采用重写的方式。例如,对于一些核心的业务页面,我们可能会选择重写,以提供更好的用户体验和更高的性能。
接下来最关键的问题就是如何设计一套迁移机制:
- 技术栈迁移
- 从Spring + FreeMarker + Struts2 + Resin 迁移到 Spring Boot + Spring Web MVC + Embedded Tomcat + FreeMarker
- 架构转变
- 从纯动态数据交互最终演变为一个结合了静态页面渲染和动态数据交互的多模式 Web 应用(名词是我自己发明的)。这个新的架构可以更好地满足我们的业务需求,同时也提供了更好的用户体验。
- 理论分析
- Spring Web MVC 本身是一个基于 Java 的 MVC 设计模式的 Web 框架,且支持多种视图技术,包括但不限于 JSP、Freemarker、Thymeleaf 等
本文会记录在迁移的过程中碰到的一些有意思的点。在后续的文章中,我会详细介绍迁移经验,以及对其他面临类似问题的开发者的建议。