绞杀者迁移、兼容与回退
绞杀者迁移把遗留系统的一部分能力逐步转到新实现，并在新旧路径并存期间维持兼容、验证和回退能力。
1. 选择一条可验证的业务切口
第一次迁移应满足几个条件：业务边界相对清楚、调用方可枚举、失败影响可控，并且迁移收益能够测量。只按代码行数选择“最容易拆”的模块，可能得不到任何独立价值。
切口可以是一组 URL、一个租户、一类订单或一段后台任务。迁移计划需要同时写出：
- 当前路径与依赖；
- 新实现的责任范围；
- 成功指标和数据校验方法；
- 新旧系统分别由谁维护；
- 回退与最终删除旧路径的条件。
2. 在稳定入口建立路由缝隙
绞杀者模式通常在客户端与遗留系统之间加入代理、网关或适配层。入口根据请求特征把一部分流量送往新系统，其余仍进入旧系统。
稳定入口避免所有调用方同时修改。路由规则必须可观测、可审计并能快速恢复，不能只靠人工修改一段 Nginx 配置。内部调用也可以通过 facade 建立相同缝隙。
新系统若仍需调用遗留能力，可以通过防腐层转换模型。转换逻辑集中在边界处，避免旧系统的字段、状态码和特殊规则扩散到新领域模型。
3. 先扩展契约再迁移调用方
接口和事件变更可以使用 expand–migrate–contract：
- 新系统先同时支持旧、新字段或版本；
- 调用方逐批迁移并记录版本使用；
- 观察到旧版本没有流量后，再删除兼容代码。
新增字段要有默认语义，枚举扩展要考虑旧消费者，事件不能随意改变已有字段含义。数据库迁移同样先增加结构、回填数据、切换读写，最后删除旧列。
兼容期要有截止日期和负责人。长期保留所有历史行为，会让新系统逐渐复制遗留系统的全部复杂度。
4. 数据迁移区分所有权
新旧系统同时写同一份业务数据时，双写顺序和部分失败很难处理。更稳妥的路径是先确定唯一写入方，再通过变更数据捕获、outbox 或迁移任务同步给另一方。
切换前需要完成：
- 全量数据回填和校验；
- 增量同步延迟监控；
- 主键、时间和枚举语义对齐；
- 重放幂等与失败隔离；
- 差异对账和修复工具。
数据量大时按租户、时间分区或业务键分批迁移。每一批都保留源范围、校验结果和当前所有权，避免回退时不知道应该相信哪一侧。
5. 影子流量验证结果
影子流量把真实请求复制给新系统，但不使用它的响应。它适合比较查询、计算和规则结果，同时不会直接影响用户。
影子验证要屏蔽邮件、扣款和消息发布等副作用。比较结果时区分可接受差异，例如时间戳、随机 ID 和排序；真正的业务差异进入可追踪的问题队列。
影子流量无法覆盖真实写入竞争和下游反馈。它通过后，再用内部用户、小租户或低风险业务逐步承接真实流量。
6. 灰度按风险逐步扩大
灰度规则可以按租户、地域、账号、请求哈希或业务类型分桶。每一阶段都检查：
- 成功率与延迟；
- 业务结果和数据差异；
- 下游错误、重试和消息积压；
- 资源成本与容量余量；
- 客服或人工处理量。
扩大流量前先满足观察窗口和样本量，不能只看几分钟没有告警。高风险写入还要确认回退后的数据处理方法。
7. 回退包含流量和数据
把路由切回旧系统只是流量回退。如果新系统已经产生新状态，还要决定：
- 旧系统是否已经同步到这些写入；
- 未完成流程由哪一侧继续；
- 新格式数据能否被旧版本读取；
- 已发布事件是否需要补偿或继续消费。
迁移前应演练回退，在时间限制内验证流量、状态和依赖恢复。对不可逆的数据变化，准备向前修复方案，并把它与普通回滚明确区分。
8. 退出条件决定何时完成
一条迁移只有在旧路径被安全删除后才结束。退出条件至少包括：
- 全量目标流量稳定运行一个约定周期；
- 数据差异已清零或有明确解释；
- 旧接口、事件和表没有消费者；
- 运维手册、告警和 on-call 已转交；
- 旧资源、权限和同步任务可以下线；
- 回退窗口关闭已获得业务和技术负责人确认。
缺少退出条件会形成永久双轨系统，维护成本比迁移前更高。
9. 面试题
9.1 怎样把一个遗留单体逐步迁移为新服务
出现公司：阿里巴巴
考察重点
- 业务切口、路由缝隙和防腐层。
- 契约兼容、数据所有权和分批校验。
- 灰度、回退和旧路径退出条件。
相关内容：第 1 节“选择一条可验证的业务切口”至第 8 节“退出条件决定何时完成”。
参考回答
我会先选一条边界清楚、影响可控并且能量化收益的业务路径，在网关或 facade 建立可切换的路由缝隙。接口采用先扩展、迁移调用方、再收缩的兼容流程；数据先明确唯一写入方，通过 CDC、outbox 或迁移任务同步，并完成全量回填、增量追平和差异对账。
上线前用无副作用的影子流量比较结果，再按租户或业务分桶逐级灰度。回退方案同时覆盖流量和已经写入的数据；不可逆变化准备向前修复。最后以稳定观察期、零未解释差异、无旧消费者、责任完成转交和旧资源下线作为退出条件，避免长期维护两套系统。