兼容层与迁移策略

• 兼容层必须"有期限"，不能永久存在
• 退场时间表的制定与执行
• 兼容层退场的条件与风险

兼容层（compatibility layer）是为了平滑迁移而存在的临时过渡，绝不应永久存在——否则它本身会成为新的技术债。因此维护一个兼容层时必须同步制定"退场时间表"（sunset schedule）：明确此兼容层何时下线、过渡到新系统的条件、以及退场后如何处理旧契约。制定退场时间表的要点：1) 设定明确的"最后期限"与"下线版本"（如"v2 发布后保留 3 个版本，此后移除"）；2) 确定退场触发条件——如"所有消费者迁移完成""旧版调用率降为 0"；3) 监控兼容层的调用量与迁移进度，作为退场决策依据；4) 预留回退与缓冲，避免过早下线导致未迁移方受损；5) 把退场任务登记进 backlog，避免"忘了移除"。兼容层若无限期维护，会持续付出双份维护成本（新旧两套都要维护），因此"有期限、有计划、有监控"的退场时间表是兼容层治理的关键。

本题考察"兼容层的生命周期管理"。核心是"兼容层是临时的，必须有退场计划"。回答强调"有期限 + 监控触发 + 退场登记"，体现对兼容层治理的完整认知。

• 兼容层的四个层面：接口、数据、消息、用户
• 各层面兼容的含义与场景
• 兼容层范围选择的权衡

兼容层的范围（scope）指兼容需要覆盖的层面，通常包括四个层面：1) 接口层（API）——对外 API 的签名、语义保持兼容，让存量调用方无需改动即可继续工作；2) 数据层（Data）——数据库 schema、存储格式的兼容，保证数据读写不因迁移而破坏；3) 消息层（Messaging）——消息队列的 topic、消息格式、事件 schema 的兼容，保证生产消费双方不中断；4) 用户层（User）——用户视角的行为兼容，如 URL、页面、交互、配置的向后兼容，保证用户体验不中断。不同迁移场景需要覆盖的层面不同：纯 API 迁移主要覆盖接口层；数据库迁移需覆盖数据层；微服务拆分需覆盖接口+消息层。选择兼容层范围时，要依据"哪些消费者不可变"来决定范围大小，范围过大则维护成本高，过小则可能破坏兼容。四层统一考虑，才能保证迁移期间系统的整体可用。

本题考察"兼容层的全景视野"。核心是"接口、数据、消息、用户四层"。回答强调"按迁移场景选范围 + 范围过大成本高、过小破坏兼容"，体现对兼容层边界的把握。

• 兼容层的目的：维持外部契约
• 外部契约的含义（接口、数据、行为）
• 兼容层与迁移的关系

兼容层（compatibility layer）的核心目的是"维持外部契约"——在系统内部发生迁移、重构或替换时，对外部消费者（其他服务、客户端、第三方）承诺的接口、数据格式与行为语义保持不变，从而让"内部大变"与"外部无感"同时成立。外部契约包括：接口签名与语义、数据格式与 schema、消息结构、行为约定（如错误码、幂等性）。兼容层作为"翻译/适配"的中间层，把新系统的实现映射回旧契约，使消费者无需迁移即可继续工作。维持外部契约的意义：1) 降低迁移风险——内部可大刀阔斧重构，外部不受影响；2) 支持渐进式迁移——消费者可以按自己的节奏逐个迁移，而非被迫一次性切换；3) 保护生态——对第三方/存量客户负责，避免破坏性变更。兼容层的本质是"用额外的适配复杂度换取外部契约的稳定"，是迁移策略的缓冲器。

本题考察"兼容层的本质"。核心是"维持外部契约、隔离迁移影响"。回答强调"内部变化、外部无感"与"支持渐进迁移"，体现对兼容层设计意图的理解。

• Adapter 模式：适配新旧接口
• Facade 模式：统一入口
• Strangler Fig（绞杀者）模式：逐步替换

