ASP.NET Core整合Zipkin链路跟踪的实现方法

前言：

在ASP.NET Core的应用中，链路跟踪是确保系统稳定性和性能的关键部分。虽然SkyAPM是一个不错的选择，但今天我们将聚焦于另一个强大的链路跟踪系统——Zipkin。Zipkin以其轻量级和原生支持的特性，为ASP.NET Core开发者提供了另一种解决方案。接下来，让我们一起如何在ASP.NET Core中整合Zipkin链路跟踪。

Zipkin简介：

Zipkin是一个由Twitter开源的分布式实时数据追踪系统，主要用于收集和分析系统实时监控数据。它通过上报端将Trace数据上报到Collector端，然后保存到内存或外部存储系统中，供UI展示。Zipkin的架构清晰，主要包括上报端、Collector、存储端和UI。其中，上报端集成到程序中，用于上报Trace数据；Collector负责接收数据并存储；UI则负责展示采集的链路数据。

在理解Zipkin之前，我们需要知道一些链路跟踪相关的概念，如TranceId、SpanId等。TranceId代表一次全局的请求，用于串联整个链路。而SpanId则代表链路中的每一个子请求。为了准确记录链路数据，我们还需要记录请求在网络上的耗时、服务端处理请求的耗时等信息。

部署Zipkin：

Zipkin的部署相对简单，常用的部署方式有两种：一种是下载安装JDK后运行zipkin.jar的方式，另一种是基于Docker的方式。为了简化操作，我们通常采用Docker方式部署Zipkin。在实际使用中，我们通常会选择使用ElasticSearch等外部存储系统来存储链路数据，因为内存存储的方式并不实用。

ASP.NET Core整合Zipkin：

整合Zipkin到ASP.NET Core应用中，首先需要引入相关的Zipkin库。然后，我们需要在程序的入口点（如Main方法或Startup类）中初始化Zipkin客户端，并配置相应的采集参数。接着，我们需要在需要追踪的方法或API调用前后，手动创建和结束Span。这样可以确保每一个请求都被正确地追踪和记录。

为了更好地展示链路数据，我们还需要配置Zipkin UI。通过访问Zipkin的UI界面，我们可以直观地查看链路数据，包括请求的处理时间、系统间的依赖关系等。这有助于我们快速定位系统中的瓶颈，优化系统性能。

通过本文，我们了解了Zipkin的基本概念、部署方式和如何在ASP.NET Core中整合Zipkin链路跟踪。Zipkin作为一种轻量级的链路跟踪系统，为ASP.NET Core开发者提供了另一种选择。通过整合Zipkin，我们可以更好地监控和分析系统的性能，提高系统的稳定性和可靠性。希望本文对你学习和使用Zipkin有所帮助。在数字化时代，分布式系统的监控和追踪变得尤为重要。为了有效追踪服务间的调用链路并解决潜在问题，我们依赖Zipkin和ElasticSearch的组合。对于这种部署形式，使用docker-compose的方式无疑是最佳选择。

你可以在Zipkin官方Github仓库中找到docker的部署方式。虽然官方提供的方式相对复杂，但我对其进行了简化，以下是简化后的docker-compose配置文件。

version: "3.6"

Elasticsearch服务配置：

我们使用Elasticsearch 7.5.0版本。通过docker镜像，我们部署了一个名为“elasticsearch”的容器。该容器在启动时总是自动重启，并且我们暴露了其端口（9200）。我们为Elasticsearch设置了特定的环境变量以满足其内存和配置要求。

```yaml

services:

elasticsearch:

image: elasticsearch:7.5.0

container_name: elasticsearch

restart: always

ports:

- 9200:9200

environment:

- discovery.type=single-node

- bootstrap.memory_lock=true

- "ES_JAVA_OPTS=-Xms512m -Xmx512m"

ulimits:

memlock:

soft: -1

hard: -1

```

Zipkin服务配置：

我们同样使用docker镜像部署Zipkin服务，并将其连接到Elasticsearch。通过环境变量设置，我们指定了存储类型为Elasticsearch并设置了Elasticsearch的地址。我们还设置了端口并依赖于Elasticsearch服务，确保在Elasticsearch启动后再启动Zipkin。

```yaml

zipkin:

image: openzipkin/zipkin

container_name: zipkin

restart: always

environment:

- STORAGE_TYPE=elasticsearch

- ES_HOSTS=elasticsearch:9200

ports:

- 9411:9411

depends_on:

- elasticsearch

```

通过运行编辑后的docker-compose文件，你可以一键启动所有服务。当Zipkin成功启动并在浏览器中显示相应的界面时，表示整合成功。你可以开始将程序中的数据采集到Zipkin中进行分析和监控。

