preface

In the recent iteration of TLog version 1.2.5, many friends have expressed their desire to participate in the contribution of open source projects. In order to better and faster iterate new features of the project and learn and communicate with each other in the spirit of open source, I am very lucky to recruit many friends to move forward with me.

This article is intended to help you understand the core principles and architecture of the TLog project. This article focuses on TLog technical design and core principles, but also covers the issues and technical points to consider when creating an open source framework.

I’ve always believed that good technical content should lead to the key points of how to read the source code. Not the whole post code. So this article is not source code analysis, but extract key points, so that we can better understand.

Because readers may have blind spots at certain points, I added extended reading as much as possible at certain points for the sake of detail. If you know the relevant knowledge, you can skip it.

Also, if you’re reading this for the first time and don’t know what TLog is, check out Gitee’s hosted repository and the project home page for features:

Gitee Hosted Repository: gitee.com/dromara/TLo…

Github hosting repository: github.com/dromara/TLo…

Project homepage: yomahub.com/tlog/

You can also check out a previous post about TLog

Mp.weixin.qq.com/s/-lalQBIUq…

The module

To learn about an open source framework, start with modules. TLog Locator is a lightweight log tracking framework consisting of 10 modules

First of all, since TLog is a logging framework, log enhancement is its core, should adapt to the mainstream logging framework (log4j/log4J2 /logback), the most important logic and the most core function implementation are in tlog-core module (may be separated from the three separate logging framework module).

Secondly, TLog is capable of log tracking, which naturally ADAPTS to microservices architecture and supports RPC framework/protocol (Dubbo/Dubbox/Spring Cloud Feign/HTTP). Since each RPC framework has its own extension points, it is naturally impossible to abstract out uniform processing logic. So we have the following modules:

Tlog-dubbo is an adaptation module for interconnecting with Apache Dubbo

Tlog-dubbox is an early open source version of Dubbox for docking, as some companies still use it

Tlog-feign is an adaptive module for interconnecting with Spring Cloud Feign

Tlog-webroot is the adaptation module for the most common HTTP calls

Considering that many companies using Spring Cloud use the Spring Cloud Gateway, there is an adaptation module tlog-gateway for Spring Cloud Gateway

In terms of Spring support, Tlog supports the traditional Spring XML configuration structure as well as automatic assembly of SpringBoot. Since spring is a subset of Springboot, there must be two modules, hence tlog-all and tlog-all-Springboot-starter. All is added because these two packages are also referenced by the developer, and they provide separate dependency addresses that will bring in other tlog packages as needed. So you don’t have to declare dependencies one by one.

TLog provides javaAgent-based dependency free use, so there is the tlog-Agent module. When packaging, it will be a separate JAR package.

Some of the VO, enumeration, and util classes commonly used by other Tlog modules are pulled out to form a single module, hence tlog-common.

The dependency diagram between modules is as follows:

Start loading

About 80% of TLog’s work is done at startup, so the first step is to figure out what TLog does as the project starts.

Since Springboot has auto-assembly, it’s only necessary to figure out what the tlog-all-Springboot-starter auto-assembly does to understand the meaning of manual configuration XML for non-Springboot projects.

Students who do not know springBoot automatic assembly function can first understand this piece of knowledge, I think this article is more thorough, can be extended to read:

zhuanlan.zhihu.com/p/95217578

The TLog configuration classes in springboot are shown in spring.factories:

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\ com.yomahub.tlog.springboot.TLogPropertyConfiguration,\ com.yomahub.tlog.springboot.TLogWebAutoConfiguration,\ com.yomahub.tlog.springboot.TLogFeignAutoConfiguration,\ com.yomahub.tlog.springboot.TLogAspectAutoConfiguration,\ com.yomahub.tlog.springboot.TLogCommonAutoConfiguration,\ com.yomahub.tlog.springboot.TLogGatewayAutoConfiguration
Copy the code

TLogPropertyConfiguration is mainly used for automatic assembly TLog configuration initializer, eventually TLogPropertyInit injection, in the traditional spring environment, also only need to configure TLogPropertyInit XML alone is ok, So the two Spring environments form the ultimate unity.

TLogWebAutoConfiguration is mainly used to automatically assemble HTTP interceptors.

TLogFeignAutoConfiguration are mainly used for automatic assembly spring cloud of intercepting filters feign environment.

TLogAspectAutoConfiguration are mainly used for automatic assembly the cut surface of the custom tag, spring will automatically for the classes to generate dynamic proxies into context.

TLogCommonAutoConfiguration are mainly used for automatic assembly tools based on the spring context. This utility class is used when many beans that are not managed by the Spring container want to fetch beans from the Spring context.

TLogGatewayAutoConfiguration are mainly used for automatic assembly spring cloud gateway under the environment of intercepting filters.

As long as you have registered the above autowiring classes, springBoot will automatically assemble them for you when you start up. But with traditional Spring, you still have to configure it individually in XML. So it is essential that open source projects support SpringBoot.

The order of automatic assembly is not in accordance with the order of configuration, there is a sequential dependence. Specific can carefully study the source code, source notes have written.

If you don’t know how to control the springBoot auto-assembly sequence, you should read my previous article on this topic

Mp.weixin.qq.com/s/-7kTj7lWr…

Dubbo/Dubbox, the three major logging framework enhancements do not need to register the autoloader?

Here’s an explanation:

