摘要

  • 2019 年 5 月的合并说明直言，OpenTracing 和 OpenCensus 最大的问题是有两套相近但不协同的方案。负责人把兼容桥列为首要工作，并计划在 2019 年底前让旧项目进入只读状态。
  • OpenTelemetry 2023 年 5 月的公告称，OpenCensus 在七种语言上已达到功能对齐，多数仓库计划于 7 月 31 日归档；仍有生产用途的 opencensus-python 被明确列为例外。

两套方案，让所有人重复接线

要看懂一套分布式服务内部出了什么事，应用和依赖库必须把请求轨迹、指标或日志记录下来，再送到能分析的地方。OpenTracing 和 OpenCensus 各自试图把这项工作变成公共基础设施，免得每个团队都重做一遍。它们的技术选择不同，争取的却是同一批库维护者和使用者。一个底层库该接哪套接口？同时接两套吗？还是等争论结束？这些选择最后都会进入运行中的服务。

Ben Sigelman 与 Morgan McLean 在 2019 年写的项目说明没有把问题包装成新功能发布。他们说，两项计划最大的麻烦，恰恰是有两项计划。如果库维护者和运维团队把时间花在保持两套埋点路径可用，所谓共享成本就又被拆成了重复成本。分布式追踪的价值在于连起一次请求经过的各层；其中一层选了另一条不兼容的接线，整条链就要靠额外工作拼回来。

合并把新工作放进 CNCF 旗下一个项目，初期治理和技术委员会包含 Google、LightStep、Microsoft 和 Uber 的代表。这个安排可以决定今后往哪里提交规范与代码，却不能当晚替换已部署服务的依赖。负责人把 OpenTelemetry 描述为两个旧项目共同的下一代主版本。既然是“下一代”，就得交代现有用户如何过渡，而不是只在会议上宣布旧名字退役。

兼容桥从第一天就在图纸上

2019 年公告把向后兼容列为合并优先事项：通过软件桥接，让原有 OpenTracing 和 OpenCensus 埋点逐步迁入新系统。另一个目标是缩短三套项目并行开发的时间，计划在年底前把两套旧项目转为只读。这里的“只读”是当时提出的项目目标，不是所有生产环境在 2019 年完成迁移的证据。

仓库停止增加功能，服务却可能继续每分钟加载旧库、发出数据。中间还有 SDK 发布、依赖升级、采集器连接和图表指标连续性。兼容桥不是几年后才补上的借口，而是合并设计的一部分。负责人知道项目组织可以统一，运行中的代码却要逐段替换。

CNCF 2021 年 8 月的孵化公告展示了新项目进展：当时已有十一种语言的 API 和 SDK，其协议支持追踪与指标。公告同时说，OpenTracing 将正式归档，两项旧计划还要进一步弃用。合并过去两年，基金会仍把旧系统退场写成接下来的工作。这比“统一已经完成”的漂亮句子更贴近运行事实。

2023 年的清单上有一行不能划掉

OpenTelemetry 在 2023 年 5 月公布的 OpenCensus 退场通知列出了具体边界。项目称 C++、.NET、Go、Java、JavaScript、PHP、Python 七种语言已达到 OpenCensus 功能对齐，计划在 7 月 31 日归档绝大多数 OpenCensus GitHub 仓库。opencensus-python 没有被一并打包，因为其中若干项目仍是推荐的生产方案。合并图上的一条箭头，到了执行阶段变成了需要逐项核对的清单。

通知列出 Go、Java、JavaScript 和 Python 的兼容桥，也说明部分适配包尚待发布。建议的次序是：让老埋点先经由桥把数据送进 OpenTelemetry 的出口，再逐步移除旧库。项目还提醒，OpenTelemetry 并非 OpenCensus 的严格超集；迁移可能改变输出数据。曲线还在动，不代表标签和含义还与旧图完全相同。

归档计划也划定维护责任。公告称，7 月 31 日后归档的 OpenCensus 项目不会再有新功能和安全修补；源码和既有包仍可下载。一个企业完全可能继续下载并运行无人维护的旧库。是否这样做是其自己的决定，不能由“仓库还能打开”来替代风险判断。

委员会先合并，服务随后搬家

2019 年的协议解决了未来共同工作该投向哪里的争执。库作者和工具提供者终于可以围绕同一个项目建设。但现有服务还有版本周期、语言实现、桥接质量和上下游依赖。2019 年合并到 2023 年退场通知之间的四年，记录的正是这部分搬迁成本。它本身不能证明 2019 年“只读”目标失效，因为只读和归档不是同一个动作；它说明项目到 2023 年仍需要一份带着桥和例外的退出说明。门牌很早就换了，电缆得一根根穿过新门。