14.3 消费共享配置

除了提供中心化的配置服务器，Spring Cloud Config Server还提供了一个客户端库，它会包含在Spring Boot应用的构建文件中，允许应用成为Config Server的客户端。

将Spring Boot应用变成Config Server客户端的最简单方式就是添加如下的依赖到项目的Maven构建文件中：

<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-config</artifactId>
</dependency>

相同的依赖也可以在Spring Initializr中通过选择标签为Config Client的复选框添加进来。

当应用启动的时候，自动配置功能将会自动化地注册一个属性源，该属性源将会从Config Server中拉取属性。默认情况下，它会假定Config Server运行在localhost并监听8888端口。如果情况并非如此，我们可以通过设置spring.cloud.config.uri配置Config Server的位置：

spring:
  cloud:
    config:
      uri: http://config.tacocloud.com:8888

需要清楚一点，这些属性必须要放到Config Server客户端应用的本地，比如随每个微服务打包和部署的application.yml或application.properties文件中。

现在，我们有了一个中心化的配置服务器，几乎所有的配置都将会由它来提供，每个微服务都不需要携带很多自己的配置了。正常情况下，我们只需要设置spring.cloud.config.uri属性来指定配置服务器的地址并设置spring.application.name属性为配置服务器指明当前应用即可。

哪个优先：Config Server还是服务注册中心？

我们正在设置微服务，让它们通过Config Server了解Eureka服务注册中心在什么地方。这是一种通用的方式，能够避免在应用的每个微服务中重复服务注册中心的细节信息。

同时，我们还可能会将Config Server本身注册到Eureka中，并让每个微服务像发现其他服务那样去查找Config Server。如果你喜欢这种模式，就需要将Config Server变成服务发现的客户端，并将spring.cloud.config.discovery.enabled属性设置为false。这样的话，ConfigServer会将自身以“configserver”名称注册到Eureka中。

这种方式的缺点在于，每个服务在启动的时候都要调用两次外部的服务：第一次调用Eureka发现Config Server的位置，第二次调用Config Server获取配置数据。

当应用启动的时候，Config Server客户端提供的属性源将会对Config Server发送请求。它所接收到的属性将会放到应用的环境之中。除此之外，这些属性实际上还会被缓存起来，即便Config Server停机，它们依然是可用的（我们将会在14.6节看一下在属性发生变更的时候，刷新它们的几种方式）。

到目前为止，Config Server提供的配置都非常简单，面向所有的应用和所有的profile。但有时候，我们需要提供特定应用专有的配置，或者提供当应用在特定profile处于激活状态时才可用的配置。我们看一下Config Server的另一面，看看使用它的几种方式，包括提供特定应用和特定profile的属性。