Dubbo/Dubbox, which has an SPI-based implementation at design time, automatically recognizes the extension plug-in, so no beans need to be registered into the Spring container, so no assembly is required.

Log4j & Logback, bytecode mode, should be loaded before SpringBoot/Spring starts. More on that later. So it is not assembled during the Springboot/Spring boot phase. As for logging adaptation mode, the logging framework does this when loading the logging configuration file because the developer needs to replace the associated Encoder in advance. So you don’t need to auto-assemble anything.

Log4j2 is designed to be completely plug-in, so it can scan and recognize relevant extensions itself, so it doesn’t need to do anything during SpringBoot/Spring assembly.

Log framework support parsing

Support for the log framework is the focus of TLog, mainly in the tlog-core module. There are three TLog access modes: JavaAgent access, bytecode access, and adaptive access. Access mode and corresponding class, as shown below:

In fact, it can be found that JavaAgent also uses bytecode in essence, the difference is that javaAgent JAR package is external, without project dependence. Bytecode, on the other hand, relies on and is triggered manually by adding AspectLogenance.Enhance () code to the launch class.

You can also see that the JavaAgent mode and bytecode mode do not currently support asynchronous logging. This is supported only in adaptation mode.

Some of you might wonder why the diagram above doesn’t mention log base 4j2.

A: Because log4j2, as mentioned earlier, is plug-in form, essentially. Log4j2 takes effect in only one way. Log4j2 automatically detects plug-ins. Strictly speaking, log4j2 log enhancement does not belong to any of the above methods. You don’t need any assembly, you don’t need any trigger conditions, you just need to define the relevant plug-ins. Plugins for log4j2 are defined in the following package for tlog-core:

com.yomahub.tlog.core.enhance.log4j2
Copy the code

MDC nodes in the Log framework

TLog also supports MDC for three logging frameworks. The three support classes can be found in the following path

log4j: com.yomahub.tlog.core.enhance.log4j.AspectLog4jMDCPatternConverter
logback: com.yomahub.tlog.core.enhance.logback.AspectLogbackMDCConverter
log4j2: com.yomahub.tlog.core.enhance.log4j2.AspectLogLog4j2MDCConverter
Copy the code

Note that these three classes do not work directly with MDC. Their purpose is to check whether the log configuration uses MDC

Useful if a configuration file is detected the MDC, set a flag in the TLog thread online

TLogContext.setHasTLogMDC(true);
Copy the code

The real handler of MDC is the TLogRPCHandler class, which is an abstraction layer for all RPC calls and contains the following code for MDC processing logic:

.// If there are MDC nodes, add log labels to the MDC nodes
if (TLogContext.hasTLogMDC()) {
   MDC.put(TLogConstants.MDC_KEY, tlogLabel);
}
Copy the code

If this flag is true, the value is set using slF4J’s MDC API

RPC support

TLog supports RPC mainly by using the interceptors and filters of each RPC framework.

dubbo/dubbox

Dubbo and Dubbox are implemented using dubboFilter, and their principles are the same. The code is pretty much the same. Because the package path and individual class naming is different, so divided into two modules, here put together

Its main processing classes are TLogDubboFilter and TLogDubboxFilter. As mentioned earlier, Dubbo/Dubbox has its own SPI to detect plug-ins. The dubbo plug-in is defined as follows:

@Activate(group = {CommonConstants.PROVIDER, CommonConstants.CONSUMER}, order = -10000)
public class TLogDubboFilter extends TLogRPCHandler implements Filter {... }Copy the code

Dubbo /dubbox is divided into provider and consumer, A->B, A is consumer, B is provider. The processing logic of the two ends is different.

Provider side: accept the parameters in implicit arguments > process parameters > thread context in tlog > call the original business logic

Consumer side: Get arguments from the Tlog thread context –> process arguments –> invoke remote business logic

feign/http

In the spring Cloud Feign scenario, the feign is typically used as the consumer and the controller as the provider. So let’s put these two together.

Feign’s main processing class is TLogFeignFilter, which, as a consumer, basically does the following:

Get parameters from the Tlog thread context –> parameter processing –> put HTTP headers –> request HTTP

The Controller class is mainly TLogWebInterceptor. As a provider, it does the following things:

Receive tag parameters from HTTP headers -> process parameters -> place tlog thread context -> invoke original business logic

Custom labels

Custom labels are a feature module in TLog, which allows users to customize labels and add them to logs.

Its main processing class is just one AOP, AspectLogAop, located in tlog-core.

The idea is to cut the @tLogAspect tag, then parse the related parameters, and finally append the result to the tag value in the thread context.

This involves annotation parsing, point operator parsing and value acquisition operations. To find out, just look at AspectLogAop.

Other features

TLog has other ancillary functions as well.

Support for MQ middleware: the code is in the com.yomahub.tlog.core. Mq package of tlog-core

Automatic printing of parameters and call times: Under the filter of RPC, there is the XxxInvokeTimeFilter class

Asynchronous thread support/thread pool support: code in tlog – the core com. Yomahub. Tlog. Core. In the thread

Custom TraceId generator: the code is in com.yomahub.tlog.id of tlog-common

The code understanding of all of the above functions, combined with the use of documentation to read and understand, should be easy to understand, not to interpret

About me

I’m an open source author and a content creator. “Yuan People tribe” is a adhere to do original technology and technology sharing number, will always share original technical articles, grow with you.