3. 数据库迁移场景分析：同步迁移 vs 异步迁移的追踪差异
数据库迁移是微服务架构中最常见的变更操作之一，但迁移的执行方式——同步还是异步——直接决定了故障排查的难度和可观测性数据的质量。本章从追踪视角剖析两种迁移模式的本质差异，帮助你在设计迁移方案时提前埋下正确的观测点。
3.1 同步迁移：线性依赖下的追踪优势
同步迁移指迁移任务在单个请求-响应周期内完成，客户端等待迁移结果返回后才继续后续操作。这种模式天然形成一条完整的追踪链路。
关键特征： 一个 Trace 包含所有 Span，父 Span 等待子 Span 完成，时间轴严格线性。
3.2 异步迁移：解耦带来的追踪断裂
异步迁移将迁移任务拆分为“提交请求”和“执行迁移”两个独立阶段，通常通过消息队列或任务调度器解耦。这种模式虽然提升了系统弹性，却切断了追踪链路的连续性。
核心痛点： 提交请求的 Trace 与后台执行的 Trace 分属不同 Trace ID，需要通过自定义关联 ID（如 migration_id）手动拼接。
3.3 核心差异对比表
| 对比维度 | 同步迁移 | 异步迁移 |
|---|---|---|
| Trace 完整性 | 单个 Trace 包含所有步骤 | 多个 Trace 需手动关联 |
| 延迟归因 | 直接定位到耗时 Span | 需跨 Trace 计算总耗时 |
| 错误传播 | 异常 Span 自动传递到父 Span | 错误需通过回调或轮询捕获 |
| 上下文传递 | 自动通过 HTTP Header 传递 | 需手动注入到消息体或任务参数 |
| 可观测性复杂度 | 低，标准分布式追踪即可 | 高，需结合日志和指标联合分析 |
| 适用场景 | 小数据量、低延迟要求 | 大数据量、长时间运行、容错要求高 |
3.4 异步迁移追踪的三大陷阱
- Trace ID 丢失：消息队列或任务调度器不原生支持 W3C Trace Context 传播，导致后台 Worker 无法继承前端的 Trace ID。
- 时间窗口错位：异步任务可能延迟数分钟甚至数小时执行，前端 Trace 已过期，后台 Trace 独立出现，排查时难以建立时间关联。
- 状态不一致：迁移任务可能部分成功、部分失败，但异步模式下前端只收到“已提交”响应，后端失败信息无法实时反馈到追踪链路中。
最佳实践： 在异步迁移场景中，始终在消息体或任务参数中携带
migration_id 和 traceparent 字段。Worker 启动新 Trace 时，通过 OpenTelemetry 的 Span Link 将当前 Span 关联到原始 Trace，确保端到端可追溯。
3.5 选择建议：何时用同步，何时用异步？
从可观测性角度出发，同步迁移始终是首选——它天然提供完整的追踪链路。但在以下场景中，异步迁移不可避免：
- 数据量超过 100 万行：同步迁移可能导致 HTTP 超时（通常 30s-60s），必须异步化。
- 跨多个数据库实例：需要分布式事务协调，异步模式允许分阶段提交和补偿。
- 迁移过程中需要人工审批：异步模式可以挂起任务等待外部信号。