接口迁移（API migration）是替换/升级对外 API 时保持兼容的策略，常用模式包括：1) Adapter（适配器）——用一个适配器把新接口适配成旧接口的形态，让调用方无需改动即可继续调用；适合接口签名变化、但功能对应的情况；2) Facade（门面/外观）——在新旧系统之上提供一个统一入口/门面，把复杂的内部迁移封装起来，调用方只面对门面，内部如何切换对他们透明；适合整合多个系统或隐藏迁移细节；3) Strangler Fig（绞杀者模式）——渐进式地把旧系统功能一个个替换到新系统，同时路由部分流量到新系统，逐步"绞杀"旧系统，直到完全替换；适合大型单体拆分、无法一次性切换的场景。三者常结合：用 Facade 提供统一入口，用 Adapter 处理局部适配，用 Strangler Fig 把控渐进替换节奏。选择时依据迁移规模、可切换性与风险偏好。

本题考察"接口迁移的三种核心模式"。核心是"适配、门面、绞杀者"。回答强调"各自适用场景与可组合使用"，体现对迁移模式库的掌握。

• expand & contract（扩展-收缩）模式
• 迁移工具 Flyway、Liquibase
• 数据库迁移的版本化与回滚

数据库迁移（DB migration）是在不破坏数据与可用性的前提下变更 schema 的策略，核心模式是 expand & contract（扩展-收缩）：1) expand（扩展）——先添加新列/新表/新索引，新旧并存，应用层先写新、读兼容；2) contract（收缩）——待所有消费者都迁移到新结构后，再移除旧列/旧表/旧索引。这种"先加后删、双写过渡"的模式避免了破坏性变更。工具方面，Flyway 与 Liquibase 是主流 schema 版本管理工具：1) Flyway——以版本化 SQL 脚本管理迁移，按版本号顺序执行，简单轻量，适合团队熟悉 SQL 的场景；2) Liquibase——用 changelog（XML/YAML/SQL）描述变更，支持更丰富的变更项与回滚（rollback），适合复杂变更与多环境管理。两者都保证 schema 迁移的版本化、可重复、可审计。数据库迁移务必配合"向后兼容、可回滚、灰度执行",避免线上数据丢失。

本题考察"数据库迁移的方法与工具"。核心是"expand & contract 模式 + 版本化工具"。回答强调"先加后删避免破坏 + 工具保证版本化与回滚"，体现对数据库迁移的实操认知。

• 双写（dual write）：同时写新旧库
• 影子读（shadow read）：对比新旧库结果
• 批量回填（backfill）：离线一次性迁移

数据迁移（data migration）是把数据从旧存储迁移到新存储的三种主要方式：1) 双写（dual write）——应用同时向新旧两个存储写入数据，保证新库持续获得最新数据，常用于在线迁移；2) 影子读（shadow read）——把线上读请求同时"影子"地打到新库，对比新旧库的返回结果，用于验证新库正确性，不影响真实流量；3) 批量回填（backfill）——把存量历史数据离线一次性从旧库迁到新库（批量导入），适用于大量历史数据的迁移。三者通常组合使用：先批量回填存量数据，再用双写保证增量数据持续同步，用影子读验证一致性，最后校验完成后再切换读流量。这种"存量回填 + 增量双写 + 影子验证"的组合，是保障数据迁移正确、平滑、可回滚的标准做法。

本题考察"数据迁移的三种手段"。核心是"存量回填 + 增量双写 + 影子验证"。回答强调"三种方式的分工与组合"，体现对数据迁移封闭流程的把握。

• 双写可能产生不一致的原因
• 异步对账的机制与周期
• 对账告警与修复闭环

双写过程中，新旧两端可能因网络抖动、部分写入失败、时序问题等产生不一致，因此必须设计"异步对账"来发现并修复差异。对账设计要点：1) 对账机制——定期扫描新旧两端的数据，按主键比对，找出"新有旧无""旧有新无""内容不一致"的差异；2) 对账周期——按一致性要求权衡：核心数据（资金、订单）可高频对账（如每分钟或近实时），一般数据可低频（如每日），对账与全量比对成本有关；3) 修复（reconcile）——对发现的差异，以"权威源"为准回填修复（通常以新库为权威，或按业务规则确定），并记录修复日志；4) 告警——设置差异率阈值与告警，差异超过阈值（如万分之一）或发现关键数据不一致时立即告警，触发人工介入；5) 趋势监控——跟踪对账发现的差异率，若持续升高说明双写环节有问题，需排查写入链路。对账形成"发现-修复-告警-复盘"的闭环，是双写可靠性的保障。

