Shulou(Shulou.com)06/03 Report--

The 2019 Spring Festival Alipay red packet technology disclosure online summit will begin on 03-07. Click here to participate in Daniel interaction at that time.

SOFA

Scalable Open Financial Architecture is a financial-level distributed middleware independently developed by Ant Financial Services Group, which contains all the components needed to build a financial-level cloud native architecture. It is a best practice honed in the financial scenario.

SOFATracer is a component for distributed system call tracking. All kinds of network calls in the call link are recorded in a log through a unified TraceId to achieve the purpose of perspective network calls. These link data can be used for rapid fault detection, service governance and so on.

This article is the second article of "Analysis | SOFATracer Framework". "profile | SOFATracer Framework" series is produced by the SOFA team and source enthusiasts, project code:, so far the collection has been completed, thank you for your participation.

SOFATracer:

Https://github.com/alipay/sofa-tracer

0. Preface

An overview of SOFATracer has been given in the article "Ant Financial Services Group distributed Link tracking component SOFATracer Overview | profile". From the definition of SOFATracer, we can know that SOFATracer, as a component of distributed system call tracking, records all kinds of network calls in the call link by data reporting through a unified TraceId, in order to achieve the purpose of perspective network calls.

This article will make a detailed analysis of the data reporting mode of SOFATracer in order to help you better understand the expansion of SOFATracer in data reporting.

1. Reporter whole model.

This section provides an overall introduction to the Report model of SOFATracer and consists of two parts:

1. Interface design and implementation of Reporter.

2. Data reporting process.

1.1.The interface design and implementation of Reporter

Data reporting is a function implemented by SofaTracer based on the extension of OpenTracing Tracer API. Reporter instance exists as an attribute of SofaTracer. When constructing SofaTracer instance, Reporter instance will be initialized.

1.1.1. Reporter interface design

Reporter API is the top-level abstraction for data reporting in SOFATracer. The core API method is defined as follows:

/ / get Reporter instance type String getReporterType (); / / output spanvoidreport (SofaTracerSpan span); / / disable the ability to output span void close ()

In addition to the core reporting function, the design of the Reporter interface also provides the ability to obtain the Reporter type, because the burying point mechanism currently provided by SOFATracer depends on this implementation.

1.1.2, Reporter interface implementation

The class architecture of Reporter is as follows:

Reporter has two implementation classes, SofaTracerCompositeDigestReporterImpl and DiskReporterImpl:

SofaTracerCompositeDigestReporterImpl:

The combined summary log reporting implementation traverses all the Reporter in the current SofaTracerCompositeDigestReporterImpl and performs report operations one by one, which can be extended for external users.

DiskReporterImpl:

The core implementation class of data on disk is also the default report device used in SOFATracer.

1.2. Analysis of data reporting process

Data reporting is actually initiated by different link components, so the extension mechanism and embedding methods of plug-ins are not the scope of this article. Take a look directly at the entrance to the data report here.

As mentioned in the Opentracing specification, the Span#finish method is the last method of execution in the span life cycle, which means that a span span is coming to an end. So when a span is about to end, it is also the time when the current span has the most complete state. So in SOFATracer, the entry for data reporting is the Span#finish method, and a short code is posted here:

/ / SofaTracerSpan#finish@Overridepublic void finish (long endTime) {this.setEndTime (endTime); / / key records: report spanthis.sofaTracer.reportSpan (this); SpanExtensionFactory.logStoppedSpan (this);}

In the finish method, the current span is reported through SofaTracer#reportSpan. With this as the entry point, the call link for the entire data report is shown in the following figure:

The whole process of reporting and calling is not very difficult, so here are two questions:

How to construct clientRportor and serverReporter, and on what basis? How do summary logs and statistical logs go down?

The answer to the first question is given in the plug-in parsing section; let's look at the second question below. 2. Log set up

As mentioned earlier, SOFATracer itself provides two reporting modes, one is to fall to disk, and the other is to report to zipkin. In terms of implementation details, SOFATracer does not separate the two strategies to provide independent functional support, but combines the two reporting methods together, and then controls whether to implement specific reporting logic by configuring parameters, as shown in the following figure:

This section will analyze the implementation details of the log disk in the future. The log is divided into the summary log and the statistical log; the summary log is the log that will land on the disk for each call; and the statistical log is the log that is output at regular intervals.

2.1. Summary log is closed.

Log storage is based on Disruptor high-performance lock-free circular queue. In SOFATracer, the AsyncCommonDigestAppenderManager class encapsulates disruptor to handle Tracer summary log printing for external components.

The principle of Disruptor and its own event model are not analyzed here. Students who are interested can consult the relevant materials on their own. Here's a direct look at how Disruptor is used in SOFATracer.

2.1.1. Message event model

SOFATracer uses two different event models, one is StringEvent used internally by SOFATracer, and the other is SofaTacerSpanEvent used by external extensions. See SofaTracerSpanEvent & StringEvent for details.

2.1.2, Consumer consumers

