Shulou(Shulou.com)05/31 Report--

This article mainly introduces the example analysis of micro-service tracking in Spring Cloud, which has a certain reference value, and interested friends can refer to it. I hope you will gain a lot after reading this article.

Overview of microservice tracking

First of all, do a basic explanation of the related concepts of micro-service tracking.

Practical problems and Sleuth

In the previous section, we used Spring Cloud to build a service cluster, which can be scaled out, whether it is Eureka servers, service instances, or nodes such as configuring servers, gateways, and so on. Once the number of services in the cluster increases and there are complex dependencies between them, managing them will become a tricky task.

When external users initiate requests to the cluster, these requests will invoke multiple services, and each service will rely on other services. At this time, if an exception or timeout occurs, it will be very difficult to troubleshoot the problem. We need to know clearly what is wrong with the service and where these problems lie.

In order to solve these problems, Spring Cloud provides Sleuth framework as a solution. Sleuth can be integrated with data analysis and service tracking systems such as Zipkin, Apache HTrace and ELK, which provides convenience for service tracking and problem solving.

Service tracking system

At present, there are many distributed tracking systems, such as Zipkin, HTrace and so on. These systems can help us to collect some real-time data (mainly logs) generated by the service. Through these data, we can analyze the health status, service invocation process, call time and other indicators of the distributed system, which provides a basis for optimizing the system and solving problems.

Readers need to distinguish between two basic concepts: service tracking and data analysis. After collecting the data generated by the service cluster, data analysis systems (such as ELK, etc.) can also realize the functions of service monitoring and service tracking, but it is obvious that the concept of data analysis system is more extensive and abstract. This book will introduce the service tracking system Zipkin, as well as the famous data analysis platform ELK.

Basic concepts of Sleuth

Sleuth draws on the design of Google Dapper and first understands the following two concepts:

Trace: represents the entire tracking process, from the user initiating the request to the final response. A trace contains multiple spans, which are saved in a tree structure.

Span: span, which represents the procedure of one call, and the trace contains multiple calls at a time. Suppose the user sends a request to the A service, and the A service invokes the B service, then there will be two spans: the user invokes the A service and the A service invokes the B service.

Figure 10-1 briefly describes the concept of span.

Figure 10-1 span

As shown in figure 10-1, the user or external program invokes A service. This call is regarded as a span A service but also a B service call. Span B is generated on the basis of span A, which is part of span A. in the design of Sleuth, span An is the parent span of B. Therefore, these spans are tree-like throughout the tracking process.

In addition to tracking and span, take a look at Annotation (event identification), which is mainly used to record the existence of events, including the following event identifiers:

Cs:Client Sent, which indicates that the client sent a request, and this identity indicates the beginning of the span. For example, the previous A service sends a request to B service, and A service is the client.

Sr:Server Received, which means that the server receives the request and begins to process it.

Ss:Server Sent, which means that the server completes the processing of the request and responds to the client.

Cr:Client Received, which indicates that the client receives a response, which means the end of the entire span.

Project preparation

Before using Sleuth, prepare the test project for this chapter. This chapter is mainly based on a micro-service cluster, which includes the following projects:

Test-eureka-server:Eureka server, port 8761.

Test-book-service: book micro service, which mainly provides the service of querying books according to id. The port is 8081.

Test-pay-service: payment micro-service, mainly provides payment service, port is 8082.

Test-sale-service: sales of micro services, book services and payment services will be called, port is 8083.

For all the above projects, you can find the corresponding source code in the codes\ 10 directory. The structure of several projects is shown in figure 10-2.

Figure 10-2 Test project structure

The above test projects are a simple Spring Cloud cluster, and the sales service relies on "book service" and "payment service".

Thank you for reading this article carefully. I hope the article "sample Analysis of Micro Service tracking in Spring Cloud" shared by the editor will be helpful to you. At the same time, I also hope that you will support us and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.