本题考察"双写一致性的运维保障"。核心是"对账机制 + 周期选择 + 告警闭环"。回答强调"以权威源修复 + 差异率阈值告警 + 趋势监控"，体现对数据一致性的工程化理解。

• 绞杀者模式的组件级应用
• 特性开关（feature flag）的渐进迁移
• 组件迁移的流量控制

组件迁移（component migration）指把一个模块/组件从旧系统迁移到新系统，常用绞杀者模式与特性开关配合：1) 绞杀者模式（Strangler Fig）——在组件层面，保留旧组件外壳，先把新组件逐步实现并接入，通过路由把部分流量导向新组件，逐步扩大新组件比例，直到旧组件完全被"绞杀"移除；2) 特性开关（feature flag）——用开关控制新组件是否生效，先对内部/小流量开启，验证后再逐步放量，异常可随时关闭回退。两者结合：用特性开关控制"新组件对新用户/新流量"的灰度比例，用绞杀者模式管理"旧组件逐步下线"的节奏。组件迁移的关键是"可控制、可回退、可验证"——通过开关控制影响面，通过监控验证新组件行为，通过并行运行降低风险。组件迁移比整库迁移更轻量，适合渐进式替换。

本题考察"组件级迁移的渐进策略"。核心是"绞杀者模式 + 特性开关的灰度控制"。回答强调"可控制、可回退、可验证"，体现对渐进迁移的实操。

• 双写的定义：同时写新旧库
• 双写的优点：保持新库最新、支持渐进切换
• 双写的缺点：双倍写入、一致性问题

数据迁移的"双写"（dual write）指应用在每次写入时同时写旧库与新库，以保证新库持续获得最新数据，为后续切换做准备。优点：1) 新库始终有最新增量数据，切换时无需再补数据；2) 支持渐进式迁移——可以边写边验证新库，逐步把读写切到新库；3) 切换前可随时回退到旧库，风险可控。缺点：1) 双倍写入开销——每次写入都打两个库，增加延迟与资源消耗；2) 一致性问题——双写可能因部分失败、时序造成新旧不一致，需要对账保证；3) 实现复杂度——需要处理双写失败、幂等、事务边界等。因此双写通常与"批量回填（存量）+ 影子读（验证）+ 对账（修复）"配合使用，用双写保证增量、用对账保证一致。双写是"在线数据迁移"的核心手段。

本题考察"双写模式的利弊"。核心是"双写保增量 + 需对账兜底"。回答强调"优点支撑渐进切换、缺点需对账修复"，体现对双写模式的全面认知。

• 影子读的定义：并行读新旧库对比
• 影子读的验证作用
• 影子读的局限

数据迁移的"影子读"（shadow read）指在真实读请求时，把请求"影子"地复制一份打到新库，并将其返回结果与旧库结果对比，但不影响真实流量与用户。它的作用是验证新库的正确性——通过对比新旧库返回的数据，发现新库中数据缺失、错误或结构不一致的问题，从而在切换到新库前确认其可用。影子读的特点：1) 只读、不写，不影响生产；2) 对比结果用于发现差异，可统计差异率；3) 通常配合双写（新库持续有数据）才有意义，否则新库没数据无法对比。局限：1) 只验证"读"的正确性，不验证"写"；2) 对比结果可能受时序（新旧库数据不同步）影响产生误报；3) 需要额外的对比逻辑与日志。影子读是"切换前验证"的重要手段，与双写、对账共同构成数据迁移的验证体系。

本题考察"影子读的验证作用"。核心是"只读对比、不扰流量、验证新库"。回答强调"配合双写才有意义 + 只验证读不验证写"，体现对影子读定位的准确理解。

