老系统迁移方案怎么做提示词（绞杀者模式、双写、数据校验、灰度切流与回滚）
要把老系统替换成新系统（重写、换数据库、单体拆服务、换云厂商）又不能停服时用：让 AI 设计逐步替换的迁移路线，包括流量路由、数据同步、新旧结果比对、按比例切流和每一步的回滚方案，避免「一刀切」上线翻车。
通用大模型 对话模型通用
你是一名主导过多次不停服迁移的架构师。请为下面的迁移设计详细方案。 - 迁移内容：[迁移内容]（例：把老 PHP 订单系统迁到新的 Java 服务） - 老系统现状：[架构、数据量、调用方] - 新系统现状：[已完成的部分、未完成的部分] - 业务约束：[业务约束]（例：不能停服、大促期间冻结变更、必须保留历史数据） - 可接受的风险：[可接受的风险]（例：允许个别用户短时间看到旧数据、绝不能丢订单） 请按以下结构输出： 1. 迁移策略：说明为什么采用逐步替换（绞杀者模式）而不是一次性切换；如果我的情况其实更适合一次性切换（例如系统很小），直接说明。 2. 拆分迁移单元：把老系统的功能按依赖关系和风险切成若干块，给出迁移顺序（通常先迁读多写少、依赖少的功能），每块的完成标准。 3. 流量路由：在哪一层做路由（网关、反向代理、应用内开关），怎么做到按功能、按用户比例、按白名单切换。 4. 数据迁移与同步： - 存量数据迁移方式与校验方法（行数、金额汇总、抽样比对）； - 迁移期间增量数据的同步方向（老写新读 → 双写 → 新写老读 → 只写新），每个阶段谁是数据的权威来源； - 双写失败时的处理（以哪边为准、如何补偿）。 5. 结果比对：在不影响用户的情况下，让新系统「影子运行」，比较新老系统对同一请求的结果，差异如何记录和分析。 6. 切流计划：每一步放量的比例、观察时长、观察指标、继续放量和回滚的判断条件。 7. 回滚方案：每个阶段分别怎么回滚、回滚后数据怎么处理；明确「越过这个点之后回滚代价变大」的节点。 8. 收尾：什么时候可以下线老系统、要清理的代码和数据。 输出一份阶段表：阶段 | 内容 | 前置条件 | 回滚方式 | 预计风险。
高亮处换成你自己的内容：[迁移内容]、[架构、数据量、调用方]、[已完成的部分、未完成的部分]、[业务约束]、[可接受的风险]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[可接受的风险] 写得越具体越好，它直接决定要不要双写、要不要影子比对。「绝不能丢订单」和「允许统计数据有几分钟延迟」需要完全不同的投入。[业务约束] 里的冻结期要写上，迁移计划要避开。
常见坑：
- 双写阶段没有明确「谁是权威来源」，两边数据不一致时不知道该信哪边。每个阶段都要写清楚。
- 没有做新老结果比对就直接切流，新系统在一些边缘场景（历史脏数据、特殊字符、时区）上的差异，上线后才被用户发现。
- 切到 100% 后马上下线老系统，出了问题无路可退。老系统应该保持可用一段时间。
追问技巧：追问「在第 3 阶段双写期间，如果新系统的数据库宕机半小时，会发生什么、恢复后怎么补数据」，逐个阶段推演故障场景。
示例输出
示例，仅供参考（阶段表节选）
| 阶段 | 内容 | 前置条件 | 回滚方式 | 风险 |
|---|---|---|---|---|
| 1 | 订单查询走新服务（只读，数据由老库同步） | 同步延迟小于 1 秒，比对差异率小于 0.01% | 网关路由切回老系统 | 低 |
| 2 | 新建订单双写，老系统为权威来源 | 阶段 1 稳定运行 1 周 | 关闭新系统写入 | 中 |
| 3 | 新系统为权威来源，老系统只接收同步 | 双写比对 2 周无差异 | 切回老系统为权威，补齐期间数据 | 高（越过此点回滚代价变大） |
| 4 | 停止同步，老系统只读保留 30 天 | 阶段 3 稳定 2 周 | 恢复同步 | 低 |
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～