Consumer is the inner class of AsyncCommonDigestAppenderManager; implements the EventHandler interface, which exists as a consumer, listens for events, and then flush span data to disk through TraceAppender. For details, see: AsyncCommonDigestAppenderManager

2.1.3. Initialization of Disruptor

Construction of Disruptor: done in the constructor of AsyncCommonDigestAppenderManager.

/ / build disruptor using ProducerType.MULTI// waiting strategy BlockingWaitStrategy, taking into account the utilization and consistency of CPU disruptor = new Disruptor (new SofaTracerSpanEventFactory (), realQueueSize, threadFactory,ProducerType.MULTI, new BlockingWaitStrategy ()); exception handling: if an exception occurs during consumption, SOFATracer will type the exception information into tracer-self.log through a custom ConsumerExceptionHandler exception handler. The parameter conditions related to printing are set, such as whether messages are allowed to be discarded, whether the number of lost logs is recorded, whether the TraceId and RpcId of lost logs are recorded, and whether the number of lost logs reaches a certain threshold for a log output.

2.1.4. Start Disruptor

The startup of Disruptor is delegated to the AsyncCommonDigestAppenderManager#start method to execute.

Public void start (final String workerName) {this.threadFactory.setWorkName (workerName); this.ringBuffer = this.disruptor.start ();}

Check the call stack to see where the start is called in SOFATracer:

CommonTracerManager: this holds a singleton object of the AsyncCommonDigestAppenderManager class and calls the start method in the static static code block; this is used to output normal middleware logs. SofaTracerDigestReporterAsyncManager: here the class also holds a singleton object of the AsyncCommonDigestAppenderManager class, and provides a getSofaTracerDigestReporterAsyncManager method to get the singleton, in which the start method is called; this object is used to output the summary log.

2.1.5. Release event

Publishing the event means that you currently need to generate a span record, which is also in the call stack of the finish method, that is, the DiskReporterImpl#digestReport method in the figure above.

AsyncCommonDigestAppenderManager asyncDigestManager = SofaTracerDigestReporterAsyncManager.getSofaTracerDigestReporterAsyncManager (); / /... asyncDigestManager.append (span); / /.

Here, the span data is append to the ring buffer. According to the initialization attribute of AsyncCommonDigestAppenderManager, if discarding is allowed, the application sequence will be attempted using tryNext, and the exception will not be thrown; otherwise, the application sequence will be blocked by next () mode. Here is a simple simulation:

2.1.6. Summary

The failure of the summary log depends on the event model of Disruptor. When the span#finish method is executed, the report behavior of SofaTracer is triggered; report will eventually put the current span data into the Disruptor queue and issue a SofaTracerSpanEvent event. Disruptor's consumer EventHandler implementation class Consumer listens for the current queue event and then flushes the span data to disk in the callback function onEvent.

2.2. Implementation of statistical log storage

The function of statistical log is to monitor the use of statistics, which records the current span of the number of calls, execution results and other data. Statistical logs are logs that are statistically output at regular intervals, so it is easy to think that they are performed using periodic tasks. Here also to track the statistical log printing method call process.

2.2.1. Call link of statistical log

AbstractSofaTracerStatisticReporter's doReportStat method is an abstract method, so here it is associated with the plug-in extension:

You can see that the implementation classes of AbstractSofaTracerStatisticReporter are all under the SOFATracer plugins package, which means that statistical log printing needs to be defined by different extensions. But in fact, different plug-ins do not flush span data directly to disk when overriding the doReportStat method, but convert SofaTracerSpan to StatMapKey and stuff it into a map structure object in AbstractSofaTracerStatisticReporter. For more information, please see AbstractSofaTracerStatisticReporter#addStat.

2.2.2. Printing model of statistical log

As mentioned earlier, the storage of statistical logs has a certain periodicity, so in the design of statistical logs, SOFATracer does not rely on Disruptor like summary logs. Let's take a look at the working model of the summary log through a simple structure diagram:

XxxxxStatReporter: the statistical log Reporter class implemented by the plug-in extender overrides the doStatReport and print methods. AbstractSofaTracerStatisticReporter: an abstract class for extension, of which xxxxxStatReporter is a subclass; in its constructor, AbstractSofaTracerStatisticReporter registers the current statReporter with SofaTracerStatisticReporterManager through SofaTracerStatisticReporterCycleTimesManager and stores it uniformly in the statReporters collection. SofaTracerStatisticReporterManager: statistical log reporter manager, reporter of all plug-in extensions will be registered with this manager class. Its inner class StatReporterPrinter implements the runnable interface, and traverses the statReporters in the run method, calling the print method one by one to brush the data to the disk. SofaTracerStatisticReporterManager initializes the cycle of task execution, initializes ScheduledExecutorService instances in the constructor, and submits StatReporterPrinter to the thread pool of scheduled tasks, thus realizing the function of periodically outputting statistical logs. 3. Report to Zipkin

The data in SOFATracer is analyzed before, and finally, let's take a look at how the data in SOFATracer is reported to zipkin.

3.1.1. The process of reporting zipkin

