一、为什么要统一管理微服务配置
对于传统的单体应用，我们常使用配置文件管理所有配置。例如一个Spring Boot开发的单体应用，我们可将配置内容放在application.yml文件中。如果需要切换环境，我们可设置多个Profile，并在启动应用时指定spring.profiles.active={profile}。在本书《Eureka Server的高可用》一节，我们使用的也是这种方式。当然，我们也可借助Maven的Profile实现环境切换。
然而，在微服务架构中，微服务的配置管理一般有以下需求：
(1) 集中管理配置。一个使用微服务架构的应用系统可能会包含成百上千个微服务，因此集中管理配置是非常有必要的；
(2) 不同环境，不同配置。例如，数据源配置在不同的环境（开发、测试、预发布、生产等）中是不同的；
(3) 运行期间可动态调整。例如，我们可根据各个微服务的负载情况，动态调整数据源连接池大小或熔断阈值，并且在调整配置时不停止微服务；
(4) 配置修改后可自动更新。如配置内容发生变化，微服务能够自动更新配置。
综上所述，对于微服务架构而言，一个通用的配置管理机制是必不可少的，常见做法是使用配置服务器帮助我们管理配置。
二、Spring Cloud Config简介
Spring Cloud Config为分布式系统外部化配置提供了服务器端和客户端的支持，它包括Config Server和Config Client两部分。由于Config Server和Config Client都实现了对Spring Environment和PropertySource抽象的映射，因此，Spring Cloud Config非常适合Spring应用程序，当然也可与任何其他语言编写的应用程序配合使用。
Config Server是一个可横向扩展、集中式的配置服务器，它用于集中管理应用程序各个环境下的配置，默认使用Git存储配置内容（也可使用Subversion、本地文件系统或Vault存储配置，限于篇幅，本书不作讨论），因此可以很方便地实现对配置的版本控制与内容审计。
Config Client是Config Server的客户端，用于操作存储在Config Server中的配置属性。
图9-1 Spring Cloud Config架构图
如图9-1，所有的微服务都指向Config Server。各个微服务在启动时，会请求Config Server以获取所需要的配置属性，然后缓存这些属性以提高性能。
三、编写Config Server
本节我们来编写一个Config Server。在本例中，我们使用Git作为Config Server的后端存储。
(1) 在Git仓库https://git.oschina.net/itmuch/spring-cloud-config-repo 中新建几个配置文件，例如：
为了测试版本控制，我们为该Git仓库创建config-label-v2.0分支，并将各个配置文件中的1.0改为2.0。
(2) 创建一个Maven工程，ArtifactId是microservice-config-server ，并为项目添加以下依赖。
(3) 编写启动类，在启动类上添加注解@EnableConfigServer，声明这是一个Config Server。
(4) 编写配置文件application.yml，并在其中添加以下内容。
这样，一个Config Server就完成了。
Config Server的端点
我们可使用Config Server的端点获取配置文件的内容。端点与配置文件的映射规则如下：
以上端点都可以映射到{application}-{profile}.properties 这个配置文件，{application} 表示微服务的名称，{label} 对应Git仓库的分支，默认是master。
按照以上规则，对于本例，我们可使用以下URL访问到Git仓库master分支的microservice-foo-dev.properties，例如：
http://localhost:8080/microservice-foo/dev
http://localhost:8080/microservice-foo-dev.properties
http://localhost:8080/microservice-foo-dev.yml
测试
(1) 访问http://localhost:8080/microservice-foo/dev ，可获得如下结果。
从结果我们可以直观地看到应用名称、项目profile、Git label、Git version、配置文件URL、配置详情等信息。
(2) 访问http://localhost:8080/microservice-foo-dev.properties ，返回配置文件中的属性：
(3) 访问http://localhost:8080/config-label-v2.0/microservice-foo-dev.properties ，可获得如下结果：
说明获得了Git仓库config-label-v2.0分支中的配置信息。
至此，我们已成功构建了Config Server，并通过构造URL的方式，获取了Git仓库中的配置信息。
WARNING
需要注意的是，访问http://localhost:8080/microservice-foo/dev ，结果中类似https://git.oschina.net/itmuch/spring-cloud-config-repo/microservice-foo-dev.properties 的URL并不能访问。这是正常的，因为它并不代表配置文件的实际URL路径，而只是一个标识。有兴趣的读者可前往该页面拓展阅读：https://github.com/spring-cloud/spring-cloud-config/issues/571 。
四、编写Config Client
前文我们已经构建了一个Config Server，并使用Config Server端点获取配置内容。本节我们来讨论Spring Cloud微服务如何获取配置信息。
下面我们来编写一个微服务，该微服务整合了Config Client。
(1) 创建一个Maven工程，ArtifactId是microservice-config-client ，并为项目添加以下依赖。
(2) 创建一个基本的Spring Boot启动类。
(3) 编写配置文件application.yml，并在其中添加如下内容。
(4) 创建配置文件bootstrap.yml，并在其中添加如下内容。
其中：
spring.application.name：对应Config Server所获取的配置文件中的{application} ；
spring.cloud.config.uri：指定Config Server的地址，默认是http://localhost:8888 ；
spring.cloud.config.profile：profile对应Config Server所获取的配置文件中的{profile} ；
spring.cloud.config.label：指定Git仓库的分支，对应Config Server所获取配置文件的{label}。
值得注意的是，以上属性应配置在bootstrap.yml，而不是application.yml中。如果配置在application.yml中，该部分配置就不能正常工作。例如，Config Client会连接spring.cloud.config.uri的默认值http://localhost:8888 ，而并非我们配置的http://localhost:8080/ 。
Spring Cloud有一个“引导上下文”的概念，这是主应用程序的父上下文。引导上下文负责从配置服务器加载配置属性，以及解密外部配置文件中的属性。和主应用程序加载application.* (yml或properties)中的属性不同，引导上下文加载bootstrap.* 中的属性。配置在bootstrap.* 中的属性有更高的优先级，因此默认情况下它们不能被本地配置覆盖。
如需禁用引导过程，可设置spring.cloud.bootstrap.enabled=false 。
(4) 编写Controller。
在Controller中，我们通过注解@Value("${profile}") ，绑定Git仓库配置文件中的profile属性。
测试：
(1) 启动microservice-config-server。
(2) 启动microservice-config-client。
(3) 访问http://localhost:8081/profile ，可获得如下的结果。
dev-1.0
说明Config Client能够正常通过Config Server获得Git仓库中对应环境的配置。
