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 管理。这样再也不怕在本地配置文件中出现敏感信息啦，再也不怕修改配置文件需要登录每一台机器修改啦。
祝玩得开心！ˇˍˇ
云舒，2017.10.4，杭州