• 批量回填的定义：离线一次性迁移存量
• 适用场景：大量历史数据
• 批量回填与增量同步的衔接

数据迁移的"批量回填"（backfill）指把存量历史数据从旧库离线一次性迁移到新库，通常通过批量导入、ETL 任务实现。它适用于：新库需要承载历史数据、且存量数据量大的场景（如换库、换存储引擎、数据重构）。批量回填的特点：1) 一次性、批量执行，处理"存量"数据；2) 需要处理数据清洗、格式转换、去重、外键关联等；3) 执行期间新库可能仍有增量写入，因此回填通常与"双写"配合——先回填存量，再靠双写同步增量，或回填后补一次增量。批量回填的挑战：1) 数据量大时耗时长，需分批、断点续跑；2) 回填期间产生的增量数据不能丢失，需与增量同步衔接；3) 回填后需校验数据完整性（数量、值、一致性）。批量回填是"存量迁移"的骨干，与双写（增量）、影子读（验证）构成完整的数据迁移方案。

本题考察"批量回填的定位与场景"。核心是"回填存量 + 与增量衔接 + 校验"。回答强调"回填是存量骨干、需配合增量与校验"，体现对数据迁移流程的理解。

• 读新写旧的定义：读新库、写旧库
• 渐进切换的步骤
• 读新写旧的应用场景

数据迁移的"读新写旧"（read new, write old）指在迁移过程中，把读流量切到新库、但写仍写旧库，是实现渐进切换的一种方式。逻辑是：先让系统"读新库"来验证新库读取功能与数据，同时"写旧库"保证数据写入的权威与回退能力；当新库读验证通过后，再把写也切到新库。这种"读先行、写后置"的渐进切换，能降低一次性切换的风险——先验证读路径，再验证写路径。它与"读旧写新"（read old, write new）相对，后者是"写新库、读旧库"，用于先验证新库写入。两种方式都要求新旧库之间保持数据同步（通过双写或同步任务），否则读旧写新会读到旧数据。读新写旧适用于：新库数据已通过回填/双写就绪、想先验证读体验的场景。切换的最终目标是"读写都切到新库、旧库退役"。

本题考察"渐进切换的读写分步"。核心是"读新写旧降低切换风险"。回答强调"读先行验证、写后置、依赖双写同步"，体现对切换节奏的把握。

• 适配器（Adapter）兼容设计
• 版本桥接（version bridge）设计
• 兼容层设计的可用性

兼容层的设计核心是"在不改变外部契约的前提下适配内部变化"，常用两种设计：1) 适配器（Adapter）——把新系统的接口/数据结构适配成旧契约的形态，使调用方无需改动。适配器负责"翻译"：把新版本的入参/出参映射回旧版本，处理字段差异、默认值、语义映射。适配器适合"接口签名变化但功能对应"的场景；2) 版本桥接（version bridge）——在多个版本之间架桥，让不同版本的客户端与不同版本的服务端互通。它通常维护"版本映射表"，把请求按版本路由到对应处理器，并做版本间的转换（如 v1 请求转成 v2 内部格式）。版本桥接适合"多版本并存、需兼容不同客户端"的场景。兼容层设计要点：1) 保持纯适配、不夹带业务逻辑；2) 明确的错误处理与降级；3) 监控适配器调用量与错误，便于退场决策；4) 可测性（适配逻辑要被测试覆盖）。良好的兼容层设计让"内部演进"与"外部稳定"兼得。

本题考察"兼容层的具体设计"。核心是"适配器翻译 + 版本桥接互通"。回答强调"纯适配、可测、可监控、支持退场"，体现对兼容层设计质量的把控。

• 源码兼容、二进制兼容、行为兼容的区别
• 检测破坏性变更的工具
• 兼容性检测在 CI 中的应用

