通过判断NACOS_SVR这个环境变量是否有值来决定服务启动时是从nacos读取配置还是读本地配置文件

[beihai23]

通过判断NACOS_SVR这个环境变量是否有值来决定服务启动时是从nacos读取配置还是读本地配置文件
NACOS_SVR: nacos服务地址，如：192.168.1.19:8848
NACOS_NS: nacos的namespace
NACOS_DATA-ID: 在nacos中的配置key
NACOS_GROUP：在nacos中的配置所属的group

除些之外，通过以下环境变量还可以进一步控制dtm服务作为nacos客户端时的行为
NACOS_TIMEOUT-MS
NACOS_LOG-DIR
NACOS_CACHE-DIR
NACOS_ROTATE-TIME
NACOS_MAX-AGE
NACOS_LOG-LEVEL

[yedf2]

如果dtm支持nacos，那么会不会还要支持etcd、consul、eureka等等？这么支持的话，那工作量和最终的程序体积就大了

关于配置应当从哪读取，一般像mysql、redis都会只支持从配置文件（传统方式）和环境变量（兼容docker）中读取，而不会负责兼容nacos或者其他注册中心。

[beihai23]

其他的几种配置中心的支持也可以慢慢加上的。我觉得这个是好的方向。就工作量来说不是很大吧，一点点来。
最终的程序体积就更不用担心，这些支持只是整合客户端的代码，对于一个后端服务的中间件来说，程序体积的稍微增加实在不是要担心的地方。

的确最linux范儿的配置方式是接收命令行参数 + 配置文件。 考虑到docker的话，从环境变量来读取。
但是在微服务的场景下，从配置中心读取也是非常常见的做法。而且我这个实现是通过环境变量来判断和控制。和常用做法并不是背道而驰的。

[yedf2]

我建议你这么做
Conf2yml nacos ... conf.yaml && dtm
前面这个程序从配置中心拉取配置，保存到文件，然后dtm从配置文件读取
这种方案开发量小，灵活，可适配mysql redis等各个程序

[beihai23]

这个思想不错，我觉得可以再扩展一下。
dtm在启动后从标准输入读取配置的内容（或者通过一个命令行参数来控制这个行为）。
然后就可以完全用linux style的管道来导入配置。
readconfcenter -s nacos | dtm --stdin-conf

从配置中心读取配置的工作交由独立的程序来完成（暂定：readconfcenter）

[yedf2]

您的新想法非常好，只是目前很少程序采用从stdin读取配置的，我猜想，其中一个原因是没有文件扩展名，那么stdin的格式目前没有好的约定，例如是yml还是json。
您可以在公司内部去实践这样的做法，像dtm这种通用程序，按照mysql之类的来，采用配置文件，大家上手更快

[li-xiao-shuang]

close