Spring Cloud Distributed Link Tracking (integrated zipkin)

Write a distributed Link Tracking Spring Cloud Distributed Link Tracking

This kind of link tracking can solve the problem but the log is too fragmented if too many microservices can become quite complex

Zipkin can help us gather all the link-call processes.

It's like a registry, which is divided into clients and services that want to use a module first as his server.

First add the following dependencies

Compile ' io.zipkin.java:zipkin-server' Io.zipkin.java:zipkin-autoconfigure-ui '

Configure its port number and project name in the configuration file

Server:   9999Spring:  application:    name:zikpin-server

And then add @enablezipkinserver to his startup class.

@EnableZipkinServer @springbootapplication  Public class Zikpinserverprovider {    publicstaticvoid  main (string[] args) {        Springapplication.run (Zikpinserverprovider. class , args);}    }

It means that this is the Zipkin server.

Then you need to join the dependency on the client

    Compile group: ' Org.springframework.cloud ', Name: ' Spring-cloud-sleuth-zipkin '

Configuring on the Client

Spring:     zipkin:        base-url:http://localhost:9999 #代表zipkin服务端的地址     Sleuth:        Sampler:           1.0  #代表提交链路到zipkin的频率

Run localhost:9999

Can see this page this is Zipkin's homepage He can be very specific image of the link between the micro-services and their calls and time, performance, etc.

We run a method to invoke another microservices with the microservices try it if that's not going to be able to see my previous call between the spring cloud Eureka MicroServices

Then select time to query to see

Have seen us call two microservices for this request

We can also find the call chain based on the ID in the upper right corner to find the need to introduce sleuth based on the requested ID.

Refer to one of my blogs for details Spring cloud Distributed Link Tracking

And then, speaking of the above

Sleuth:        Sampler:           1.0

The following values can be entered between 0.1-1.0 for how much

It means that a percentage of the requests will be uploaded to Zipkin, like 50% of us. Upload it once, and then do it for the second time. Display only in the form of a log

Why do you use this thing?

Calls between our microservices are inherently resource-intensive and limited because the need to invoke another micro-service now needs to be uploaded to Zipkin, which can affect performance very much.

If it takes 30 seconds to upload to Zipkin, then the micro-service will do nothing but wait for 30 seconds to do something else so if the upload volume is particularly large, you can upload just a few samples

Link information can also be uploaded to the message queue so that it can be decoupled to the efficiency will not have an impact and then Zipkin from the message queue to download can be used Kafka and the like, I will write another blog in detail

The above is distributed Link tracking with integrated Zipkin

Spring Cloud Distributed Link Tracking (integrated zipkin)