毕业一年遇上项目迁移

江湖纷扰，世事难料。项目迁移犹如一场江湖中的大规模门派搬迁，牵一发而动全身。如何在动荡中保持秩序，如何在变局中谋求稳定，成为了每个开发者的必修功课。这篇文章，便是记录一次笔者实际经历的项目迁移的纪实，愿为各位侠士提供一条可行之路。

缘起：新武学的觉醒

背景：

• 当前项目正处于技术迭代期，为了适应新业务需求，提升系统稳定性与扩展能力，以及后续的持续迭代开发与维护，需要对现有项目进行迁移。
• 此次迁移涉及路由转发规则配置、应用、数据库等中间件的迁移、以及部署平台的全面升级，堪称一次“内外兼修”的武道升级。

技术定位：

• 技术水平：中级
• 适用于具有一定开发和运维经验的工程师，能够独立完成代码迁移、系统配置调整以及问题排查。

目标群体：

• 开发人员：负责代码的迁移与功能实现。
• 运维人员：负责平台环境的搭建、配置与优化。
• 项目管理者：了解迁移过程中的资源分配与进度控制。

技术应用场景：

• 新平台上线：将项目从现有Pass平台迁移至内部自研的新平台。
• 集成部署升级：优化当前项目持续集成部署等方面的问题。

话不多说，下面进入正题。

筹谋慎思方成大计

江湖中，门派迁徙并非稀事，或因地盘不足，或因资源匮乏，或因盟友相邀。但无论缘由如何，这都不是一件可以草率行事的事情。项目迁移亦然，从开发环境到生产环境，从旧框架到新技术栈，每一步都需要精心筹备。因此项目迁移的第一步便是梳理现状，确定系统的根基稳固。

整体思路：

• 评估与准备：分析当前项目技术栈、部署环境及依赖，明确迁移目标和风险。
• 迁移规划：分阶段制定迁移计划，包括环境准备、数据迁移和代码调整。
• 实施与验证：逐步完成代码迁移、环境部署与系统配置，确保迁移过程中的平稳过渡。
• 测试与优化：通过功能测试、性能测试和安全测试，优化系统并解决潜在问题。
• 正式上线：在充分验证后，将系统切换至新平台，并做好应急预案。

在当前项目【后端】中采使用SpringBoot + Maven这一套常规的开发技术栈。迁移过程中已经明确数据库MySQL和MQ不动。因此本次迁移不涉及到数据的迁移。同时也明确是停机迁移。不涉及到在线迁移中的过渡、流量、路由切换等问题。同时应用之间不涉及强依赖关系，因此问题便很明了，只需关注打通环境以及应用即可。

粮草未动，兵马先行

在迁移之前，务必先做好准备工作。

迁移前的准备工作

• 准备工作一：新平台部署
• 准备工作二：将应用导入新平台
• 准备工作三：梳理需要迁移的配置和中间件【同时更改各个项目对应的配置项】
• 准备工作四：配置域名和HTTP转发
• 准备工作五：验证需要迁移的中间件等是否可用
• 准备工作六：在新平台上尝试构建应用
• 准备工作七：备份与兼容性检查【在未完全迁移前，做好以前代码、数据、环境等的备份工作。&& 在迁移失败或中断时，能够快速恢复到原环境。】

值得注意的是域名更换涉及到的各个场景的域名更改问题，具体如下表所示。整个准备过程仅针对笔者的场景，不同场景具体分析即可。

使用方	描述
前端调用后端	前端域名 + 相对路径【这里不用更改】
前端调用报表	涉及到的domain修改
报表调用后端	涉及到的domain和host修改
反向代理服务器	更改反向代理路径【nginx】
pc调用前端	验证新域名能否解析 && 是否配置host
外部系统调用后端	...
...	...

试招：江湖验真

分阶段迁移

• 优先迁移低风险服务：如无状态服务、非关键业务模块。
• 逐步验证：完成一个模块迁移后，进行全面测试，再迁移下一个模块。

配置管理

• 检查并调整配置文件（如 application.yml、nginx.conf）中涉及的 IP、域名、数据库连接等。

服务依赖迁移

• 检查所有外部服务依赖，如第三方 API、消息队列、缓存服务、文件存储等是否需要调整。
• 确保服务之间的网络连通性，尤其是在防火墙限制较多的环境下。

江湖险恶，步步为营

注意事项	备注
DNS解析	关于域名对应的DNS解析服务是否可用？
HTTPS 支持	是否启用 HTTPS 保障数据传输安全？
防火墙规则细节	防火墙规则是否包含 IP、白名单、黑名单、DDoS 防护？
Nginx 配置	是否在 Nginx 层支持请求限流及缓存机制？Nginx 是否支持后端健康检查，确保请求只转发到可用的 POD？
更换yml配置	是否存在写死在代码中的配置？通过更改yml配置无法替换到其他地方
基础服务和中间件验证	确保迁移前后的中间件版本和基础服务参数一致
部分走捷径的报表如何更改	部分报表配置的参数domain等需要更改
性能下降	平台升级后性能不足，导致响应变慢或服务异常（网络、IO、CPU还是某些系统配置导致？）
依赖的服务故障	依赖的服务等第三方接口无法联通

战后整军，方显宗师本色

用户反馈：

• 邀请部分核心用户或团队对迁移后的系统进行试用，收集反馈并优化。

功能测试

• 全量回归测试：覆盖主要业务场景，确保功能正常运行。
• 性能测试：检查迁移后是否满足 SLA（服务级别协议）的性能要求。
• 异常测试：模拟网络中断、服务宕机等异常情况，验证系统的容错能力。

监控与日志

• 迁移期间监控：重点监控 CPU、内存、磁盘 IO、网络流量等指标。
• 日志验证：确保日志采集和存储正常，日志格式一致。
• 报警机制：设置关键指标报警，发现问题时及时通知。

迁移是修行，不是捷径

江湖传闻，迁移到新环境后便能立刻提升效率，获得新生。但这不过是“后江湖时代”的一场幻梦。真正的高手明白，迁移只是内功修炼的一部分，唯有不断学习新技术，积累实践经验，才能在江湖中站稳脚跟。

简单写了写迁移过程的大概方针，不涉及具体细节，也可能不具备普适性。但还是想记录一下。项目迁移是一次跨越式的修炼过程。项目迁移的关键，不在于迁徙本身的复杂，而在于迁徙过程中确保稳中求进。每一步都如同在棋盘上落子，一子错，满盘皆输。正所谓，“磨刀不误砍柴工”，唯有精心筹备，方可保江湖安定，武学不失。同时也须谨记“修炼内功，稳扎稳打”之道。迁移只是江湖中的一场试炼，而非终点。唯有踏实走好每一步，方能登顶笑傲江湖。