如何在不进行大爆炸式重写的情况下逐步迁移遗留单体应用

为什么大爆炸式迁移遗留单体应用风险很高？

大爆炸式迁移试图一次性替换整个系统，导致运行时、框架、数据库、API契约、认证、数据模型、业务逻辑等大量变量同时改变。一旦最终切换失败，可能的原因极多，难以定位，例如定价逻辑变化、数据丢失、支付提供商故障、认证行为差异、超时变短、事件停止发布等。这种迁移方式将风险集中在一个不可逆的事件上。

如何选择第一个迁移的业务能力？

应选择中等流量、外部依赖有限、行为清晰、测试覆盖好、事务边界少、影响范围小的能力。避免从最关键的能力开始，例如“授权支付”风险太高，而“生成客户对账单”可能是更好的起点。第一个迁移不仅是技术工作，也是验证路由、部署、可观测性、回滚、数据访问和团队工作流的练习。

Strangler Fig模式在增量迁移中如何应用？

Strangler Fig模式通过在新旧系统之间引入路由，让新实现逐渐包围旧系统。初始时所有流量走旧路径，然后逐步将少量流量（如1%、5%、10%……）切换到新路径，观察对比后再扩大比例，最终完全替换旧实现并移除旧路径。这种方式使替换逐步发生，旧系统在过渡期间继续服务其他部分。

增量迁移中如何设计回滚？

回滚应在部署前设计好。对于路由级迁移，回滚可能只需关闭功能标志（如将useNewInvoices设为false），流量立即回到旧实现。但如果涉及数据格式变化、新数据写入、事件差异或外部系统更新，回滚可能更复杂，需要向后兼容的schema、补偿操作、可重放事件或对账作业。关键是要明确回滚在何时仍然可逆，何时已进入不同的恢复策略。

迁移过程中如何处理数据所有权？

数据所有权必须明确。对于每个迁移的能力，应定义系统记录、写入所有者、读取者、复制方向和一致性期望。例如，发票的写入所有者是新系统，新数据库是真相来源，旧系统通过只读适配器访问，复制方向为新到旧报告存储。没有所有权规则，迁移常会导致永久性的同步问题。

AI在增量迁移中能起到什么作用？

AI可以加速迁移中的分析工作，例如检查遗留代码库，识别实现某能力的模块、调用者、数据库表、外部服务、副作用、现有功能标志和迁移接缝；也可以比较新旧实现，识别返回值、错误、副作用、持久化、事件顺序、重试、幂等性和事务边界等方面的行为差异。但AI不能替代工程判断，不应让AI将增量迁移变成自动重写。

增量迁移的完整工作流程是什么？

完整工作流程包括：理解能力（输入、输出、规则、副作用、依赖）、用特征测试保护现有行为、重构以创建接缝和边界、构建新实现、对新旧实现进行差异测试、引入显式路由、从安全流量开始、逐步增加流量、监控技术和业务指标、保持回滚可用、转移数据所有权、最后移除遗留路径。然后选择下一个能力重复此过程。

增量迁移不能解决哪些问题？

增量迁移降低风险，但不能消除复杂性。仍可能面临分布式事务、共享数据库、旧schema、紧耦合、不支持的运行时、测试覆盖差、组织所有权和监管约束等问题。对于高度有状态系统、强耦合桌面应用、大型事务批处理系统或共享全局状态的系统，部分迁移可能极其困难，迁移边界可能需要更大。原则是做出最小的可逆变更以产生有用的迁移进展。