Introduction to Link Tracing

The use of microservice architecture makes the system become more and more complex. The original single system is divided into many services, and each service interacts with each other through the lightweight HTTP protocol.

In a singleton architecture, the invocation link of a request is very clear, typically by a load balancer such as Nginx. The caller’s request is forwarded to the back-end service, which does business processing and returns it to the caller. When an architecture becomes a microservice architecture, a number of problems can arise, such as the following three problems:

  • How can I troubleshoot the fault that the interface responds slowly?
  • How do I view the dependencies between services?
  • Requests run through multiple microservices. How do you string together logs for each request?

It can be solved by introducing distributed link tracking.

The principle of distributed link tracing is how to correlate all the service nodes through which the request passes. When a request arrives at the gateway from the client, which is the first entry, a unique request ID needs to be generated to identify the request. After arriving at service A from the gateway, the request ID must be passed to service A, so that the request from the gateway to service A can be associated, and so on, and then the service will pass through multiple layers, which need to transfer the information layer by layer. Of course, data needs to be reported, stored and displayed at each layer.

From our understanding of this requirement, link tracing is not very complicated. The difficulty is how to implement the tracing framework. In the case of request passing, services interact with each other using either the Feign invocation interface or the RestTemplate invocation interface to pass information to downstream services. You have to extend the framework for these calls. I sorted out some information, and friends in need can click to get it directly.

Java Basics

22 Java Architect Core books

Learning routes and materials from 0 to 1Java

1000+ questions from 2021

The core concept

  • Span: The basic unit of work, for example, sending RPC requests is a new Span, sending HTTP requests is a new Span, and internal method calls are a new Span.
  • Trace: indicates the link information of a distributed invocation. Each invocation generates a TraceId at the request entry.
  • Annotation: Information used to record events. In Annotation, there will be CS, SR, SS and CR. The C in front represents the client and S represents the server. S is sent, R is Received, S is sent. Here’s how this information works.
  • CS is Client Sent, Client sends a request, and this Annotation is the beginning of Span.
  • The Client Received a response from the server. The CS is subtracted from the CR timestamp

To know the total time required for the client to receive the response from the server.

  • SS, also known as Server Sent, sends the response back to the client when the request processing is complete, subtracting the SR with the timestamp of SS

The timestamp shows how long it took the server side to process the request.

  • SR is Server Received, the Server side gets the request and starts processing it, subtracting the CS timestamp from SR’s timestamp to show the network latency.

The primary function of the Spring Cloud Sleuth component is to provide a solution for service tracing in distributed systems.

Why do you need link tracing?

Microservices architecture is the partitioning of services by business, using REST calls. An exposed interface may require the cooperation of many services to complete the interface function. If any service on the link is faulty or the network times out, the interface invocation fails. As businesses expand, services call each other more and more complex.

In the frame of the micro service, a request by the client in the back-end system through a number of different service node calls to collaborative production last request as a result, each front request will form a complicated distributed service call link, link to any part of the high latency or mistakes can cause the failure of the entire request finally

So how to solve it?

  • Sleuth: link tracker
  • Zipkin: Link Analyzer (visual)

Introduction to Sleuth components

Sleuth is a component of the SpringCloud microservices system that implements a link tracing solution. You can locate which specific services are requested by a request. In a complex microservice system, if an exception occurs on a request, the service where the problem occurs can be quickly captured.

Workflow:

Sleuth records a requested link (which services and classes the request passes through)

A link has a unique Trace ID. Each link (service) that passes through is identified by a Span (recording request information). Each Span is associated with a parent ID

The project structure

The startup sequence is as follows

* Registry node07-Eureka-7001 * Link data collection service node07-zipkin-7003 * Service provides node07-provider-6001 node07-provider-6002 * gateway route node07-zuul-7002Copy the code

Setting up link Services

The core depends on

<dependency>
    <groupId>io.zipkin.java</groupId>
    <artifactId>zipkin-server</artifactId>
</dependency>
<dependency>
    <groupId>io.zipkin.java</groupId>
    <artifactId>zipkin-autoconfigure-ui</artifactId>
</dependency>

Copy the code

Start class annotation: @enableZipkinServer

The configuration file

server:
  port: 7003
spring:
  application:
    name: node07-zipkin-7003
eureka:
  instance:
    hostname: zipkin-7003
    prefer-ip-address: true
  client:
    service-url:
      defaultZone: http://registry01.com:7001/eureka/

Copy the code

Microservice configuration

The configurations of gateway, Zuul-7002, service provider, provider-6001, and provider-6002 are the same.

The core depends on

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

Copy the code

The configuration file

Spring: Zipkin: base-URL: http://localhost:7003 sleuth: sampler: # Data 100% upload percentage: 1.0Copy the code

The test process

The registry

After starting the above services once, look at the registry:

Request process

Access interface

http://localhost:7002/v1/api-6001/get6001Info

Copy the code

The request enters from the gateway service, reaches the port service 6001, requests the 6002 end, and finally returns the result.

6001 interface

@Autowired
private RestTemplate restTemplate ;
@RequestMapping("/get6001Info")
public String get6001Info (){
    String server_name = "http://node07-provider-6002" ;
    return restTemplate.getForObject(server_name+"/get6002Info",String.class) ;
}

Copy the code

6002 interface

@RequestMapping(value = "/get6002Info",method = RequestMethod.GET)
public String get6002Info () {
    LOG.info("provider-6002");
    return "6002Info" ;
}

Copy the code

Link Management Interface

Zipkin:

Zipkin is the development source implementation of Twitter’s Distributed monitoring system Dapper (Paper) based on Google.

Zipkin is used to track application data links between distributed services, analyze processing delays, and help us improve system performance and locate faults. Liverpoolfc.tv: zipkin. IO /

UI

Access interface

Rely on the analysis of

Click “Dependency Analysis” in the picture, which is exactly the same as the request process described above.

The last

Thank you for reading this article, remember to like if you think it is helpful to you, thank you for your support!