分布式跟踪

1 分布式调试

1.1 存在的问题

服务的分布式特性意味着你必须跨多个服务，物理机器和不同的数据存储来跟踪一个或多个交易， 所以试图调试问题发生的地方会令人发狂。

1.2 使分布式调试成为可能的方法和技术

方法：

1. 使用关联 ID 将多个服务之间的交易链接在一起。
2. 可视化跨多个服务的用户交易流程，并了解交易每个部分的性能特点。

对应的技术：

1. Spring Cloud Sleuth ：Spring Cloud Sleuth 是一个 Spring Cloud 项目，它使用关联 ID 处理 HTTP 调用，并提供将生成的跟踪数据提供给 OpenZipkin 的钩子。它通过添加过滤器并与其他Spring 组件进行交互来完成此操作，以便将生成的关联 ID 传递到所有系统调用。
2. Zipkin ：Zipkin 是一个开源的数据可视化工具，可以显示跨多个服务的交易流程。Zipkin 允许你将交易分解成组件，并以可视方式识别可能存在性能热点的地方。

2 示例项目

我们通过一个简单的项目来说明如何使用Spring Cloud Sleuth等技术，该项目中包含两个服务，许可证服务（licence service）和组织服务（organization service）。

 

 

注意：查询许可证是一个跨服务的请求（如下图所示）。

 

 

3 Spring Cloud Sleuth 和关联 ID

3.1 关联ID

关联 ID 是一个随机生成的唯一编号或字符串，在交易启动时分配给一个交易。由于交易流经多个服务，关联 ID 从一个服务调用传递到另一个服务调用。

3.2 添加Spring Cloud Sleuth依赖

要在两个服务（许可证和组织）中使用 Spring Cloud Sleuth，你只需要在两个 服务中的 pom.xml 文件中添加一个 Maven 依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>

添加了依赖之后，Spring Cloud Sleuth会自动为HTTP请求创建和传递关联ID，并将关联ID写入日志中。

3.3 分析 Spring Cloud Sleuth Trace

我们在组织服务上执行HTTP GET请求 http://localhost:5555/api/organization/v1/organizations/442adb6e-fa58-47f3-9ca2-ed1fecdfe86c，Spring Cloud Sleuth为每个日志条目添加了5条跟踪信息（如下图所示），这些数据有助于将用户请求的服务调用绑定在一起。

 

                                                                      

应用程序名称	正在记录的服务的名称。
跟踪ID	用户请求的唯一标识符，将在该请求中的所有服务调用中携带。
跨度ID	整个用户请求中的单个段的唯一标识符。对于多业务调用，用户交易中每个服务调用将有一个 span id。
父跨度ID	可选的id，当前跨度的父跨度 id
发送到 Zipkin	标志表示是否将数据发送到 Zipkin 服务器进行跟踪。

到现在为止，我们只查看了单个服务调用产生的日志数据。让我们来看看在通过GET  http://localhost:5555/api/licensing/v1/organizations/e254f8cc442-4ebe-a82a-e2fc1d1ff78a/licenses/f3831f8c-c338-4ebe-a82a-e2fc1d1ff78a 调用许可证服务时会发生什么。请记住，许可证服务还必须向组织服务发出调用。下图显示了两个服务调用的日志输出。

 

 

 

可以看出许可证服务和组织服务具有相同的跟踪 ID和不同的跨度 ID。