为了展示Zipkin的使用场景，我新建了两个ASP.NET Core程序：OrderApi和ProductApi。在这两个项目中，我们引入了Zipkin的依赖包，以便进行分布式追踪。其中，"zipkin4"是核心包，"zipkin4.middleware.aspcore"是用于集成ASP.NET Core的程序包。通过引入这些包，我们可以轻松地将数据发送到Zipkin进行追踪和分析。这样，在分布式系统中，我们可以清晰地看到服务间的调用链路，从而更好地解决潜在问题并提高系统的稳定性和性能。在Startup文件中，我们添加了一个名为RegisterZipkinTrace的方法，用于集成Zipkin跟踪服务。这个方法接收三个参数：IApplicationBuilder对象app，用于构建应用程序的请求管道；ILoggerFactory对象loggerFactory，用于创建日志记录器；以及IHostApplicationLifetime对象lifetime，用于监听应用程序的生命周期事件。

在RegisterZipkinTrace方法内部，我们首先注册了一个应用程序启动后的操作。当应用程序启动时，我们会执行一系列操作来配置Zipkin跟踪。我们设置采样率为1.0，意味着我们将记录所有的跟踪数据。然后，我们创建一个用于记录链路日志的日志记录器，并指定使用zipkin4作为日志名称。接下来，我们定义了一个HttpZipkinSender对象，用于向Zipkin服务发送跟踪数据，并指定了Zipkin服务的地址和内容的类型。然后，我们创建了一个ZipkinTracer对象和一个ConsoleTracer对象，并将它们注册到TraceManager中。我们启动TraceManager并开始记录跟踪数据。

为了在应用程序停止时停止链路跟踪，我们还注册了一个应用程序关闭后的操作。当应用程序关闭时，我们将调用TraceManager的Stop方法来停止跟踪。

我们在Configure方法中调用RegisterZipkinTrace方法，以启用Zipkin跟踪服务。通过这种方式，我们可以轻松地集成Zipkin跟踪到我们的应用程序中，并实时监控服务请求。通过这种方式，我们可以更好地了解我们的应用程序在运行时的情况，并对其进行优化和改进。我们还可以使用Zipkin来跟踪和分析分布式系统中的请求流程，从而更好地理解和优化系统的性能。

通过添加RegisterZipkinTrace方法并在Configure方法中调用它，我们可以轻松地集成Zipkin跟踪服务到我们的应用程序中，并实时监控服务请求，从而更好地了解系统的运行情况并进行优化和改进。在OrderApi项目中，我们将采用HttpClient的方式调用ProductAPI。由于zipkin4默认支持采集HttpClient发出的请求链路数据，我们将利用这一特性进行集成。对于使用HttpClientFactory的方式，我们在ConfigureServices中的配置如下：

```csharp

public void ConfigureServices(IServiceCollection services)

{

// 引入Nacos作为服务注册中心

services.AddNacosAspNetCore(Configuration);

services.AddScoped();

// 针对ProductService配置HttpClient

services.AddHttpClient(ServiceName.ProductService, client =>

{

client.BaseAddress = new Uri($"

})

.AddHttpMessageHandler()

// 引入zipkin trace跟踪httpclient请求，配置当前服务名称为跟踪名称

.AddHttpMessageHandler(provider => TracingHandler.WithoutInnerHandler(Configuration["nacos:ServiceName"]));

// 添加Controllers

services.AddControllers();

}

```

若直接使用HttpClient的形式调用，可以采用如下方式：

```csharp

using (HttpClient client = new HttpClient(new TracingHandler("OrderApi")))

{

// 使用client进行API调用

}

```