接口兼容有三个层次：1) 源码兼容（source compatibility）——消费者代码无需修改即可重新编译运行；2) 二进制兼容（binary compatibility）——消费者已编译的二进制无需重新编译即可运行，更严格（如方法签名变化、字段移除都可能破坏二进制兼容）；3) 行为兼容（behavioral compatibility）——接口签名不变但运行行为一致，如返回结果、异常、性能语义不变。三者严格程度递增：符合二进制兼容通常也符合源码兼容，但行为兼容最难保证。检测破坏性变更的工具：Java 生态用 japi-compliance-checker、Revapi、japicmp 等对比新旧 jar 的 API，检测方法/字段/类型的变化；前端可用 semver 校验 + 类型定义对比（TypeScript API Extractor）；OpenAPI 审计工具可检测 RESTful 接口的破坏性变更。这些工具集成到 CI，在发布前自动拦截破坏性变更，配合 semver（语义化版本）管理契约演进。

本题考察"兼容性层次与自动化检测"。核心是"源码/二进制/行为三级兼容 + 工具检测破坏性变更"。回答强调"塞进 CI 自动拦截 + semver 管理"，体现对接口契约治理的工程化。

• 回填与增量的衔接问题
• 回填期间新增数据不丢失的机制
• 双写与回填的顺序安排

批量回填处理"存量"，增量同步处理"回填期间新增的数据"，两者必须衔接，否则回填期间新写入的数据会丢失。常见做法与顺序：1) 先开启双写（同时写旧库与新库），让新库从回填开始前就持续接收增量；2) 再执行批量回填，把存量数据迁入新库；3) 回填完成后，比对"回填 + 双写"的数据，对回填期间可能因并发产生的新增/冲突做最终对账补平。关键点：回填要"幂等"（可重复执行不产生重复数据），且与双写之间要有"去重/合并"机制（如以主键 upsert），避免回填与双写写入同一记录时冲突。另一种顺序是"先回填再双写"，但回填期间的新增数据会丢失，因此需在回填结束的时间点重放增量或做一次时间点对账。推荐的"先双写、再回填、最后对账"顺序，能保证任意时刻新增数据都不丢失，并最终收敛一致。

本题考察"存量与增量迁移的衔接"。核心是"先双写保增量、再回填、最后对账"。回答强调"幂等回填 + 对账补平 + 时间点法"，体现对数据迁移细节的把握。

• 读旧写新的定义：写新库、读旧库
• 读旧写新的应用场景
• 与读新写旧的对比

数据迁移的"读旧写新"（read old, write new）指在迁移过程中，把写流量切到新库、但读仍读旧库，用于先验证新库的写入能力。逻辑是：先让系统"写新库"来验证新库的写入路径与数据落库，同时"读旧库"保证读的稳定与回退能力；当新库写入验证通过、数据也同步回旧库（或旧库读到的是最新数据）后，再把读也切到新库。这种方式适用于"想先验证新库写入正确性、再决定切换读"的场景。它要求新旧库之间数据能同步（通过双向同步或回读），否则"读旧库"会读不到新库刚写入的数据。读旧写新与"读新写旧"（read new, write old）互为镜像，代表"先验证写"与"先验证读"两种渐进切换路径。最终两者都收敛到"读写全部切新、旧库退役"。

本题考察"读旧写新的渐进切换路径"。核心是"先验证写、后切换读"。回答强调"与读新写旧互为镜像、需数据同步配合"，体现对切换路径的完整理解。

• 并行运行：新旧系统并存
• 影子流量：复制流量验证
• 切换：灰度与全量

迁移策略的完整流程通常包括并行运行、影子流量与切换：1) 并行运行（parallel run）——新旧系统同时运行，双写数据、双读对比，让新系统在"后台"逐渐成熟，同时旧系统保持可用，是可回退的稳妥方式；2) 影子流量（shadow traffic）——把真实流量复制一份打到新系统，不影响真实用户，用于压测新系统容量、验证行为正确性，是并行运行的验证手段；3) 切换（switchover）——经过验证后，把流量按灰度比例逐步从旧系统切到新系统（如 1%→10%→50%→100%），每步观察指标，异常可回退。组织方式：先并行运行 + 影子流量充分验证新系统，再灰度切换逐步放量，最后全量切换并退役旧系统。整个过程强调"可回退、可观察、灰度渐进"，任何一步异常都可回到旧系统。这套"并行+影子+灰度"组合是大型迁移的标准范式。

