This is the 30th day of my participation in the August Text Challenge.More challenges in August

🌈 Column Introduction

Thank you for reading, I hope to help you, if there is a flaw in the blog, please leave a message in the comment area or add my private chat in the home page, thank you for every little partner generous advice. I am XiaoLin, a boy who can both write bugs and sing rap. This column mainly introduces the most mainstream micro services solution, SpringCloudAlibaba, which will be introduced in groups. Column address: SpringCloudAlibaba

  • 7️ Gateway (suggested collection)
  • 6️ Sentinel (suggested collection)
  • 5️ retail Feign
  • 4️ Ribbon (suggested collection)
  • 3️ Nacos (suggested collection)
  • 2️ retail (suggested collection)
  • 1️ retail (suggested collection)

Link tracking: Sleuth&Zipkin

10.1 Introduction to Link Tracing

In the microservitization of large systems, a system is broken down into many modules. These modules are responsible for different functions, combined into a system that can ultimately provide rich functionality.

In this architecture, a single request often involves multiple services. Internet applications are built on different sets of software modules, which may be developed by different teams, implemented in different programming languages, and deployed on thousands of servers across multiple data centers, which means that there are some problems with this architecture:

  1. How to find problems quickly?
  2. How do I determine the scope of the fault?
  3. How to sort out service dependencies and their rationality?
  4. How to analyze link performance problems and plan real-time capacity?

Distributed Tracing refers to restoring a Distributed request to a call link for logging, performance monitoring, and centralized display of calls of a Distributed request. For example, the time spent on each service node, the specific machine on which the request arrives, the request status of each service node, and so on.

Common link tracing techniques include the following:

  1. Cat: Real-time application monitoring platform developed based on Java and open source by Dianping, including real-time application monitoring and business monitoring. The integration solution is to implement monitoring through code burying points, such as interceptors, filters, etc. The code is very intrusive and the integration cost is high. The risk is greater.
  2. Zipkin: An open source distributed tracking system developed by Twitter to collect timed data from services to address latency issues in microservices architecture, including data collection, storage, lookup, and presentation. The product is relatively simple to use in combination with Spring-Cloud-sleUTH, with easy integration but simple functionality.
  3. Pinpoint e is the Korean open source based on bytecode injection call chain analysis, as well as application monitoring analysis tools. Feature is to support a variety of plug-ins, UI powerful, access end without code intrusion.
  4. Skywalking: SkyWalking is a native open source call chain analysis and application monitoring analysis tool based on bytecode injection. Feature is to support a variety of plug-ins, strong UI function, access end without code intrusion. You have joined the Apache incubator.
  5. Sleuth: Link tracing solution for distributed systems provided by SpringCloud.

SpringCloud Alibaba technology stack does not provide its own link tracking technology, we can use Sleuth +Zinkin to do the link tracking solution.

10.2 Introduction to Sleuth

10.2.1 Introduction to Sleuth

SpringCloud Sleuth’s main function is to provide tracking solutions in distributed systems. It borroys heavily from the Google Dapper design, but let’s start with the terminology and related concepts in Sleuth.

  • Trace

    A group of Span with the same Trace Id is connected together to form a tree structure. To achieve request tracing, when a request arrives at an entry endpoint in a distributed system, the service tracing framework only needs to create a unique identifier (TraceId) for the request, and the framework keeps passing the unique value as it flows through the distributed system until the entire request is returned. We can then use this unique identifier to concatenate all requests to form a complete request link.

  • Span

    Represents a set of basic units of work. In order to count the latency of each processing unit, a unique identifier (SpanId) is also used to mark the start, progress, and end of a request when it arrives at each service component. The SpanId’s start and end timestamps count when the SPAN was called, as well as the name of the event. Request information and other metadata.

  • Annotation

    Use it to record events over a period of time. Important notes for internal use:

    • Cs (Client Send) The Client sends a request to start the life of a request.
    • Server Received (SR) Sr-CS = network delay (service invocation time).
    • Server Send (SS) Indicates the request processing time on the Server. Ss – sr = Indicates the request processing time on the Server.
    • Client Reveived (CR) The Client receives the response from the server, and the request ends. Cr-sr = Total time of request.

10.2.2 Integrated link tracking component Sleuth

Sleuth is extremely simple to use and simply introduces a dependency.

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

We can print logs in a random service and see sleuth’s log output on the console:

Log parameters:

[product-service,d1e92e984eaec1ff,d1e92e984eaec1ff,true]

  1. The first value, the value of spring.application.name, represents the service name

  2. The second value, D1E92E984eaEC1ff, is the Trace ID generated by SLEuth. It is used to identify a request link. A request link contains one Trace ID and multiple Span ids

  3. The third value, d1E92E984EAEC1FF, spanID basic unit of work, gets metadata, such as sending an HTTP

  4. The fourth value: true, whether to output this information to the Zipkin service for collection and display.

Viewing log files is not a good way to do this, and as more microservices become available, there will be more and more log files. With Zipkin, you can aggregate logs for visual presentation and full text retrieval.

10.3 Zipkin+Sleuth integration

10.3.1 Introduction to ZipKin

Zipkin is an open source project for Twitter, based on the Google Dapper implementation, which aims to collect timed data from the service to address latency issues in the microservice architecture, including data collection, storage, lookup, and presentation. We can use it to collect the tracking data of the request link on each server, and through the REST API interface provided by it to assist us to query the tracking data to realize the monitoring program of the distributed system, so as to timely find the delay increase problem in the system and find out the root of the system performance bottleneck. In addition to the development-oriented API interface, it also provides convenient UI components to help us intuitively search tracking information and analyze request link details, such as: you can query the processing time of each user request within a certain period of time.

Zipkin provides pluggable data storage options: In-memory, MySql, Cassandra, and Elasticsearch.

It mainly consists of four core components:

  1. Collector: A Collector component that processes trace information sent from external systems and converts it into a Span format processed internally by Zipkin for subsequent storage, analysis, presentation, and so on.
  2. Storage: A Storage component that processes trace information received by the collector. By default, this information is stored in memory. We can also modify this Storage policy to store trace information to the database by using other Storage components.
  3. RESTful apis: API components that provide external access interfaces. For example, to display tracking information to clients, or external system access to achieve monitoring, etc.
  4. Web UI: UI component, an upper application based on API components. Through UI components, users can easily and intuitively query and analyze tracking information.

Zipkin is divided into two ends, one is Zipkin server, one is Zipkin client, the client is the application of micro services. The client will configure the URL address of the server. Once the invocation between services occurs, it will be monitored by the Sleuth listener configured in the micro-service, and the corresponding Trace and Span information will be generated and sent to the server.

10.3.2 ZipKin server installation

Download the ZipKin JAR package

The official website download address, download after is a JAR package.

Start by command

Java-jar Specifies the name of the JAR packageCopy the code

Go to http://localhost:9411

10.3.3 Zipkin+Sleuth integration

Add dependencies to shop-Produuct-server and shop-order-server

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

Add application.yml to shop-Produuct-server and shop-order-server

spring:
  zipkin:
    base-url: http://127.0.0.1:9411/ #zipkin server request address
    discoveryClientEnabled: false Have nacos treat it as a URL, not as a service name
    sleuth:
      sampler:
        probability: 1.0 # Percentage of samples
Copy the code

Access to the test