Spring Boot的应用环境感知自识别配置解决方案
1. Spring Boot应用集成etcd配置源
起衣,2018.1.2
在分布式、云化的系统里,应用的配置(尤其是依赖服务的配置、环境相关的配置)都存储到应用的本地配置文件里会给维护带来很大的麻烦,而且 docker 更是将应用本身做成了镜像,更难以在本地的配置文件里去存储一些部署环境相关的信息。所以通常在整个系统里会有一个公共的配置服务,配置服务统一集中地维护其他系统的配置信息,再通过网络分发。Spring Cloud Config 就是 Spring 推出的解决方案,不过在自己的应用里还不想为此再起 Java 进程,就选择了较为轻量级的 etcd 来作为配置服务。
2. Apollo - 携程
Apollo(阿波罗)是携程框架部门研发的分布式配置中心 ,能够集中化管理应用不同环境、不同集群的配置 ,配置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性,适用于微服务配置管理场景。
3. Spring Boot自定义配置属性源(PropertySource)
caosh,2017.12.5
配置覆盖优于profile
在生产实践中,配置覆盖是解决不同环境不同配置的常用方法。比如用生产服务器上的配置文件覆盖包内的文件,或者使用中心化的配置服务来覆盖默认的业务配置。
相比于profile机制,即不同环境使用不同的配置文件,覆盖的方式更有优势。程序员在开发时不需要关心生产环境数据库的地址、账号等信息,一次构建即可在不同环境中运行,而profile机制需要将生产环境的配置写到项目资源文件中,而且要为不同环境使用不同的构建参数或者运行参数。
Spring提供了灵活的配置扩展能力,有多种方式将自定义的属性源集成进来,可以轻松地实现配置覆盖。
自定义属性源工厂
如果想要更加灵活的自定义属性源,比如实现从中心化的配置服务加载配置,可以通过实现 PropertySourceFactory
接口,并通过配置 @PropertySource
注解的 factory 参数来实现。
4. Spring Boot自定义配置源
atheva,2017.10.17
概述
如果我们有远程配置,如何把她引入进来呢。
实现方式
- 通过
EnvironmentPostProcessor
接口把我们自定义的PropertySource
加入Environment
中(相对简单但没那么"优雅") - 参考
Spring Cloud
中的做法,也只需要 3 步(相对比较复杂一点)
小结
上面只是抛砖引玉,这样无论是哪里的数据源,都可以通过这种方式编写,把配置交给 Spring 管理。这样再也不怕在本地配置文件中出现敏感信息啦,再也不怕修改配置文件需要登录每一台机器修改啦,再也不用进行代码变更。
参考
- 深入Spring配置内核,感受抽象的力量 --张建飞(Frank)
祝玩得开心!ˇˍˇ
云舒,杭州