在这种情况下，确保数据完整性需要实施 变更数据捕获 (CDC) 机制，并结合持续的对账流程。在迁移开始之前，必须使用 校验和 验证和 哈希 比较建立基线数据快照，以确定当前状态。在转换过程中，部署 Kafka Connect 或 Debezium 将遗留 ERP 数据库事务日志中的实时变更流式传输到新的 事件驱动 系统中。
实现分布式事务管理的 Saga 模式，以优雅地处理故障，而不损坏跨服务的数据。最后，使用 Apache Spark 或 Databricks 运行并行的 ETL 作业，在源系统和目标系统之间进行夜间对账，生成不一致报告以供人工审核，直到信心达到 99.99%。
我曾与一家全球零售连锁合作，迁移他们的库存管理系统，从一个已有 15 年历史的 Oracle ERP 单体系统到一个使用 Apache Kafka 和 PostgreSQL 的 微服务 生态系统。多年来，ERP 系统已被多个供应商修改，导致大约 30% 的历史库存变动有孤立记录和缺失的审计线索。该业务 24/7 跨时区运营，任何停机时间都将导致每小时损失 200 万美元的销售。
数据完整性挑战非常严峻，因为库存水平需要保持准确，以防止超卖，但我们无法暂停操作以进行干净的切换。
解决方案 1：实现 Debezium CDC 和实时流式处理
这种方法涉及配置 Debezium 连接器以监控 Oracle LogMiner，并将每个插入、更新和删除操作捕获为事件进入 Kafka 主题。优点包括接近实时的同步和毫秒级延迟，对遗留数据库性能影响最小。然而，缺点也很明显：CDC 无法调解缺失历史审计的现有数据间隙，遗留系统中的架构变化需要不断重新配置连接器，增加了维护开销。
解决方案 2：部署 Strangler Fig 模式与 API 拦截
我们考虑构建一个使用 GraphQL 联邦的抽象层，它将同时写入旧的 ERP 和新的 微服务，逐步迁移读流量。优点包括能够在生产中验证新系统的准确性与旧系统，并在出现差异时立即回滚。缺点包括基础设施成本翻倍，写操作延迟增加，以及维持两个不同存储模型（关系型 与 事件 源）间数据一致性的复杂性。
解决方案 3：创建 大批量 ETL 方法与维护窗口
这种传统方法建议使用 Apache Airflow 在低流量时段调度大批量转移，执行全表比较并使用 MD5 哈希。优点包括对每条记录进行彻底验证，对批量操作的错误处理较为简单。缺点直接违反了零停机时间的要求，因为 ERP 系统在获取一致快照时需要读锁，可能在高峰对账期间阻止库存更新 4-6 小时。
选定解决方案和理由
我们选择了混合式方法，结合 解决方案 1（Debezium CDC）进行持续同步，以及修改过的 解决方案 2 用于历史数据填补。我们使用 Kafka Streams 处理实时变更，同时在非高峰时段运行 Spark 作业来回填并验证 30% 缺失审计的记录。这个选择平衡了持续运营的需要与数据完全准确的要求，接受了更高的基础设施成本，因为这比潜在的停机成本更便宜。
结果
迁移完成耗时六周，没有发生意外停机。对账过程在客户受到影响之前识别并纠正了 12,000 条库存不一致。Prometheus 仪表板跟踪滞后指标，确保 CDC 延迟保持在 500 毫秒以内。在与自动对账并行运行三个月后，显示 99.97% 的准确性，我们停用了 ERP 模块，为公司节省了每年 400 万美元的许可费用，同时保持库存准确率在 99.9% 以上。
在 事件驱动 架构中，当事件是不可变的并且下游消费者依赖于特定字段结构时，您如何处理架构演变？
候选人通常会建议简单地更新事件架构，但这会破坏 事件源 的基本不可变性原则。正确的方法是实现 架构注册中心 模式，使用 Confluent Schema Registry 或 Apicurio。您必须使用具有向后和向前兼容性策略的架构版本控制：向后 兼容允许新消费者读取旧事件，而 向前 兼容允许旧消费者读取新事件。当无法避免破坏性变化时，您应实施 事件 升级 模式，创建一个单独的翻译层，在从事件存储读取时将旧事件格式转换为新的领域模型。这保持了不可变的审计线索，同时允许领域模型演变，尽管这会增加消费者逻辑的复杂性，并需要仔细管理架构演变政策。
在零停机迁移期间 CAP 定理 对数据一致性决策的具体影响是什么，您如何向非技术利益相关者沟通权衡？
许多候选人提到 CAP 定理，但未能将其实际应用于迁移场景。在零停机迁移期间，您不能同时保证 一致性、可用性 和 分区容忍性——您必须选择两个。在分布式迁移中，您通常会牺牲即时的 一致性 以换取 可用性 和 分区容忍性，实施 最终 一致性。为了向商业利益相关者传达这一点，避免使用 "CAP" 或 "ACID" 等技术术语；相反，解释在过渡期间，不同系统可能会短暂显示不同的库存数量，但它们将在几分钟内对齐。使用具体的例子："客户可能会在网站上看到某个商品有货，但在结账时收到 '缺货' 消息，大约在系统同步期间持续 30 秒"。这为 "一致性窗口" 设置了现实预期，并帮助利益相关者理解为何需要对账过程而不是实时完美。
您如何计算临时数据不一致的可接受财务成本与延迟迁移截止日期的成本之间的平衡点，哪些指标定义了盈亏平衡点？
候选人常常忽略迁移的定量风险分析方面。您必须通过分析历史数据的错误率和业务影响来计算 不一致成本 (COI)：将平均每日交易量乘以错误概率再乘以每个错误的平均成本（包括客户服务时间、退款和声誉损失）。这与 延迟成本 (COD) 相比较，包括持续的遗留许可证费用、错失的市场机会和技术团队的士气/流失成本。盈亏平衡点发生在 COI × 迁移持续时间 = COD × 延迟持续时间。例如，如果数据不一致每天损失 5,000 美元，而延迟成本每天为 50,000 美元，您可以容忍最长 10 天的对账问题，然后延迟将变得更贵。您应建立 服务级别目标 (SLOs)，例如"对账滞后低于 0.1% 的记录"，并定义自动回滚触发器，如果错误率超过历史基线的 3 个标准差。