题干与适用场景
一个多语言微服务平台同时使用 OpenTracing API、厂商 shim 和 OpenTelemetry SDK。OpenTelemetry 规范在 2026 年 3 月起不再要求新实现提供 OpenTracing 兼容性，但现有 shim 仍需在过渡期运行。请设计迁移方案，要求不中断追踪、可控制成本，并能在单个服务出现问题时回滚。
面试官考察点
面试官考察你能否区分 API 兼容、数据语义兼容和后端协议兼容；能否处理 trace/span 属性映射、上下文传播、采样一致性、双写成本和供应商锁定。高质量回答会给出迁移顺序、验收指标与失败隔离，而不是只说“替换依赖”。
回答前需要澄清的问题
- 现有 OpenTracing 调用集中在哪些语言和框架，shim 是否修改过语义？
- 追踪后端是否接受 OTLP，历史数据和查询维度是否必须保持一致？
- 迁移优先级是零丢失、低开销、统一语义，还是供应商可替换性？
- 是否允许短期双写，采样率和每服务成本上限是多少？
30 秒回答
“我会把迁移拆成 API、语义、传输和运营四层。先冻结新的 OpenTracing 依赖，盘点 shim、传播格式和关键属性；在一个服务中接入原生 OpenTelemetry，同时保留 shim 作为兼容入口，用一致的 trace context 和采样策略做对照。通过 trace 连续性、错误率、属性覆盖、延迟和成本门槛后，再按语言和依赖拓扑扩展。出现问题时按服务关闭双写或回退入口，不回滚整个 Collector 平台。”
分步骤深入解答
1. 盘点调用与语义
建立服务、语言、OpenTracing 包、shim 版本、传播格式和导出路径清单。标记自定义 tag、log、baggage 和 span 命名，逐项映射到 OpenTelemetry attributes、events、links 和 baggage。先处理边界清晰的无状态服务，避免从最复杂的自定义 tracer 开始。
2. 设计兼容边界
让应用逐步依赖 OpenTelemetry 原生 tracer；对暂时不能修改的库保留 OpenTracing shim，但禁止新增 shim 特性。Context propagation 必须在入口、异步队列、RPC 和批处理边界保持一致；不得因为 API 名称相似就假设采样和 parent 关系相同。
3. 选择双写位置
优先在 SDK 或 Collector 出口做可控分流，而不是让每个业务代码生成两套 span。若确实要双写，给每个服务设置采样上限、队列容量、重试和丢弃指标，并区分“业务 span 未生成”和“导出失败”。双写窗口应有明确结束条件。
4. 保持后端可查询
迁移期间固定 service、operation、status 和关键业务属性的命名。用同一组请求同时比较旧链路和新链路的 trace 数量、父子关系、错误状态、延迟分位数和 exemplars。若后端查询语义变化，先提供查询适配或仪表盘双版本，再切换默认视图。
5. 灰度与成本护栏
按语言、团队或依赖树逐批迁移。灰度看端到端 trace 连续率、span 丢失率、Collector 队列、CPU/内存、出口流量和每百万 span 成本。任何指标超阈值只停止新服务进入，保留已迁移服务和原始证据。
6. 回滚和生命周期
为每个服务保留 tracer 初始化开关、依赖版本和配置快照。回滚只切换该服务的入口或导出路由，避免删除共享 Collector 中的资源。迁移完成后删除 shim 依赖前，先确认没有下游库仍通过全局 tracer 获取上下文，并保留一段时间的兼容监控。
高质量示范回答
我会先冻结新增 OpenTracing 兼容开发，建立调用、语义、传播和导出清单。原生 OpenTelemetry API 逐服务接入，暂时不能修改的库继续经 shim 运行；Context、采样和属性映射用契约测试固定。双写只在 SDK/出口做限额分流，观察 trace 连续性、属性覆盖、Collector 队列、延迟和成本。按语言和依赖拓扑灰度，失败时关闭单服务的新路径并恢复旧出口，保留配置、事件和对照数据；全部服务稳定后才删除 shim。
常见错误
- 只替换 import → parent、baggage 或属性语义改变 → 用传播和语义契约测试验证。
- 每处业务代码双写 → span 数量与成本失控 → 在 SDK/出口集中分流并限额。
- 只看 Collector 成功率 → 应用端已丢 span → 区分生成、排队、导出和后端落库指标。
- 一次迁移所有服务 → 故障域过大 → 按语言和依赖拓扑灰度。
- 立即删除 shim → 未迁移库无法启动 → 先冻结新增依赖，确认引用清零再删除。
追问及应对
为什么不能要求所有团队同时改成原生 API？
共享库、发布节奏和语言 SDK 不同会造成大爆炸半径。分层兼容允许业务连续运行，同时把新能力集中到原生 API。
如何证明没有丢失 trace？
用可重复请求注入稳定标识，比较入口、服务间传播、Collector 接收和后端查询的计数，并抽样核对 parent、status 和关键属性。
双写会不会改变采样结果？
会。两个 tracer 若各自采样，链路可能断裂或成本翻倍。应在共享上下文中决定采样，并让分流继承同一决定。
什么时候可以删除兼容层？
当依赖扫描确认没有 OpenTracing 入口，契约测试覆盖传播与语义，灰度指标达到门槛，且保留窗口内无回退事件时，再删除并保留配置审计。