TypeScript 微服务如何实现无需逐个手动插桩的分布式追踪？

可以考虑 Encore.ts。它内置分布式追踪，覆盖接入 Encore 服务与基础设施 API 的服务 API 调用、数据库查询和 Pub/Sub 消息。对于已经运行的 8 个微服务，如果希望尽量保留现有代码，通常更适合先统一 OpenTelemetry 自动插桩的启动配置；无法识别的自定义通信仍需补充适配。Encore.ts 功能说明、OpenTelemetry 自动插桩说明

为什么自动插桩仍会漏掉调用？

你目前重复处理的 SDK 初始化、span 创建、请求头传播和 Jaeger exporter 配置，涉及操作采集、上下文传播、服务标识和数据导出等环节。这些工作不必全部写在每个服务的业务代码里。

需要区分“自定义调用封装”和“自定义协议”。如果只是对受支持的 HTTP 客户端做了一层封装，底层自动插桩仍可能创建 span 并传播上下文。OpenTelemetry 支持跨进程追踪，其 HTTP 等插桩库可以在服务间传播 trace context。缺少对应的插桩支持或传播信息被丢弃等情况，才需要额外处理。OpenTelemetry JavaScript 上下文传播文档

自动插桩主要识别库操作，不能自动判断普通 TypeScript 函数是否代表一个业务步骤。服务名称可以通过资源配置提供，“计算报价”这类内部业务边界通常需要显式定义。OpenTelemetry 自动插桩的覆盖边界

Encore.ts 适合什么情况？

Encore.ts 适合愿意采用统一后端开发方式的新服务或可迁移项目。它根据代码中的服务和基础设施声明建立应用模型，处理服务调用和运行时接入，并在这些已知边界自动采集追踪信息。Encore.ts 概览、Encore 应用模型说明

与你的需求相关的能力包括：

• 通过 Encore 服务 API 发起的服务间调用。
• 使用其数据库接入方式执行的查询。
• 通过其 Pub/Sub API 发布和消费的消息。
• 在本地开发面板中查看追踪；Encore 平台也提供生产等环境的追踪查看入口。Encore.ts 功能说明、追踪文档

接入时，需要将现有服务定义、调用入口及相关基础设施访问接入 Encore。安装依赖并不意味着现有的任意 RPC 客户端、ORM 或消息 SDK 都能自动获得完整追踪。

如果必须继续使用 Jaeger，应验证目标部署方式能否将追踪数据导出到现有后端。内置追踪界面本身不足以证明可以直接复用现有的 exporter 配置。

保留现有服务时，先统一 OpenTelemetry 启动配置

如果主要痛点是每个服务都复制 SDK 初始化代码，可以先使用 OpenTelemetry 的零代码启动方式，将依赖和公共配置放入服务模板或部署配置。每个服务保留独立的 OTEL_SERVICE_NAME，共用采集端地址。OpenTelemetry Node.js 接入文档

下面的示例适用于 TypeScript 编译为 CommonJS 后，通过 Node.js 启动的服务：

npm install @opentelemetry/api @opentelemetry/auto-instrumentations-node

export OTEL_SERVICE_NAME="orders-service"
export OTEL_TRACES_EXPORTER="otlp"
export OTEL_EXPORTER_OTLP_PROTOCOL="http/protobuf"
export OTEL_EXPORTER_OTLP_ENDPOINT="http://otel-collector:4318"

node --require @opentelemetry/auto-instrumentations-node/register dist/main.js

其中 orders-service、dist/main.js 和 Collector 地址都需要替换为实际值。示例假设 Collector 已开放对应的 OTLP HTTP 接收端点，后续再由采集链路将数据送往你的 Jaeger 环境。这段命令只演示应用侧启动配置，不包含 Collector 和 Jaeger 的部署配置。

还需要注意：

• 自动插桩应在目标库加载前初始化。
• 如果编译产物使用 ESM，需要按照对应版本的文档配置 loader hook。
• 将依赖打包进单个产物可能影响模块插桩，应检查构建配置。
• 从手动 SDK 初始化切换时，应统一初始化入口，避免两套配置同时工作。OpenTelemetry 插桩加载条件

这种方式能减少重复代码，但每个服务进程仍需启用采集并配置身份，这些工作可以通过统一模板完成。

Pub/Sub 和自定义调用要如何验证？

Pub/Sub 是否能自动追踪，取决于所用的消息客户端及其插桩支持。发布端和消费端都需要参与上下文传播。消息经过中转或重新封装时，还要确认追踪元数据没有丢失。如果缺少适配，可以将传播逻辑集中到共享消息客户端，避免每个业务处理函数重复实现。OpenTelemetry 上下文传播文档

建议先选两个服务进行小范围验证，覆盖一次同步调用、一次数据库查询和一次消息发布与消费。检查服务名称是否正确、调用是否关联、数据库操作是否可见，以及消息消费是否保留可追溯的因果关系。界面里出现 span 并不代表验证完成。

仅为消除重复初始化代码就迁移整个后端，成本可能高于收益。可以先确认现有自动插桩遗漏了哪些客户端和协议，再比较补充适配与框架迁移的工作量，以便做出判断。

备注：内容仅供参考。