(二)关于代码中的配置

2021年11月26日 阅读数:2
这篇文章主要向大家介绍(二)关于代码中的配置,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

上一篇中说到java

目前的设计是,基本上除了定时器设置的变更,有可能会修改app-scheduling.xml和spring-servlet.xml文件外,其余的配置都在这个config.properties文件中了python

这一篇就来讲说这块是怎么作的,看config.properties文件。nginx

1.关于logback的配置。spring

之前就写了这块的实现,参考这里。主要就是logback的配置没怎么变化,最多就是由于日志的名称不一样和日志级别,修改config.properties。数据库

2.关于配置文件的想法。api

由于项目部署了不少个tomcat节点,有开发环境、测试环境、生产环境的区别,而生产环境又利用nginx作了不一样模块的区分,部分服务的配置稍微有点改动,这时候在部署上线的时候很麻烦,常常要改动配置文件,恰好项目的其余模块,有别人用python作的,这个模块,有个配置文件config.py,里面就利用字典数组的形式来写配置,指定当前环境,就能够读取到对应的配置,因而脑洞大开,是否也能够作相似的配置。数组

因而在配置文件里加了一个参数curEnv表示当前环境,值设置为.dev或.test或.pro,对于通用的配置,不加后缀,专用的配置就加上对应的配置。好比一个配置apihost=1.2.3.4,由于项目大部分是在生产用,为了便于部署,我把测试环境的配置加上后缀apihost.test=5.6.7.8,默认curEnv=,没有值。这里须要看全局常量类Constants.javatomcat

//系统配置文件
	private static PropertiesConfiguration config;
	private static String curEnv = "";

	static{
		try {
			config = new PropertiesConfiguration();
			config.setEncoding("UTF-8");
			config.load("config.properties");
			config.setReloadingStrategy(new FileChangedReloadingStrategy());
			curEnv = config.getString("curEnv");
		} catch (ConfigurationException e) {
			logger.error("找不到配置文件", e);
		}
	}

	private static String getString(String key) {
		if(config.containsKey(key + curEnv)) {
			return config.getString(key + curEnv);
		}
		return config.getString(key);
	}

	public static String getTestStr() {
		return getString("test.str");
	}

这里,又有另一个东西能够说,就是PropertiesConfiguration,这里用到commons-configuration,之因此用到这块,是为了让部分配置即时生效。之前用普通的properties,正常读取文件是没问题,可是当遇到部分参数须要即时生效的时候,就须要重启tomcat,有时候又不容许随便重启,就要到凌晨去重启,很麻烦,找到这个就能够实现当即生效。在配置文件config.properties里面有中文,因此先设置默认用UTF-8来读取文件。以后设置加载策略config.setReloadingStrategy(new FileChangedReloadingStrategy());就是文件改变的时候从新加载。app

对于须要即时生效的常量,好比这个test.str,采起这种写法是能够实现咱们的效果的,若是写成public static String TESTSTR = getString("test.str");是没用的,我的是这么想的,这个静态变量初始化以后,指向的就是最先使用的值,以后文件的改变,不会触发新的读取。而用方法的形式,每次触发的是getString这个方法,这个方法由于PropertiesConfiguration的管理会读取新值。测试

这个getString方法针对环境变量curEnv改造了一下,含有当前环境包含的配置,就返回,没有就返回默认的。

在这么作了以后,好比我生产环境就不设置了,就用默认的空,在开发环境就用.dev,在测试环境就用.test。基本上除了数据库的配置是在 applicationContext.xml  很差这么加后缀作区分,其余的均可以了。通常数据库的配置,我按照几个环境,就写几个块在config.properties,不用的时候用#注释。

再后来,部署不用本身作了,可是要打包给负责部署的人,每次都修改配置文件也是麻烦,因此就这么作,好比有3个环境,3套配置,就写3个config.properties,就是命名不同,配置内容有点不同,由于通常都在开发环境,因此开发环境的配置文件就命名为config.properties,测试的配置文件命名为config.test.properties,生产的命名为config.pro.properties,在打包的时候,删掉去他无用的配置,把测试或生产的配置文件重命名为config.properties,就能够了。

关于代码中的配置就讲完了。