分布式跟踪系统(SpringCloudSluth+OpenZipkin)

当我们构建一个微服务体系结构，并且服务的数量不断增加时，我们面临着在整个系统中调试和跟踪请求的问题。当用户在请求中出现500错误时，会发生什么情况？是什么部门不正确地处理了他的请求？所有这些问题都可以通过分布式跟踪系统来解决。我们走吧春云探测举个例子。

春云探测是如何工作的

为了通过分布式系统跟踪请求，引入了TraceID和SpanID的概念。当请求进入我们的系统并在整个路径中保持不变时，将生成TraceID。当请求从一个服务传递到另一个服务时，SpanID会发生更改。如果有必要，可以在一个服务中生成新的跨度，以区分业务流程。

在HTTP报头中，跟踪和跨系统之间传递。其中一个标准是B3传播，它描述分布式跟踪系统的头格式。上下文通过窗体的标头从一个服务传递到另一个服务。X-B3-*。在接收到具有此类头的请求之后，我们可以恢复跟踪上下文并继续执行流程。

Sluth的优点是它使用拦截器自动向所有请求(例如RestTemplate或假象)注入必要的标头。要使其自动工作，需要将HTTP客户端声明为Springbean。

让我们考虑由3个微服务组成的以下体系结构：

1. 用户注册服务
2. 负责忠诚度计划的服务
3. 向用户发送通知的服务

在这个示例中，让我们看看如何将SpringCloudSluth连接到SpringBoot应用程序。我们将使用假名作为HTTP客户端。在创建了一个Gradle项目之后，我们将向每个服务添加依赖项：sluth，这个库用于将数据发送到齐普金并冒充客户，使我们可以向其他服务提出要求。

用户服务

Build.gradle：

ext {
    set('springCloudVersion', "2021.0.0")
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.cloud:spring-cloud-starter-sleuth'
    implem