本题考察"迁移的全流程组织"。核心是"并行验证 + 影子流量 + 灰度切换"。回答强调"可回退、灰度渐进、可观察"，体现对迁移节奏的成熟把控。

• API 兼容性测试
• 数据格式兼容性测试
• 兼容性测试的自动化

兼容性测试用于验证迁移/升级后，新旧版本的 API 与数据格式仍能被消费者正确识别与处理。API 兼容性测试：1) 契约测试（contract test）——用消费者驱动的契约（Consumer-Driven Contracts）验证新旧 API 是否符合消费者期望的契约；2) 回归测试——对旧版本客户端调用新版本服务端（及反向）做全链路验证，确保签名、语义、错误码兼容；3) 工具——用 OpenAPI/契约文件比对，检测破坏性变更。数据格式兼容性测试：1) 序列化测试——用新旧 schema 对同一数据做序列化/反序列化，验证字段兼容（新增字段用默认值、类型不变）；2) 版本化数据测试——对旧版本格式的数据，用新版本代码读取，验证能正确解析；3) 反向测试——新格式数据能被旧版本读取（若需向后兼容）。这些测试应集成到 CI，在每次变更时自动运行，作为"兼容层不破坏外部契约"的保障。兼容性测试是迁移安全网的一部分。

本题考察"兼容性测试的具体方法"。核心是"契约测试 + 序列化/版本化数据测试 + 自动化"。回答强调"前后向兼容都测 + 集成 CI"，体现对兼容性保障的工程化。

• 可逆迁移步骤的设计
• 回滚预案的制定
• 灰度流量比例与观察期

迁移必须具备"可逆性"与"回滚预案"，否则一旦出错难以挽回。设计要点：1) 可逆步骤——每一步迁移都应是"可逆"的，如 expand & contract 的"先加后删"、双写的"先写新再切读"，保证任何一步都能回到前一状态；2) 回滚预案——预先定义回滚触发条件（如错误率、延迟超阈值）与回滚操作（切回旧系统、恢复旧数据），并演练；3) 灰度流量比例——按风险递增放量，常用 1%→5%→10%→25%→50%→100%，从低风险用户（内部/测试）开始；4) 观察期——每档灰度后设观察期（如 15 分钟到数小时），监控错误率、延迟、数据一致性、业务指标，确认稳定后再放量；5) 监控与告警——全程监控关键指标，异常立即触发回滚。迁移完成后不要立即删除旧系统，保留一段"回退期"（如一到两周）再退役。核心原则是"小步、可回退、可观察、灰度渐进"。

本题考察"迁移的风险控制"。核心是"可逆步骤 + 回滚预案 + 灰度观察期"。回答强调"逐步放量、监控触发回滚、保留回退期"，体现对迁移安全性的把控。

• 兼容层可观测性的指标
• 调用量、失败率、转换错误的监控
• 用可观测数据驱动退场决策

兼容层需具备完善的可观测性，才能监控其健康度并作为退场决策依据。关键指标：1) 适配器调用量——统计兼容层被调用的频率与趋势，判断还有多少消费者依赖旧契约；调用量持续下降说明迁移在推进，降到 0 是可退场的信号；2) 失败率——兼容层转换/适配的失败比例，高失败率说明适配逻辑有缺陷或出现兼容性问题，需要修复；3) 转换错误——记录适配过程中发生的字段映射错误、类型转换异常、默认值回退等，用于定位兼容问题；4) 调用方画像——哪些消费者还依赖兼容层，便于逐个推动迁移。这些指标通过日志、埋点、监控大盘（如 Prometheus/Grafana）呈现。退场决策依据：当兼容层调用量趋近 0、剩余消费者已迁移、且无转换错误时，可启动退场时间表；若调用量仍高，则说明退场过早，应继续维护。用可观测数据驱动退场，避免"拍脑袋下线"或"无限期保留"。

本题考察"兼容层的可观测性"。核心是"调用量/失败率/转换错误监控 + 数据驱动退场"。回答强调"用调用量趋势判断退场时机、防止过早或过晚下线"，体现对兼容层治理的闭环。