springboot下配置文件统一加载、管理
博客专区 > ilaotan 的博客 > 博客详情
springboot下配置文件统一加载、管理
ilaotan 发表于10个月前
springboot下配置文件统一加载、管理
  • 发表于 10个月前
  • 阅读 1621
  • 收藏 65
  • 点赞 2
  • 评论 10

腾讯云 技术升级10大核心产品年终让利>>>   

摘要: 好久没写博客了,最近打算把积淀在印象笔记中的东西整理一下,分享出来 此篇是第一篇,场景是springboot微服务下,配置文件统一加载,统一管理

springboot 就不必多说了吧,这货结合dubbo/thrift做微服务棒棒的. 笔者现在做的这个项目就是基于springboot的一堆服务,大约几十个吧. springboot的配置都在application.propertie里,尽管已经约束好了里面的配置,但还有诸多不便性,所以需要一个统一加载机制,来加载公共配置和个性化配置.

springCloud是有这么一套来着.本文就是参考的org.springframework.boot.cloud.CloudFoundryVcapEnvironmentPostProcessor 不过找着这个类也是扒拉了好久源代码.

好了,啰嗦了这么多,开始贴代码了.

public class LoadThirdEnv implements EnvironmentPostProcessor, Ordered {
    @Override
    public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) {
        //此处可以http方式 到配置服务器拉取一堆公共配置+本项目个性配置的json串,拼到Properties里
        //......省略new Properties的过程
       MutablePropertySources propertySources = environment.getPropertySources();
       //addLast 结合下面的 getOrder() 保证顺序 读者也可以试试其他姿势的加载顺序
        propertySources.addLast(new PropertiesPropertySource("thirdEnv", properties));
    }
    @Override
    public int getOrder() {
        //  +1 保证application.propertie里的内容能覆盖掉本配置文件中默认的
        // 如果不想被覆盖 可以去掉 +1  或者 -1  试试
        return ConfigFileApplicationListener.DEFAULT_ORDER + 1;
    }
}

对,没错,就是这么几行. 还不够,还需要在resources/META-INF/spring.factories里添加

org.springframework.boot.env.EnvironmentPostProcessor=\
 com.ilaotan.LoadThirdEnv

好了,完工. springboot的配置文件参数,可以精简到几个. 其他都从http加载.以后需要改参数,直接配置平台改完,重启这个springboot服务即可.

spring.factories 是springboot的一种加载机制.这里不多赘述.

至于http请求的配置平台,实现得很简单,就是发不同的参数,那边返回json串.

共有 人打赏支持
ilaotan
粉丝 10
博文 1
码字总数 474
评论 (10)
wellyao
我使用的Spring Cloud Config。但是确实存在一个问题:公共配置,每个配置文件都会写,比如邮件配置,没必要在每个profile配置文件都配置,只需要配置到公共配置项,你这个方法很好,但是,能否有更优雅的方式,不明白Spring Cloud Config 为啥不出解决方案。
kucoll
可以用disconf阿
开源中国首席董事长
加载配置文件要这么复杂?
TongLau
如果直接使用spring cloud config可能更好,不需要自己实现spring启动加载功能,还可以切换本地和远程配置。
TongLau
我觉得这不是spring的问题,或者有其他办法解决,例如微服务有一个统一配置文件,而激活的部分不同
spring:
application:
name: foo
profiles:
active: dev,mysql

如果是开发环境需要oracle配置
spring:
application:
name: foo
profiles:
active: dev,oracle
dev就是所谓公共部分,mysql和oracle就是个性配置
ilaotan

引用来自“TongLau”的评论

我觉得这不是spring的问题,或者有其他办法解决,例如微服务有一个统一配置文件,而激活的部分不同
spring:
application:
name: foo
profiles:
active: dev,mysql

如果是开发环境需要oracle配置
spring:
application:
name: foo
profiles:
active: dev,oracle
dev就是所谓公共部分,mysql和oracle就是个性配置
那如果有30个项目,用rpc框架通信,其中有个数据库地址需要换,我需要改30个项目的配置文件吧。 单项目就没必要这么折腾了
TongLau

引用来自“TongLau”的评论

我觉得这不是spring的问题,或者有其他办法解决,例如微服务有一个统一配置文件,而激活的部分不同
spring:
application:
name: foo
profiles:
active: dev,mysql

如果是开发环境需要oracle配置
spring:
application:
name: foo
profiles:
active: dev,oracle
dev就是所谓公共部分,mysql和oracle就是个性配置

引用来自“ilaotan”的评论

那如果有30个项目,用rpc框架通信,其中有个数据库地址需要换,我需要改30个项目的配置文件吧。 单项目就没必要这么折腾了
这是策略问题,spring配置提供了集中配置的方法论,看你怎么使用了。
以上面的例子的意思,公共的配置可以写到dev里,个性配置是mysql或者oracle,但对于30个应用集体换数据库配置的这种需求来说,数据库配置应该放到dev里,因为属于公共配置,那么修改一次即可。
另外,还可以使用占位符,增加灵活性,降低可读性。
ilaotan

