Log framework selection during service splitting

background:

In the recent process of service splitting, many interceptors have log printing because they need to encapsulate common interceptors such as login-related ones into API packages. It stands to reason that there should be no log printing in the api package, but if you remove important logs, it will be difficult to locate online problems.

Solution one:

Originally, the API package provided by our account needed to print some local stub information, such as initializing the cache, whether the local stub fetched the object, and whether the dubbo interface was used. So referring to the solution of the existing framework, I wrote the following logic. Let the relying party initialize this bean when it starts, and then you can use this LogUtil object to print logs.

@Component
public class LogUtil implements InitializingBean {

    public static final Logger accountOpt = LoggerFactory.getLogger("accountOpt");

    @Override
    public void afterPropertiesSet() throws Exception {
        Properties p = new Properties();

        p.setProperty("log4j.category.accountOpt", "INFO"  + ",accountOpt");
        p.setProperty("log4j.appender.accountOpt", "org.apache.log4j.DailyRollingFileAppender");
        p.setProperty("log4j.appender.accountOpt.File", "logs/log/accountOpt.log" );
        p.setProperty("log4j.appender.accountOpt.layout", "org.apache.log4j.PatternLayout");
        p.setProperty("log4j.appender.accountOpt.maxFileSize ", "100MB" );
        p.setProperty("log4j.appender.accountOpt.maxBackupIndex ", " 30");
        p.setProperty("log4j.appender.accountOpt.DatePattern ", " '.'yyyy-MM-dd");
        p.setProperty("log4j.appender.accountOpt.layout.ConversionPattern", "%d - accountOpt - %c - %p [%t] %x - %m%n");

        PropertyConfigurator.configure(p);
    }
}

// use
LogUtil.accountOpt.info("Account userName:" + userName + " is not in cache");

shortcoming:

1) API-dependent services need to rely on log4j to print out logs.

2) The configuration is written dead in the code, which is ugly.

3) The relying party needs to manually initialize this bean.

Solution two:

slf4j (Simple Logging Facade for Java ), the API depends on slf4j, and the relying party only needs to introduce the corresponding slf4j-adapter and the corresponding underlying implementation. slf4j uses the Facade mode, why is it called this mode? Look at the Facade mode definition, define a set of simple interfaces for complex subsystems, the subsystems are the various log implementations below, and the interface is slf4j. I also learned the Facade mode through slf4j.

The architecture is as follows:

Code:

// The relying party only needs to configure accountOpt
Logger logger = LoggerFactory.getLogger("accountOpt");

Advantage:

1) The api does not care about the specific log implementation, and is left to the relying party to implement. The relying party only needs to introduce its own adapter jar and the underlying implementation log.

2) Even if the corresponding log implementation is introduced in the API, the relying party can still exclude the corresponding implementation, make different log implementations, and can print out the logs in the API.

3) If the api already depends on a specific implementation, such as account-api depends on log4j. Then, when the application relies on account-api, it directly excludes log4j and directly introduces slf4j-log4j-adapter, which defines the same interface as the same package as log4j. So the startup will not report an error, and there is no need to rely on the implementation of log4j in account-api. This point was added by Bo Ye when Zhou Hui shared, so I often find that others can often see your shortcomings when sharing, so share it often.

Final choice:

Our final choice is to use slf4j in the API and logback in the implementation, because it is said that logback has much higher performance than log4j.

Log framework selection during service splitting

Guess you like