Following the above analysis, the data reporting strategies in SOFATracer coexist in combination, which can be seen here in conjunction with the first diagram in section 2. Here, the reporting process of zipkin is given, and then the analysis is carried out with the process:

There is a method in SofaTracer#reportSpan that is invokeReportListeners;. The purpose of this method is to iterate through all the current SpanReportListener implementation classes and call back the onSpanReport method of SpanReportListener one by one. ZipkinSofaTracerSpanRemoteReporter is a class provided in the sofa-tracer-zipkin-plugin plug-in that implements the SpanReportListener interface and reports span data to zipkin through the zipkin2.reporter.AsyncReporter instance object in the onSpanReport callback function. Although both SOFATracer and zipkin are based on the OpenTracing specification, SOFATracer has made a lot of extensions in the specific implementation, so it is necessary to adapt SofaTracerSpan to zipkin2.Span through a ZipkinV2SpanAdapter.

Zipkin2.reporter.AsyncReporter is a data reporting abstract class provided by zipkin. The default implementation is BoundedAsyncReporter. Through a daemon thread flushThread, it calls the flush method of BoundedAsyncReporter all the time to report the span information in memory to zipkin.

3.1.2. Escalation support for non-SpringBoot applications

The ability to report zipkin has been changed once, mainly for support in non-SpringBoot applications (that is, Spring project). For more information, please see issue: it is recommended to use sofa-tracer without spring boot and report to zipkin.

For the SpringBoot project, with the introduction of tracer-sofa-boot-starter, the auto-configuration class SofaTracerAutoConfiguration saves all current bean instances of SpanReportListener type to the List object of SpanReportListenerHolder. Bean of type SpanReportListener is injected into the current Ioc container in the ZipkinSofaTracerAutoConfiguration autoconfiguration class. In this way, when invokeReportListeners is called, you can get the reporting class of zipkin, so you can report.

For reporting support for non-SpringBoot applications, it is essentially necessary to instantiate the ZipkinSofaTracerSpanRemoteReporter object and place it in the List object of the SpanReportListenerHolder. So SOFATracer provides a ZipkinReportRegisterBean in the zipkin plug-in, and by implementing the bean lifecycle interface InitializingBean provided by Spring, build an instance of ZipkinSofaTracerSpanRemoteReporter after ZipkinReportRegisterBean initialization and give it to the SpanReportListenerHolder class to manage.

3.1.3, Zipkin reports cases and shows

For reporting cases using zipkin in SpringBoot project, please refer to: reporting data to zipkin

For information on the use of zipkin reporting plug-ins in spring applications, please refer to: tracer-zipkin-plugin-demo

Services display

Link dependency display

4. Summary 4.1.The consideration of SOFATracer in data reporting model.

Students who know or use SOFATracer should know that SOFATracer currently does not provide the functions of data collector and UI display; there are two main considerations:

As a very lightweight component in the SOFA system, SOFATracer is intended to log the span data to disk, so that users can be more flexible to deal with the data UI display. SOFATracer itself is based on OpenTracing specification and can be seamlessly docked with some open source products in the model. To a certain extent, it can make up for its own shortcomings in link visualization.

Therefore, in the reporting model, SOFATracer provides the expansion of log output and external reporting, so that the access party can be flexible enough to deal with the reported data. 4.2. Summary of the article

Through this article, you should have a general understanding of the SOFATracer data reporting function. For the internal implementation details, due to length and readability of the article and other reasons, it is not appropriate to post too much code. I hope that interested students can read the source code directly and understand some of the details. Data reporting as one of the core expansion capabilities of SOFATracer, although different reporting approaches correspond to different reporting models, the overall structure is still relatively clear, so it is not very difficult to understand.

The links mentioned in the article:

Disruptor:

Https://github.com/LMAX-Exchange/disruptor

SofaTracerSpanEvent:

Https://github.com/alipay/sofa-tracer/blob/master/tracer-core/src/main/java/com/alipay/common/tracer/core/appender/manager/SofaTracerSpanEvent.java

StringEvent:

Https://github.com/alipay/sofa-tracer/blob/master/tracer-core/src/main/java/com/alipay/common/tracer/core/appender/manager/StringEvent.java

AsyncCommonDigestAppenderManager:

Https://github.com/alipay/sofa-tracer/blob/master/tracer-core/src/main/java/com/alipay/common/tracer/core/appender/manager/AsyncCommonDigestAppenderManager.java

[AbstractSofaTracerStatisticReporter#addStat]:

Https://github.com/alipay/sofa-tracer/blob/master/tracer-core/src/main/java/com/alipay/common/tracer/core/reporter/stat/AbstractSofaTracerStatisticReporter.java

Issue: it is recommended to use sofa-tracer without spring boot and report to zipkin:

Https://github.com/alipay/sofa-tracer/issues/32

Report data to zipkin:

Https://www.sofastack.tech/sofa-tracer/docs/ReportToZipkin

Tracer-zipkin-plugin-demo:

Https://github.com/glmapper/tracer-zipkin-plugin-demo

Click to read more and see more details

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.