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

This article mainly introduces the relevant knowledge of "how ServiceComb implements zipkin distributed call chain tracking". The editor shows you the operation process through an actual case, and the operation method is simple, fast and practical. I hope this article "how ServiceComb implements zipkin distributed call chain tracking" can help you solve the problem.

Brief introduction of SeviceComb + Zipkin

ServiceComb is the top-level project of Apache's microservices. In the framework of microservices, microservices communicate through the network, and we have to deal with all network-related problems, such as latency, timeout and partitioning. As more and more micro-services are deployed, we need the system to monitor the micro-service network latency and request flow.

How ServiceComb supports zipkin

ServiceComb provides a processing chain mechanism through which consumer and server call chain requests go through. By extending the handler processing chain interface, load balancing, circuit breaker fault tolerance, flow control and other capabilities can be achieved. Similarly, the call chain tracing capability is also achieved by extending the interface.

ServiceComb extends the interface of handler processing chain and writes a handler-tracing-zipkin module. The Handler-tracing-zipkin module is under the java-chassis/handler processing chain, and the module content is as follows.

The handler-tracing-zipkin module implements the tracking call chain to record data and upload tracking data to the zipkin service to support Zipkin.

Interpretation of handler-tracing-zipkin module source code

Each interface call request triggers the processing of the handler chain, and in this handler chain, ServiceComb writes the handler class ZipkinConsumerTracingHandler specifically for Zipkin

Adapt to ZipkinProviderTracingHandle. Let's take a look at these two categories.

ZipkinConsumerTracingHandler and ZipkinProviderTracingHandler

Looking at the source code of these two classes, we can see that they are both inherited from ZipkinTracingHandler.

There are only two constructors.

The difference is that different ZipkinTracingDelegate implementations are passed to the parent class constructor.

The ZipkinTracingDelegate implementations are ZipkinConsumerDelegate and ZipkinProviderDelegate respectively.

These two proxy classes encapsulate the corresponding Zipkin request consumption and request production operations, respectively. Let's focus on the source implementation of ZipkinTracingHandler.

ZipkinTracingHandler

The most important method of the handler class is the handler method, which receives an Invocation object and an AsyncResponse object (all ServiceComb built-in objects). The Invocation object contains information about the current call (including the HttpServletRequest object). Let's take a look at what this method has done.

The handler method executes the steps:

one

The tracingDelegate.createSpan (invocation) method is called to create a span. TracingDelegate is a ZipkinTracingDelegate object.

two

Calls the onResponse method of the current object to encapsulate it into an AsyncResponse object. The object is a functional object, and you can see in the function body of the figure below that tracingDelegate.onResponse (span, response, error) is finally called to upload span to the Zipkin server.

three

Call the invocation.next () method to pass the generated AsyncResponse object to the next handler processing.

four

If an exception occurs in the above operation, the tracingDelegate.onResponse (span, null, e) method is called to send the span with the exception information to the Zipkin server.

From the above analysis, we can see that tracingDelegate is very important, so let's take a look at what the ZipkinTracingDelegate interface does.

ZipkinTracingDelegate interface

As shown in the following figure, the interface defines four methods.

1.tracer () to get the corresponding tracker

2.createSpan (), which creates the corresponding span based on the information carried by the Invocation object

3.onResponse (), uploads the span object and its corresponding response and exception information to the Zipkin server

4.name (), distinguishing between consumption operations and production operations

The interface has two implementation classes, ZipkinConsumerDelegate

And ZipkinProviderDelegate, corresponding to the request consumption operation and the request production operation, respectively.

Below we can see the difference between the two implementations.

ZipkinConsumerDelegate and ZipkinProviderDelegate

Let's first compare the two pictures carefully. The first is the ZipkinConsumerDelegate class and the second is the ZipkinProviderDelegate class.

We will find that they all use the handler variable to operate accordingly. Notice that the handler variable here is of a different type in the two classes, the handler variable of ZipkinConsumerDelegate is the HttpClientHandler object, and the hanler variable of ZipkinProviderDelegate is the HttpServerHandler object. The HttpClientHandler and HttpServerHandler classes are final-decorated classes that cannot be inherited. We saw earlier that these two classes are responsible for creating the span and sending the span, so let's take a look at how these two objects are generated.

If you look closely, you can see that ↓↓↓

Part of the code for ZipkinConsumerDelegate constructor:

This.handler = HttpClientHandler.create (httpTracing, new ConsumerInvocationAdapter ())

Part of the code for ZipkinProviderDelegate constructor:

This.handler = HttpServerHandler.create (httpTracing, new ProviderInvocationAdapter ())

From the above two pieces of constructor code, we can see that both HttpClientHandler and HttpServerHandler pass in ConsumerInvocationAdapter objects and ProviderInvocationAdapter objects when creating objects. These two objects inherit Zipkin's HttpClientAdapter and HttpServerAdapter abstract classes respectively, and provide client-side and server-side information that belongs to ServiceComb itself. Zipkin can get this customization information without changing the code and use it to call chain tracing.

This is the end of the introduction to "how ServiceComb implements zipkin distributed call chain tracking". Thank you for reading. If you want to know more about the industry, you can follow the industry information channel. The editor will update different knowledge points for you every day.

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.