```csharp

[Route("orderapi/[controller]")]

public class OrderController : ControllerBase

{

private readonly List orderDtos;

private readonly IHttpClientFactory _clientFactory;

public OrderController(IHttpClientFactory clientFactory)

{

orderDtos = new List { new OrderDto { Id = 1, TotalMoney = 222, Address = "北京市", Addressee = "me", From = "淘宝", SendAddress = "武汉" } };

_clientFactory = clientFactory;

}

///

获取订单详情接口

/// 订单id

///

[HttpGet("getdetails/{id}")]

public async Task GetOrderDetailsAsync(long id)

{

var orderDto = orderDtos.FirstOrDefault(i => i.Id == id);

if (orderDto != null)

{

var orderDetailDto = new OrderDetailDto

{

Id = orderDto.Id,

TotalMoney = orderDto.TotalMoney,

Address = orderDto.Address,

Addressee = orderDto.Addressee,

From = orderDto.From,

SendAddress = orderDto.SendAddress

};

// 使用_clientFactory创建的client调用ProductApi服务接口

var client = _clientFactory.CreateClient(ServiceName.ProductService);

var response = await client.GetAsync($"/productapi/product/getall");

var result = await response.Content.ReadAsStringAsync();

orderDetailDto.Products = JsonConvert.DeserializeObject>(result); //反序列化结果到Products列表属性中。如果服务端返回的数据格式不同，这里需要进行相应的调整。同时服务端也需要进行相应的配置来接收并处理这个请求。如果在服务端有处理日志、错误追踪等功能的话，那么在服务端同样也需要集成zipkin。此外在服务端也要保证能够正确请求并返回期望的数据格式和内容。否则客户端可能无法正确返回的数据，从而导致错误或异常。服务端需要实现对应的API接口并提供必要的数据。在这个例子中我们假设服务端能够正确地响应请求并返回期望的数据格式和内容。如果服务端无法正确响应请求或者返回的数据格式和内容不符合预期的话，那么客户端将无法正确返回的数据并可能抛出异常或产生错误结果。因此在实际应用中需要确保服务端和客户端之间的数据交互是正确无误的。同时服务端也需要进行相应的配置来接收并处理这个请求，确保能够正确地响应客户端的请求并返回期望的数据格式和内容。因此在实际应用中需要注意服务端和客户端之间的协同工作以确保系统的稳定性和可靠性。另外在服务端也需要进行必要的错误处理和日志记录以便于在出现问题时能够及时定位和解决问题。这一点同样非常重要以确保整个系统的健壮性和稳定性。在这种情况下我们通常会采用分布式追踪系统如Zipkin来追踪请求的处理过程以便于定位和解决问题。在这种情况下我们需要在服务端也集成Zipkin以便于追踪请求的处理过程。然后我们可以将处理过程中产生的追踪信息通过Zipkin进行收集和分析以便于我们分析和解决可能出现的问题。这样我们就可以通过追踪信息来了解请求的处理过程以及可能出现的问题从而帮助我们更好地优化和改进系统的性能和质量。总的来说在实现分布式系统时需要同时考虑客户端和服务端的协同工作以确保系统的稳定性和可靠性同时还需要关注错误处理和日志记录等方面以便于在出现问题时能够及时定位和解决问题从而保障整个系统的健壮性和优化与简化 ProductApi 的设计：摒弃集成 HttpClient 的繁琐，追求简洁之美

在产品 API 的设计领域，有时候并不需要过度复杂的集成与调用。对于 ProductApi，由于其不依赖其他服务调用，我们可以选择简化设计，无需集成 HttpClient。

代码实现上，我们可以采取如下的方式定义一个简洁的产品控制器。它使用内置的数据存储机制来存储产品信息，并直接通过简单的接口提供数据。

```csharp

[Route("productapi/[controller]")]

public class ProductController : ControllerBase

{

private List productDtos = new List(); // 存储产品信息的列表

// 在构造函数中初始化产品信息

public ProductController()

{

productDtos.Add(new ProductDto { Id = 1, Name = "酒精", Price = 22.5m });

productDtos.Add(new ProductDto { Id = 2, Name = "84消毒液", Price = 19.9m });

}

///

/// 获取所有商品信息

///

/// 返回所有产品信息列表

[HttpGet("getall")]

public IEnumerable GetAll()

{

return productDtos; // 直接返回存储的产品信息列表

}

}

