Table of contents
2. Build a demonstration project
5.2. Use MQ to cut traffic peaks
1 Overview
When a distributed architecture is adopted, a request will flow between multiple services, and the services that make up a single call chain are often scattered on different servers. This will bring up a problem:
The fault is difficult to trace.
A request is initiated, and then an error is reported. Which link in the call chain is the problem? Very difficult to locate. At this time, link tracking technology needs to be used. The so-called link tracking technology is to find ways to make the link call of a single request in the distributed system traceable, so as to facilitate rapid location and traceability when a fault occurs.
There are currently two sets of implementation ideas:
-
Implemented based on logs, commonly used ones include Sleuth and zipkin
-
Implemented based on agent, commonly used ones include skywaiking
This article explains the log-based implementation of sleuth and its supporting visualization suite zipkin.
The author gave a detailed introduction to distributed link tracking above:
https://bugman.blog.csdn.net/article/details/135175596?spm=1001.2014.3001.5502
2. Build a demonstration project
The project used for demonstration this time is very simple. Spring cloud is used to build three services. An app service is used to provide services, an authentication center is used for login and authentication, and a bis service is used for aggregation:
Call the authentication center in bis to log in and obtain the token, then verify the token. After passing the verification, call the services provided by the app:
A systematic article on spring cloud is in another column of the blogger, starting from 0 and explaining it step by step (this series has been included in the 2023 Rising Star Plan):
3.sleuth
rely:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
<version>3.1.8</version>
</dependency>
If you visit bis, you will see:
bis log:
AuthenticationCenter log:
APP log:
I think many readers will have questions here.
ask:
How does sleuth ensure that the traceID on a link is the same?
answer:
When a request enters Spring Cloud's microservice system, Sleuth generates a unique Trace ID. If the request comes in from another service that uses Sleuth, Sleuth will extract and use the Trace ID passed in by that service. Sleuth integrates these communication protocols, such as the HTTP protocol, and automatically adds the Trace ID to the header of the HTTP request, the metadata of the message, etc. when calling between services.
4.zipkin
With just the logs, troubleshooting still requires going through them one by one, which is still very cumbersome. Therefore, a visualization suite appeared, developed by Twitter-zipkin. It can collect and display logs in standard opentracing format. The standard CS architecture used by zipkin, the client sends data to the server.
Server:
The server is a jar package, which can be run directly. Download address:
Central Repository: io/zipkin/zipkin-server
Client:
rely:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
<version>2.2.1.RELEASE</version>
</dependency>
Configuration:
#zipkin server address
spring.zipkin.base-url=http://localhost:9411/
#The way the client sends data to the server, web, http message
spring.zipkin.sender.type=web
Effect:
The startup log of zipkin has clearly told the access address of the web interface:
Visit 127.0.0.1:9411/ and you can see:
Click the link to see the details of a single request:
5. Plug-in storage
Where is the data on the server collected by zipkin from each client stored? The default is to store data in memory. In addition, zipkin also supports a variety of data storage methods, such as mysql, ES, etc., which can be switched according to the needs of the scenario.
5.1. Store in MySQL
To store it in MySQL, you must first create a table. Zipkin comes with a MySQL table creation script in the project file:
As you can see in the configuration file of the server's source code project, the default storage is memory, and the parameters have default values, but parameters can be passed to set:
Therefore, when starting with java -jar, you can switch the storage type by following the parameters:
java -jar zipkin-server-2.20.1-exec.jar --STORAGE_TYPE=mysql --MYSQL_HOST=localhost --MYSOL_TCP_PORT=3306 --MYSQL_USER=root --MYSQL_PASS=admin --MYSQL_DB=zipkin
In this way, the data will be stored in MySQL for persistence.
5.2. Use MQ to cut traffic peaks
zipkin supports multiple data storage methods, such as mysql, ES, etc. The default is to store data in memory.
Server side:
As you can see from the configuration file, zipkin server supports Kafka, rabbitMQ and other MQs. The specific configuration is configured by starting the parameter transfer method:
Which kind of MQ you want to use, just configure it directly. Here we take rabbitMQ as an example:
java -jar zipkin-server-2.20.1-exec.jar --STORAGE_TYPE=mysql --MYSQL_HOST=localhost --MYSOL-TCP-PORT=3306 --MYSOL_USER=root --MYSQL_PASS=admin --MYSQL_DB=zipkin --RABBIT_ADDRESSES=10.1.2.10:5672 --RABBIT_USER=quest --RABBIT_PASSWORD=guest --RABBIT_VIRTUAL_HOST=/ --RABBIT_QUEUE=zipkin
Client side:
Add the following mq configuration on the client side:
#zipkin server address
spring.zipkin.base-url=http://localhost:9411/
#The way the client sends data to the server, rabbitmq
spring.zipkin.sender.type=rabbit
#Queue name
spring.zipkin.rabbitmq.queue= zipkin
#Server IP, port number, account name, password
spring.rabbitmq.host=10.1.2.10
spring.rabbitmq.port=5672
spring.rabbitmq.username=guest
spring.rabbitmq.password=guest
#Virtual host address
spring.rabbitmq. virtual-host=/
#Whether to enable release retry
spring.rabbitmq.listener.direct.retry.enabled=true
#Maximum number of retries
spring.rabbitmq.listener.direct.retry.max-attempts=5
#Retry interval
spring .rabbitmq.listener.direct.retry.initial-interval=5000
#Whether to enable consumer retry
spring.rabbitmq.listener.simple.retry.enabled=true
#Maximum number of retries
spring.rabbitmq.listener.simple.retry.max -attempts=5
#Maximum interval
spring.rabbitmq.listener.simple.retry.initial-interval=5000
6. Contact the author
No public:
Bloggers will systematically output back-end useful information on it.
Business cooperation and various exchanges:
