基于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

概述

如果我们有远程配置，如何把她引入进来呢。

实现方式

1. 通过 EnvironmentPostProcessor 接口把我们自定义的 PropertySource 加入 Environment 中（相对简单但没那么“优雅”）

2. 参考 Spring Cloud 中的做法，也只需要 3 步（相对比较复杂一点）

小结

上面只是抛砖引玉，这样无论是哪里的数据源，都可以通过这种方式编写，把配置交给 Spring 管理。这样再也不怕在本地配置文件中出现敏感信息啦，再也不怕修改配置文件需要登录每一台机器修改啦。

作者：云舒Lee
链接：https://www.jianshu.com/p/c332efc4e5ec