```

关于链路追踪的改进方案：

在实际应用中，为了进行链路追踪和监控，我们可能需要引入额外的中间件或处理机制来记录请求链路。在某些情况下，尤其是当我们使用第三方库或框架时，很难通过自定义的方式去设置 HttpClient 的相关参数。我们可以考虑以下方案：

让我们聚焦在SendAsync方法上。这个方法的核心作用是发送异步请求并记录链路信息。这个方法首先定义了两个重要的变量：一个是用于获取客户端链路信息的函数_getClientTraceRpc，另一个是用于注入HTTP头信息的IInjector对象_injector。这两个变量在方法中都扮演着重要的角色。

接下来，方法创建了一个ClientTrace对象，这个对象用于记录客户端的链路信息。如果ClientTrace的Trace对象不为空，那么方法会通过_injector对象将链路信息注入到请求的HTTP头中。这样，我们就可以在Zipkin中追踪到这些链路信息。

然后，方法通过调用TracedActionAsync方法来执行发送请求的操作，并记录一些重要的标签信息。这些标签信息包括请求路径、HTTP方法以及一些主机信息。这些信息对于我们在Zipkin链路详情中查看和理解请求的上下文非常有帮助。

实现方式相对简单明了，主要是借助ClientTrace来记录一些标签信息。其他的操作都是由Zipkin4插件提供的。通过深入理解TracingHandler的源码，我们可以更好地利用Zipkin进行链路跟踪和监控。这对于我们理解HttpClient底层的工作机制以及如何对其进行链路跟踪埋点非常有帮助。

我们还可以借鉴HttpClient底层发出诊断日志的思路，来对HttpClient进行链路跟踪埋点。通过这种方式，我们可以更深入地了解系统的运行情况，及时发现并解决潜在的问题。这对于提升系统的稳定性和性能至关重要。

在结合了Microsoft.Extensions.DiagnosticAdapter扩展包之后，我们定义了一个引人注目的类——HttpDiagnosticListener，它继承了ITraceDiagnosticListener接口。这个类为我们提供了一种深入观察和理解HTTP请求、响应以及可能出现异常的方式。

让我们关注这个类的基本属性。HttpDiagnosticListener拥有一个明确的诊断名称“HttpHandlerDiagnosticListener”。它还包括一个ClientTrace对象，以及一个针对HttpHeaders的IInjector。这个IInjector实例用于在需要时注入HTTP头部信息。

当我们面对系统网络HTTP请求时，HttpDiagnosticListener的HttpRequest方法应运而生。它接收一个HttpRequestMessage对象作为参数，然后创建一个新的ClientTrace实例，记录请求的相关信息。如果Trace对象存在，它会将HTTP头部信息注入到当前的Span中。

紧接着，当HTTP响应返回时，HttpResponse方法被触发。这个方法同样会检查Trace对象是否存在，如果存在的话，它会添加一些注解，包括HTTP路径、HTTP方法和主机名等。如果响应的状态码不是成功的，还会将状态码作为注解添加进去。

当发生HTTP请求异常时，HttpException方法将接收请求和异常作为参数。目前这个方法还未实现具体的操作，但可以根据需要添加相关的异常处理逻辑。

至于ITraceDiagnosticListener接口，它就像是一个操作DiagnosticListener的便捷工具。它只有一个DiagnosticName属性，用来表示DiagnosticListener监听的名称。这个接口的引入极大地简化了我们的操作，让我们能够更方便地实现订阅操作。通过这个接口和HttpDiagnosticListener类的结合，我们可以轻松地追踪和诊断HTTP请求和响应的问题，从而提升系统的稳定性和性能。

TraceObserver类：诊断监听器的观察者模式

我们有一个名为TraceObserver的类，它实现了IObserver接口并专门观察DiagnosticListener。此类设计巧妙，为我们处理诊断监听提供了便捷方式。

在TraceObserver的构造函数中，我们传入一个IEnumerable的ITraceDiagnosticListener集合。这些诊断监听器是我们要观察的核心对象。当我们收到新的诊断监听器通知时，我们可以轻松地在这些监听器上执行操作。

对于OnCompleted和OnError方法，我们在此处并未进行任何特定的实现。OnNext方法却大有不同。当新的DiagnosticListener被触发时，我们会检查集合中的诊断监听器是否有与当前监听器名称匹配的项。如果找到匹配的项，我们会使用适配器将其订阅。这样的设计允许我们轻松地扩展其他DiagnosticListener的操作，而无需关心如何将自定义的DiagnosticListener适配到DiagnosticAdapter中。

在服务的注册部分，我们通过AddSingleton方法将TraceObserver和特定的ITraceDiagnosticListener（例如HttpDiagnosticListener）添加到服务集合中。这样的注册方式为我们解决了一些特定问题，比如在封装HttpClient到框架中且无法通过外部程序修改设置时。比如，在引入Ocelot网关的架构中，我们可以采用类似的方式集成zipkin4。

自定义埋点

要理解埋点的实现方式，我们先查看TracingHandler的源码。源码告诉我们，埋点主要是通过ClientTrace进行的，它在发起请求的客户端进行埋点。而在服务端进行埋点的方式则可以通过查看TracingMiddleware中间件的源码得知。通过ServerTrace，我们可以非常轻松地在服务端进行埋点。无论是ClientTrace还是ServerTrace，打上一些标签即可实现完整的客户端和服务端埋点。

TraceObserver类的设计为我们提供了一种便捷的方式来观察和操作诊断监听器。通过自定义埋点，我们能够更好地理解和追踪系统的行为。这样的设计不仅使得代码更加简洁易懂，而且为我们的开发工作带来了极大的便利。无论是在客户端还是服务端，我们都可以轻松地实现埋点，从而更好地监控和诊断系统的运行状态。关于Trace类的封装与Zipkin集成演示

在我们的应用程序中，跟踪服务调用对于监控和诊断问题至关重要。当我们谈论Trace类的封装时，我们实际上是在谈论对跟踪行为的抽象和封装，以便于管理和使用。让我们深入一下这两个类：ClientTrace和ServerTrace。

它们都是对Trace类的封装，继承自BaseStandardTrace类并实现IDisposable接口。这意味着它们封装了跟踪的起始和结束，以及对服务名称、RPC调用等关键信息的记录。

当我们查看源码并深入理解这些类的构造方法和Dispose方法时，我们会发现它们都在关键时刻记录了跟踪信息。例如，ClientTrace在构造函数中记录了客户端发送信息，而在Dispose方法中记录了客户端接收信息。同样，ServerTrace也做了类似的操作。

如果你想以更原始的方式手动记录跟踪日志，你可以直接创建Trace对象并调用其Record方法。这可以让你更灵活地记录跟踪信息，例如添加自定义标签或注解。

为了更好地展示Zipkin的集成方式，我制作了一个简单的Demo。这个Demo包括一个ApiGateway网关项目，它可以转发针对OrderApi的请求。OrderApi和ProductApi模拟了业务系统。这三个项目都集成了Zipkin来进行链路跟踪。它们之间通过Nacos实现服务的注册和发现。

这个Demo不仅展示了Zipkin的基本使用，还展示了如何在ASP.NET Core项目中整合Zipkin。如果你有需要，可以继续深入研究。Zipkin相对于其他工具如Skywalking，更专注于链路跟踪，并且如果以ES作为存储数据库的话，它可能更为轻量级。技术并无好坏之分，选择适合自己的才是最重要的。

Zipkin提供了丰富的链路信息检索、详情展示和链路数据上报形式。而Skywalking作为一款APM工具，功能更为全面，包括应用监控、调用分析等多种功能。但对于只关注链路跟踪的我们来说，Zipkin可能是一个更好的选择。

无论你选择哪种工具，重要的是理解其工作原理，掌握其使用方法，并根据实际需求进行选择。希望这篇文章能给你带来帮助，如果你有任何问题或需要进一步的解释，请随时提问。随着技术的飞速发展，分布式系统变得越来越复杂，链路跟踪成为了解决系统间调用关系的关键技术。ASP.NET Core与Zipkin的整合，为我们提供了一种高效、可靠的方式来追踪系统的链路。本文将深入如何在ASP.NET Core中整合Zipkin链路跟踪，以帮助您更好地理解和优化您的系统。

我们来认识一下Zipkin。Zipkin是一个开源的分布式跟踪系统，它可以帮助收集解决方案中的链路信息，从而帮助您分析系统的性能瓶颈。通过整合Zipkin到ASP.NET Core中，我们可以轻松地追踪请求在系统中的流动路径，从而确保系统的稳定性和可靠性。

接下来，让我们看看如何在ASP.NET Core中实现Zipkin的整合。您需要在项目中安装相关的NuGet包。然后，通过简单的配置，您可以轻松地将Zipkin集成到您的ASP.NET Core应用程序中。具体的配置步骤包括设置Zipkin服务器的地址、端口等信息。完成配置后，您就可以开始使用Zipkin进行链路跟踪了。

在整合过程中，您需要注意一些关键步骤和细节。确保您的应用程序正确地发送跟踪数据到Zipkin服务器。您需要合理地配置跟踪数据的采样率，以避免对系统性能造成影响。您还需要关注跟踪数据的存储和查询方式，以便后续的性能分析和优化。

整合完成后，您可以利用Zipkin提供的功能进行链路跟踪和分析。通过查看跟踪数据，您可以了解请求在系统中的流动情况，从而发现潜在的性能问题并进行优化。您还可以利用Zipkin的UI界面进行可视化展示，以便更直观地了解系统的运行情况。

ASP.NET Core整合Zipkin链路跟踪是一项非常重要的技术，它可以帮助您更好地理解和优化您的系统。相信您已经掌握了整合Zipkin的基本方法和关键步骤。希望您在后续的SEO优化和网站性能提升过程中能够充分利用这一技术，为您的系统带来更好的性能和稳定性。也希望大家能够多多支持狼蚁SEO，共同学习进步。

更多关于ASP.NET Core整合Zipkin链路跟踪的内容，请搜索狼蚁SEO以前的文章或继续浏览狼蚁网站的相关优化文章。我们将不断更新和分享更多实用的技术知识和经验，以帮助大家不断提升技能水平。