Dapr 可观测性之分布式追踪

在构建应用程序时，了解系统的行为方式是运维它的重要部分——这包括能够观察应用程序的内部调用、衡量其性能并在问题发生时能够立即找到问题。这对任何系统来说都是具有挑战性的，对于由多个微服务组成的分布式系统更是如此，其中由多个调用组成的流可能在一个微服务中开始，但在另一个微服务中继续调用。可观测性在生产环境中至关重要，在开发过程中对于了解瓶颈、提高性能和跨微服务执行基本调试也很有用。

虽然可以从底层基础架构中收集有关应用程序的一些数据（例如内存消耗、CPU 使用情况），但必须从 应用程序感知 层收集其他有意义的信息——该层可以显示如何执行一系列重要的调用跨微服务。这通常意味着开发人员必须为此添加一些代码来检测应用程序。通常，检测代码只是将收集到的数据（例如追踪和指标）发送到外部监控工具或服务，以帮助存储、可视化和分析这些信息。

由于这部分代码并不是应用程序的核心逻辑，所以这自然成为了开发人员的另一个负担，有时需要了解监控工具的 API，使用额外的 SDK 等。这种工具也可能会增加应用程序的可移植性挑战。应用程序可能需要不同的工具，具体取决于应用程序的部署环境。例如，不同的云提供商提供不同的监控解决方案，本地部署可能需要本地解决方案。

用于获得可观测性的系统信息被称为 telemetry（遥测） ，它可以分为四大类。

1. Distributed tracing（分布式追踪）提供了对参与分布式业务通信的服务之间流量的洞察力。

2. Metrics（指标）提供了对服务性能及其资源消耗的洞察力。

3. Logging（日志）提供了对代码如何执行以及是否发生错误的洞察力。

4. Health（健康）端点提供了对服务可用性的洞察力。

Dapr 可观测性构件将可观测性与应用解耦，它自动捕捉由构成 Dapr 控制平面的 Dapr sidecar 和 Dapr 系统服务产生的流量。该模块将跨越多个服务的单个操作的流量进行关联。它还暴露了性能指标、资源利用率和系统的健康状况。遥测数据以开放标准的格式发布，使信息能够被输入你选择的监控后端。在那里，这些信息可以被可视化、查询和分析。

由于 Dapr 进行了抽象，所以应用程序不知道可观测性是如何实现的。不需要开发者关心如何去实现这部分与核心业务逻辑无关的代码，Dapr 允许开发者专注于构建业务逻辑，而不是观察能力的建设。观察力是在 Dapr 系统层面上配置的，并且在不同的服务中是一致的，即使是由不同的团队创建，并使用不同的技术栈构建。

如何工作

Dapr 的 sidecar 架构实现了内置的可观测性功能，当服务进行通信时，Dapr sidecars 拦截流量并提取追踪、指标和日志信息，遥测数据以开放标准格式进行发布，默认 Dapr 支持 OpenTelemetry 和 Zipkin。

Dapr 提供 collectors 收集器，可以将遥测数据发布到不同的后端监控工具，这些工具将 Dapr 遥测数据呈现出来，用于分析和查询。图 10-1 显示了 Dapr 的可观察性架构。

dapr observability 架构

• 服务 A 调用服务 B 的一个操作，该调用从服务 A 的 Dapr sidecar 被路由到服务 B 的 sidecar。

• 当服务 B 完成操作时，响应会通过 Dapr sidecar 被送回服务 A。它们收集并发布每个请求和响应的所有可用遥测数据。

• 配置的收集器摄取遥测数据并将其发送到监控后端。

不过需要注意的是添加可观测性的支持不同于配置其他 Dapr 构建块，比如前面我们介绍的发布订阅或者状态管理这些组件，我们不需要引用构建块了，而是添加收集器和监控后端，上图显示我们可以配置多个与不同监控后端集成的收集器。

下面我们来分别对可观测性的几个遥测类型进行说明。

分布式追踪

分布式追踪提供了对分布式应用中跨服务流动流量的洞察力。交换的请求和响应信息的日志是排除问题的重要信息来源，比较困难的是把属于同一业务事务的消息整合起来。

Dapr 使用 W3C Trace Context 这个统一的标准来关联相关信息，它将相同的上下文信息注入到一次完整的请求和响应中。

W3C Trace Context 示例

上图显示了一个 W3C Trace Context 标准的示例：

• 服务 A 调用服务 B 上的操作。当服务 A 开始调用时࿰