Microservice Development Series: Directory Structure, Keeping a Clean File Environment

Source address

1 Directory unification

It is absolutely necessary to have a unified directory structure in the system. I have seen many projects that do not define the directory structure at all, and each developer freely defines where the directory is according to their own preferences.

This will cause many problems, which will hinder the future maintenance of the system and the troubleshooting of problems in the environment.

Therefore, the environment of the directory must be regular, so whether it is for troubleshooting or for future maintenance, it is beneficial.

There are five types of directory unity I have encountered

1. The installation path of system-dependent services, such as mysql, redis, etc. If you install it yourself, you need to plan the directory location in advance
2. The files that the system depends on the service to generate or depend on
3. The installation path of the system's own services
4. The files that the system's own services generate or depend on
5. System integration jar generated or dependent files

2 Take nacos and arthas as examples to solve the problem of file location conflicts

If the environment you are facing is complex and changeable, it is not recommended to rely too much on arthas, which has been removed from the framework.

Two typical dependent modules for generating files, nacos and arthas, are the fifth point mentioned above.

nacos will generate two folders in the main directory

1. $HOME/nacos , configuration file address
2. $HOME/logs , log file address

arthas will generate three folders

1. arthas log address
2. arthas-cache log address
3. arthas-output address

For the two services, nacos and arthas, environment variable settings are provided for these locations. Some are in the documentation, some are not. You can only find the source code yourself. There are even some variable documentations, but they are no longer available. Well, you still have to go to the source code to find it.

In these directories, the non-log directory configuration uses environment variables, I can understand, but I don't understand why the log needs to be configured. All the modules I have seen only print the log, but do not configure the log, and leave it to the user. Configure the log yourself.

Both nacos and arthas have their own logback.xml log configuration file, which is puzzling.

In this regard, I submitted issues to nacos (the explanation has been made at the end, but there is no solution to the following problems).

The biggest problem is that file conflicts .

When a user deploys multiple services of its own system and all use nacos or arthas, multiple files will be output in one location, and it is completely impossible to determine which service is printing, although you may not look at this file, But that doesn't mean you don't have to solve it.

At first I thought of using the variable spring.application.name to distinguish the directory location, but these two dependencies use the variable System , and spring.application.name is only set in spring It takes effect after the stage, but nacos gets it before the variable is set, so the value can only be spring.application.name_IS_UNDEFINED .

The first workaround that came to my mind was to utilize the PID environment variable:

 -DSERVER_COMMON.BASE=${HOME}/server-common
-DARTHAS_LOG_PATH=${SERVER_COMMON.BASE:-${HOME}/server-common}/logs/arthas/${PID}
-DRESULT_LOG_FILE=${SERVER_COMMON.BASE:-${HOME}/server-common}/logs/arthas-cache/${PID}/result.log
-DJM.LOG.PATH=${SERVER_COMMON.BASE:-${HOME}/server-common}/logs/nacos/${PID}
# 注意到这里没有使用上面的值相同的变量 ${SERVER_COMMON.BASE}，因此它不支持~，翻看过源码，获取环境变量的方式不对
-DJM.SNAPSHOT.PATH=${HOME}/server-common
-Darthas.outputPath=${SERVER_COMMON.BASE:-${HOME}/server-common}/arthas-output/${PID}

Although this method can be solved, it is often restarted, PID changes frequently and is not a long-term solution.

After a period of exploration, I provided an autoloading class in the framework framework:cn.framework.config.GlobalCommonVarConfig to dynamically set the values of these variables. The code of this class is also open in the above issue.

The conditions for this autoloading class to take effect are as follows:

1. You need to configure org.springframework.cloud.bootstrap.BootstrapConfiguration spring.factories otherwise the variable cannot take effect before nacos
2. Need to add @AutoConfigureBefore(NacosConfigBootstrapConfiguration.class) still to ensure that it takes effect before nacos reads the variable
3. You need to add @AutoConfigureAfter(Environment.class) need to ensure that the spring variables take effect after the initialization is completed, otherwise you cannot get the value of spring.application.name

After meeting the above three points, you can dynamically configure the file path without adding additional environment variables to the project. If there are other dependencies and similar problems, the same idea can still be used.

In addition, GlobalCommonVarConfig also added two ways to configure nacos domain reading, the premise of use is that under each module bootstrap.yml configure spring.cloud.nacos.config.namespace required It is a fixed value ${nacosNamespace:vte-server} , otherwise it will not take effect.

1. The first is to read the ${HOME}/.server.namespace file. This is configured for multiple projects under the same user. When changing the domain, there is no need to configure the domain separately for each project.
2. The second is to directly set the variable value of nacosNamespace . If a user needs to start two identical modules at the same time, but needs to access different domains, this method can be used

If neither is set, the default value configured by the variable in the configuration file will be used.

This article participated in the Sifu technical essay , and you are welcome to join.