引用来自“TongLau”的评论

我觉得这不是spring的问题,或者有其他办法解决,例如微服务有一个统一配置文件,而激活的部分不同
spring:
application:
name: foo
profiles:
active: dev,mysql

如果是开发环境需要oracle配置
spring:
application:
name: foo
profiles:
active: dev,oracle
dev就是所谓公共部分,mysql和oracle就是个性配置

引用来自“ilaotan”的评论

那如果有30个项目,用rpc框架通信,其中有个数据库地址需要换,我需要改30个项目的配置文件吧。 单项目就没必要这么折腾了

引用来自“TongLau”的评论

这是策略问题,spring配置提供了集中配置的方法论,看你怎么使用了。
以上面的例子的意思,公共的配置可以写到dev里,个性配置是mysql或者oracle,但对于30个应用集体换数据库配置的这种需求来说,数据库配置应该放到dev里,因为属于公共配置,那么修改一次即可。
另外,还可以使用占位符,增加灵活性,降低可读性。
我不清楚你说的集中配置什么意思,你所谓的分active,在底层其实就是根据active里的字段,load不同的properties。你说只修改公共配置,那30个项目,我得修改1次X30吧。按实际分布式开发来讲,30个项目,分布在上百台机器上,每个项目都部署了好几份。
TongLau

引用来自“TongLau”的评论

我觉得这不是spring的问题,或者有其他办法解决,例如微服务有一个统一配置文件,而激活的部分不同
spring:
application:
name: foo
profiles:
active: dev,mysql

如果是开发环境需要oracle配置
spring:
application:
name: foo
profiles:
active: dev,oracle
dev就是所谓公共部分,mysql和oracle就是个性配置

引用来自“ilaotan”的评论

那如果有30个项目,用rpc框架通信,其中有个数据库地址需要换,我需要改30个项目的配置文件吧。 单项目就没必要这么折腾了

引用来自“TongLau”的评论

这是策略问题,spring配置提供了集中配置的方法论,看你怎么使用了。
以上面的例子的意思,公共的配置可以写到dev里,个性配置是mysql或者oracle,但对于30个应用集体换数据库配置的这种需求来说,数据库配置应该放到dev里,因为属于公共配置,那么修改一次即可。
另外,还可以使用占位符,增加灵活性,降低可读性。

引用来自“ilaotan”的评论

我不清楚你说的集中配置什么意思,你所谓的分active,在底层其实就是根据active里的字段,load不同的properties。你说只修改公共配置,那30个项目,我得修改1次X30吧。按实际分布式开发来讲,30个项目,分布在上百台机器上,每个项目都部署了好几份。
我并没有说你做的不好,只是善意的在叙述,spring cloud config能满足你的需求。
另外,我举配置例子的那个回复是针对一楼来的,也是针对所谓“能否有更优雅的方式”。
最后,你是否可以看一下spring cloud config参考:
http://cloud.spring.io/spring-cloud-static/spring-cloud-config/1.3.0.M1/
这是一个里程碑版本。
我在http://git.oschina.net/dlpin/microservice-example-config放了一个例子,参考user.yml,你能理解我在说什么。
ilaotan

引用来自“TongLau”的评论

我觉得这不是spring的问题,或者有其他办法解决,例如微服务有一个统一配置文件,而激活的部分不同
spring:
application:
name: foo
profiles:
active: dev,mysql

如果是开发环境需要oracle配置
spring:
application:
name: foo
profiles:
active: dev,oracle
dev就是所谓公共部分,mysql和oracle就是个性配置

引用来自“ilaotan”的评论

那如果有30个项目,用rpc框架通信,其中有个数据库地址需要换,我需要改30个项目的配置文件吧。 单项目就没必要这么折腾了

引用来自“TongLau”的评论

这是策略问题,spring配置提供了集中配置的方法论,看你怎么使用了。
以上面的例子的意思,公共的配置可以写到dev里,个性配置是mysql或者oracle,但对于30个应用集体换数据库配置的这种需求来说,数据库配置应该放到dev里,因为属于公共配置,那么修改一次即可。
另外,还可以使用占位符,增加灵活性,降低可读性。

引用来自“ilaotan”的评论

我不清楚你说的集中配置什么意思,你所谓的分active,在底层其实就是根据active里的字段,load不同的properties。你说只修改公共配置,那30个项目,我得修改1次X30吧。按实际分布式开发来讲,30个项目,分布在上百台机器上,每个项目都部署了好几份。

引用来自“TongLau”的评论

我并没有说你做的不好,只是善意的在叙述,spring cloud config能满足你的需求。
另外,我举配置例子的那个回复是针对一楼来的,也是针对所谓“能否有更优雅的方式”。
最后,你是否可以看一下spring cloud config参考:
http://cloud.spring.io/spring-cloud-static/spring-cloud-config/1.3.0.M1/
这是一个里程碑版本。
我在http://git.oschina.net/dlpin/microservice-example-config放了一个例子,参考user.yml,你能理解我在说什么。
×
ilaotan
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: