this article briefly introduces how to use zipkin to perform service analysis on spring cloud applications. in practical application, zipkin can be used in combination with stress testing tools to analyze the availability and performance of systems under high stress.
imagine the following scenario: if your microservices grow gradually and the dependencies between services become increasingly complicated, how can you analyze the call relations and mutual influences between them?
an application comprised of microservices divides the problem domain through services and completes the operation through rest api to connect services. an entry service call may require the coordination of multiple background services. any call timeout or error on the link may lead to the failure of the front-end requests. the call chain of the service will become longer and longer, and form a tree-shaped call chain.
although it doesn't match the source, i think this should be 'service call'... a service call may require the coordination of multiple background services.
with the increasing services, the analysis on the call chain will become more and more detail-oriented. suppose you are in charge of the system below, and every small point in it is a microservice. the call relations between the microservices constitute the complicated network.
the open-source implementation corresponding to dapper is zipkin. it supports multiple languages including javascript, python, java, scala, ruby, c# and go. among them, java supports different databases.
in this example, we prepare to develop two spring cloud-based applications and use spring cloud sleuth to integrate with zipkin. spring cloud sleuth is a kind of encapsulation of zipkin and automates span and trace information generation, access of http requests and sending collection information to the zipkin server.
this is a concept map of spring cloud sleuth.
there are two demo services in this example: tracedemo, acting as the frontend service to receive requests from users; and tracebackend, acting as the backend service. the tracedemo calls the backend service through the http protocol.
the tracedemo application calls the backend tracebackend service through resttemplate. attention: the tracedemo address is specified in the url as backend.
the backend service responds to the http request, and the output log shows that it returns the classic “hello world”.
we can see that this is a typical access from two spring applications through resttemplate. so which one of them injects the tracing information in the http request and sends the information to zipkin server? the answer lies in the jar packages loaded by the two applications.
in this example, gradle is used to build applications. jar packages related to sleuth and zipkin are loaded in build.gradle:
after the spring application detects sleuth and zipkin in java dependent packages, it will automatically inject tracing information to the http request during resttemplate calls, and send the information to the zipkin server.
so where can we specify the address of the zipkin server? the answer is: in application.properties:
note: the zipkin server address is: zipkin-server.
create two identical dockerfiles for these two services to generate the docker image:
the procedure for building a docker image is as follows:
create zipkin using annotation declarations
introduce zipkin dependent package in <code>build.gradle</code>.
add an annotation @enablezipkinserver in the main program class
specify the port as 9411 in <code>application.properties</code>.
the dockerfile here is the same as with the previous two services, so i won't repeat the procedure here.
create the <code>docker-compose.yml</code> file with the following content:
using the orchestration templateon alibaba cloud docker, and visit the zipkin endpoint, then you will see the effect of service analysis.
visit the front-end application three times, and the page displays three service calls.
click any trace, and you will see the duration of different spans on the request link.
enter the dependencies page, and you will see the dependency relationships between services.
from this process, we can see that zipkin and spring cloud integration is successful. the visualization of service tracing analysis is also intuitive.
it is worth noting that you also need to configure databases for zipkin in a production environment. i will not go into the details here.