Spring Cloud Starter Series Eight: Service link tracking with Spring cloud sleuth Consolidated Zipkin

Haven't written a blog for a long time, mainly is a few busy recently, today sneak into an article.

======= I'm gorgeous split-line ==========

MicroServices architecture is a distributed architecture, micro-service system according to Business Division service Unit, a micro-service will often have a lot of service units, a request will often have a lot of units involved, once the request is abnormal, want to locate the problem point really not easy, so need to have something to track the request link, Records which service units are called by a request, what the order of calls is, and how long it takes to process each service unit. Common service link Tracking components include Google's dapper, Twitter's Zipkin, Ali's eagle eye, and so on, all of which are outstanding open source link tracking components.

Spring Cloud has its own components to integrate these open source components, the spring cloud Sleuth, which provides a complete set of solutions for service link tracking.

Today's topic is how to use the Spring Cloud Sleuth integrated Zipkin for service link tracking. This blog will be expanded around the following clues:

1. Server-side Code implementation
2. Client-side Code implementation
3. Perform tests

By the above clues can be found, Zipkin sub-server and client.

The client is our service unit, used to send link information to the server;

The server is used to receive the link information sent by the client and to process it, which consists of 4 parts:

• Collector component: Used to receive the link information sent by the client and then organized into a format that can be processed by Zipkin for subsequent storage or to provide external queries for use.
• Storage components: The link information is saved, by default in memory, through the configuration can also be saved to MySQL and other places.
• Restful API components: Provides API interfaces for querying link information to other service units.
• Web UI component: Invokes the interface of the API component and displays the information to the web screen.

Nonsense not much to say, directly on the code.

First, the server-side code implementation

The code structure is given first:

The structure is relatively simple, the construction process is as follows:

2. New MAVEN Project Sleuth-zipkin
3. Modify the Pom file

   <Projectxmlns= "http://maven.apache.org/POM/4.0.0"Xmlns:xsi= "Http://www.w3.org/2001/XMLSchema-instance"xsi:schemalocation= "http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">    <modelversion>4.0.0</modelversion>    <groupId>Com.sam</groupId>    <Artifactid>Sleuth-zipkin</Artifactid>    <version>0.0.1-snapshot</version>    <Parent>        <groupId>Org.springframework.boot</groupId>        <Artifactid>Spring-boot-starter-parent</Artifactid>        <version>1.5.1.RELEASE</version>    </Parent>    <Properties>        <javaversion>1.8</javaversion>    </Properties>    <!--version Management with Dependencymanagement -    <dependencymanagement>        <Dependencies>            <Dependency>                <groupId>Org.springframework.cloud</groupId>                <Artifactid>Spring-cloud-dependencies</Artifactid>                <version>Camden.sr6</version>                <type>Pom</type>                <Scope>Import</Scope>            </Dependency>        </Dependencies>    </dependencymanagement>    <Dependencies>        <!--introducing Zipkin-server dependencies to provide server-side functionality -        <Dependency>            <groupId>Io.zipkin.java</groupId>            <Artifactid>Zipkin-server</Artifactid>        </Dependency>        <!--introduction of Zipkin-autoconfigure-ui dependencies to provide functionality for Zipkin Web UI components for easy viewing of relevant information -        <Dependency>            <groupId>Io.zipkin.java</groupId>            <Artifactid>Zipkin-autoconfigure-ui</Artifactid>        </Dependency>        <!--Introducing Eureka Dependencies -        <Dependency>            <groupId>Org.springframework.cloud</groupId>            <Artifactid>Spring-cloud-starter-eureka</Artifactid>        </Dependency>            </Dependencies></Project>

5. new Startup class

    /**   * @EnableZipkinServer * * Used to turn on the Zipkin server function *  */ @ Enablezipkinserver@springbootapplication@enablediscoveryclient  public  class   Sleuthzipkinapp { public  static  void   main (string[] args) {Springapplication.run (Sleuthzipkinapp. ) class      

    

7. New configuration file

   server.port=9411spring.application.name=sleuth-Zipkin
   #需要使用到eureka服务注册中心eureka. Client.serviceUrl.defaultZone=http://Localhost:1111/eureka

Second, client-side code implementation

Here we are going to use the previously implemented MicroServices (Gateway service Api-gateway, consumer Hello-consumer, and producer Hello-server, which can be viewed by clicking the link to see the build process, which is not described in detail here). The following modifications are made in these micro-services:

1. Introducing Dependencies

   <!--introducing Zipkin dependencies, providing Zipkin client functionality--        <dependency>            <groupId>org.springframework.cloud< /groupid>            <artifactId>spring-cloud-starter-zipkin</artifactId>        </dependency>

2. Modify configuration file, append two configuration

   #指定zipkin服务端的url
   spring.zipkin.base-url=http://localhost:9411
   #设定样本收集的比率为100%
   spring.sleuth.sampler.percentage=1.0

   Because of the general size of the request of the distributed system, it is impossible to collect all the request links, so sleuth uses the sampling collection method to set a sampling percentage. In the development phase, we typically set a percentage of 100% or 1.

III. implementation of the test

2. Start microservices in turn: Service registry Eureka, Zipkin server Sleuth-zipkin, Gateway Service Api-gateway, consumer Hello-consumer, and producer Hello-server
4. Visit http://localhost:1111/to confirm that 4 micro services have been successfully registered with the Service registration center

6. access http://localhost:5555/hello-consumer/hello-consumer?accessToken=111, accessed through the Zuul Gateway,

   View the Api-gateway console:

    2018-07-19 18:02:34.999 INFO   [Api-gateway,4c384ab23da1ae35, 4c384ab23da1ae35,true]   9296---[nio-5555-exec-3] com.sam.filter.AccessFilter:send GET requ EST to Http:// localhost:5555/hello-consumer/ Hello-consumer  2018-07-19 18:02:45.088 INFO [api-gateway,,,] 9296---[trap-executor-0] c.n.d.s.r.aws.configclusterresolver:resolving Eureka Endpoints via configuration 

   See the Scarlet Letter section, which has 4 parts, separated by commas. The first part is the name of the service; the second part is Tranceid, each request will have a unique tranceid; the third part is Spanid, each unit of work sends a request to produce a spanid, each request produces a tranceid and multiple Spanid, According to Tranceid and Spanid, it is possible to analyze what service units a complete request has undergone, and part four is a Boolean that is used to mark whether the request link needs to be sampled for collection and sent to the Zipkin for sorting.

8. Visit the Zipkin server http://localhost:9411/to view the UI page

   Select Api-gateway, then click "Find Trances"

   can see which service nodes the request is experiencing. Click on the link to see the order of the calls, and also to see the length of time for each service node to be processed.

   Switch to the dependency screen to see the dependencies of the service node

Spring Cloud Starter Series Eight: Service link tracking with Spring cloud sleuth Consolidated Zipkin