从 .NET 单体到 Java 微服务的迁移实践

技术栈迁移是架构师面对的最难课题之一：既要推倒旧的，又要保证业务不断。本文复盘我主导的一次公司级 .NET → Java 迁移。

为什么要迁

做这个决策时，公司的核心系统是运行多年的 .NET 单体，问题很现实：

  1. 人才：Java 生态的招聘池远大于 .NET，团队扩编困难
  2. 生态：微服务、云原生、中间件，Java 侧的成熟方案更多
  3. 国产化：信创环境对 Java 的适配和支持更完善

迁移不是技术洁癖，而是工程现实倒逼的战略选择。

迁移策略：双轨并行 + 渐进替换

最危险的做法是”停摆重写”。我们采用了双轨并行：

1
2
3
老 .NET 系统（继续跑）
        ↓ 逐步替换
新 Java 服务（增量上线）

具体节奏：

  1. 先建基础设施：注册中心、网关、数据库，先把”新世界的底座”搭好
  2. 从边缘模块开始：先迁相对独立、耦合度低的模块，积累经验
  3. 核心模块最后迁：等团队熟悉新栈、工具链稳定后再动核心

数据迁移的难点

代码能重写，数据不能丢。数据迁移的几个关键点：

  • 双写过渡期：新旧系统同时写库，用 MQ 同步，保证数据最终一致
  • 数据校验：迁移后抽样对比新旧系统的产出，确保口径一致
  • 可回滚：每个模块迁移都保留回滚到旧系统的能力

踩过的坑

  • 低估了数据迁移工作量：迁移 80% 的时间花在数据上，不是代码上
  • 过早追求微服务：初期服务拆太细，分布式事务问题频发，后来合并回大服务再逐步拆
  • 测试不充分：老系统有大量”隐式行为”（没人写在文档里的业务规则），迁移时容易遗漏，需要业务人员深度参与验收

小结

技术栈迁移最考验的是节奏感和风险控制，而不是技术本身。双轨并行、边缘先行、数据兜底、随时可回滚——这四条原则，比选什么框架重要得多。迁移完成后，团队终于可以站在一个统一、可扩展的技术底座上继续往前走，为后续云原生和 AI 化铺平了道路。