基于Spring Boot的应用环境感知自识别配置（转）

1.Spring Boot应用集成etcd配置源

在分布式、云化的系统里，应用的配置（尤其是依赖服务的配置、环境相关的配置）都
存储到应用到本地配置文件里会给维护带来很大的麻烦，而且docker更是将本身做成了
镜像，更难以在本地的配置文件里去存储一些部署环境相关的信息。所以通常在整个系
统里会有一个公共的配置服务，配置服务统一集中地维护其他系统的配置信息，再通过
网络分发。Spring Cloud Config就是Spring推出的解决方案，不过在自己的应用里还不想
为此再起Java进行，就选择了较为轻量级的etcd来作为配置服务。

2.Apollo - 携程

Apollo（阿波罗）是携程框架部分研发的分布式配置中心，能够集中化管理应用不同环境
、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理
等特性，适用于微服务配置管理场景。

3.Spring Boot自定义配置属性源（PropertySource）

配置覆盖优于profile
在生产实践中，配置覆盖是解决不同环境不同配置的常用方法。比如用生产服务器上的配置
文件覆盖包内文件，或者使用中心化的配置服务来覆盖默认的业务配置。

相比于profile机制，即不同环境使用不同的配置文件，覆盖的方式更有优势。程序员在开发
时不需要关心生产环境数据库的地址、账号等信息，一次构建即可在不同环境中运行，而
profile机制需要将生产环境的配置写到项目资源文件中，而且要为不同环境使用不同的构建
参数或者运行参数。

Spring提供了灵活的配置扩展能力，有多种方式将自定义的属性源集成进来，可以轻松实现
配置覆盖。

自定义属性源工厂

如果想要更加灵活的自定义属性源，比如实现从中心化的配置服务加载配置，可以通过实现
PropertySourceFactory接口，并通过配置@PropertySource注解的factory参数来实现。

4.Spring Boot自定义配置源

概述

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

实现方式

1.通过 EnvironmentPostProcessor 接口把我们自定义的PropertySource加入Environment中
（相对简单但没有那么“优雅”）
2.参考Spring Cloud中的做法，也只需要3步（相对比较复杂一点）

小结

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

祝玩得开心！^_
2017.10.4

原文地址：https://www.jianshu.com/p/c332efc4e5ec