查看本文大纲

在云原生环境中，提升对应用程序的可观测性以更好地理解用户体验是至关重要的。然而，单纯依靠指标和日志无法提供个别案例的具体细节。这时，追踪（Tracing）技术就显得尤为重要。

追踪的基本原理

追踪通过为每个用户请求附加一个关联 ID，向开发人员提供完整的用户体验上下文。这个关联 ID 就像一根线，将跨越多个服务的追踪串联起来，从而实现全面的可观测性。

下图展示了 Envoy 处理用户请求的流程。

追踪可以通过为每个用户请求附加一个关联 ID，向开发人员提供完整的用户体验上下文。这个关联 ID 就像一根线，将跨越多个服务的追踪串联起来。

尽管所有请求都会经过 Envoy 代理，但 Envoy 无法独立提供完整的追踪信息。它只看到应用程序作为网络的一部分，无法洞察内部处理。这使得 Envoy 无法区分入站请求和出站请求是否来自同一个用户，因此无法自动转发追踪上下文。

服务网格中的请求上下文

Envoy 可以在 Istio 服务网格中作为 Sidecar 或 Waypoint 代理，下图展示了 Envoy 在服务网格中如何处理请求上下文的。

1. 用户请求的开始

追踪涉及通过多个服务跟踪路径，以理解用户体验的完整上下文。追踪从一个用户请求开始，该请求被分配了一个关联 ID。

2. 请求通过 Envoy 代理

Envoy 位于应用程序旁边，所有进入的请求都会经过 Envoy。

3. Envoy 附加额外的 Headers

Envoy 可以在请求中附加额外的 Headers，以收集关于应用程序内部发生情况的信息。

4. 应用程序处理请求并调用后端服务

应用程序在处理请求的过程中，可能需要联系其他系统来处理该请求。比如外部的认证和授权服务。

5. 应用程序需要复制关联 ID

应用程序知道出站请求是代表哪个入站请求发起的（例如 Trace ID 为 1234 的请求）。但是，Envoy 并不知道这一点。因此，应用程序需要将关联 ID 等上下文从入站请求复制到出站请求中。

6. 多个请求的并发处理

在实际场景中，应用程序同时处理多个用户请求，这导致了并发性。由于 Envoy 只能看到网络层面的请求和响应，无法区分这些请求之间的因果关系。

7. Envoy 的局限性

因为 Envoy 无法看到应用程序内部的处理逻辑，它只能看到一系列的网络请求和响应，无法知道哪些出站请求是由哪些入站请求触发的。

需要应用程序的参与

由于 Envoy 无法自动转发追踪上下文，应用程序本身需要负责将入站请求的 Headers 复制到出站请求中，以保持追踪信息的完整性。

应用程序复制 Headers

应用程序在处理入站请求时，需要将必要的 Headers（如关联 ID、用户身份等）复制到任何出站请求中。

响应返回给用户

应用程序完成对用户请求的处理后，将响应返回给用户。

解决方案与推荐

为了确保追踪信息的完整性，应用程序需要主动复制和传递追踪相关的 Headers。这可以通过集成如 Apache SkyWalking 的工具来实现，SkyWalking 不仅支持分布式追踪，还包括性能监控、日志分析等功能。利用 SkyWalking 的库和代理，可以简化 Headers 的复制和追踪信息的传递。

关于如何在 Istio 中使用 SkyWalking 实现分布式追踪详见这篇博客。

总结

• 追踪的重要性：追踪为开发人员提供了用户请求的完整上下文，帮助更好地理解和改进用户体验。
• Envoy 的局限性：Envoy 只能看到网络层面的请求和响应，无法跟踪请求的因果关系，因此无法自动转发追踪上下文。
• 应用程序的角色：应用程序需要主动复制和传递追踪相关的 Headers，以确保追踪信息的完整性。
• 推荐的工具：使用 SkyWalking 等追踪工具的库，可以简化在应用程序中实现 Headers 复制的过程。

参考

• How the Envoy proxy handles a user request - tetrate.io
• 如何在 Istio 中使用 SkyWalking 进行分布式追踪？- jimmysong.io