1 目录对立
零碎中有一个对立的目录构造相对是必要的,我见过很多我的项目对目录构造齐全没有定义,每个开发人员都按本人的爱好规定随便的定义目录在哪里。
这样会产生很多的问题,对于零碎日后的保护,环境中问题的排查都会产生妨碍。
因而目录的环境肯定要有法则,这样不论是排查问题,还是为了当前的保护,都是无益的。
我遇见过的目录对立的类型分为五种
- 零碎依赖服务的装置门路,例如 mysql、redis 等,如果是本人来装置,须要提前布局好目录地位
- 零碎依赖服务产生或者依赖的文件
- 零碎本身服务的装置门路
- 零碎本身服务产生或者依赖的文件
- 系统集成的 jar 产生或者依赖的文件
2 以 nacos 和 arthas 为例解决产生的文件地位抵触问题
如果面临的环境复杂多变,不倡议过于依赖 arthas,目前框架中曾经移除。
nacos 和 arthas 两个产生文件的典型依赖模块,就是上述说的第五点。
nacos 会在主目录生成两个文件夹
$HOME/nacos
,配置文件地址$HOME/logs
,日志文件地址
arthas 会生成三个文件夹
- arthas 日志地址
- arthas-cache 日志地址
- arthas-output 地址
对于 nacos 和 arthas 这两个服务,对这几个地位都提供了环境变量设置,有些在文档里,有些并不在,只能本人翻源码去找,甚至还有些变量文档外面有,然而曾经不能用了,还是要到源码外面找。
这些目录中,非日志的目录配置应用环境变量我能了解,然而对于日志为什么也须要配置我就不明确了,我见过的所有模块都是只打印日志,然而不对日志进行配置,交由用户本人去配置日志。
nacos 和 arthas 都有本人的 logback.xml 日志配置文件,令人费解。
对此我提交了 issues 给 nacos(最初曾经做出了解释,然而并没有提供解决上面问题的计划)。
最大的问题是, 文件抵触 。
当一个用户上面,部署多个本身零碎的服务并且都应用了 nacos 或者 arthas 时,多个文件就会输入在一个地位,齐全无奈确定是哪个服务正在打印,尽管你可能不会去看这个文件,然而不代表不必去解决它。
一开始想到过应用 spring.application.name
的变量辨别目录地位,然而这两个依赖应用变量时用的是 System
,而 spring.application.name
只在 spring 设置的阶段后失效,然而 nacos 在该变量未设置之前就获取了,所以获取该值只能是 spring.application.name_IS_UNDEFINED
。
我想到的第一个解决办法是利用 PID 环境变量:
-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}
这样的办法尽管能解决,然而常常重启,PID
扭转频繁,不是长久之计。
在通过一段时间的摸索之后,我在框架中提供了一个主动装载类 framework:cn.framework.config.GlobalCommonVarConfig
,动静的设置这几个变量的值,这个类的代码也凋谢在了下面的 issue 中。
该主动装载类失效的条件如下:
- 须要通过在
spring.factories
配置org.springframework.cloud.bootstrap.BootstrapConfiguration
,否则不能在 nacos 之前让变量失效 - 须要增加
@AutoConfigureBefore(NacosConfigBootstrapConfiguration.class)
仍然是为了保障在 nacos 读取到变量之前失效 - 须要增加
@AutoConfigureAfter(Environment.class)
须要保障 spring 的变量初始化实现后失效,否则不能获取到spring.application.name
的值
满足以上三点后,就可能动静的配置文件门路,不必在我的项目中增加额定的环境变量,如果有其它依赖也有相似的问题,雷同的思路仍然可应用。
除此之外,GlobalCommonVarConfig
还增加了两个配置 nacos 域的读取形式,应用的前提是每个模块上面的 bootstrap.yml
配置 spring.cloud.nacos.config.namespace
须要是固定值 ${nacosNamespace:vte-server}
,否则不会失效。
- 第一个是读取
${HOME}/.server.namespace
文件,配置这个是为了多我的项目在同一个用户下,在扭转域的时候,不必为每个我的项目都独自配置域 - 第二个是间接设置
nacosNamespace
的变量值,如果一个用户下须要同时启动两个雷同的模块,然而须要拜访不同的域,就能够应用该办法
如果都不设置,就会应用配置文件中变量配置的默认值。
本文参加了思否技术征文,欢送正在浏览的你也退出。