14.1 共享配置

就像我们在第5章所看到的那样，我们可以通过多种属性源设置属性来对Spring应用进行配置。如果某个配置属性可能会更改或者只针对运行时环境有效，那么Java系统属性或操作系统环境变量是一个合适的可选方案。对于不太可能发生变化或者应用特定的属性，将它们放到application.yml或application.properties中，随着打包的应用一起部署是一种很好的方案。

这些方案对于简单的应用来说都很不错。但是，当在环境变量或Java系统属性中设置配置属性的时候，我们必须要接受这样一个现实，那就是修改这些属性需要应用重启。如果我们选择将属性打包到要部署的JAR或WAR文件中，那么在属性变更时，我们必须要完全重新构建和重新部署应用。如果我们想要回滚配置变更，那么同样的约束依然有效。

这些约束在有些应用程序中是可以接受的。但是，在有些情况下，如果仅仅是为了修改一个属性就重启应用，往好了说是不太方便，往坏了说则具有破坏性。除此之外，在基于微服务架构的应用中，属性管理会跨越多个代码库和部署实例，因此将相同变更用到应用中多个服务的每个实例中是不现实的。

有些属性是敏感的，比如数据库密码和其他类型的私密信息。尽管这些值作为应用的属性在写入的时候可以进行加密，但是应用在使用它们之前必须要先解密。即便如此，有些属性甚至可能需要对应用开发人员保密。这样的话，将它们设置成环境变量或者将它们与应用的其他代码一起通过源码控制系统进行管理就是不可取的了。

相反，我们可以考虑一下这些场景在集中式的配置管理下会是什么样子。

• 配置不再需要和应用程序代码一起打包和部署。这样的话，配置的变更或回滚就都不需要重新构建和重新部署应用了。配置甚至可以在运行时进行变更，无须重新启动应用。
• 共享通用配置的微服务不需要管理自己的属性设置副本，并且能够管理共享的相同属性。如果需要对属性进行变更，那么这些变更只需在一个地方执行一次就可以应用到所有的微服务上。
• 敏感配置可以进行加密，并且能够与应用代码分开进行维护。应用可以按需获取未加密的值，而不需要应用程序提供解密信息相关的代码。

Spring Cloud Config Server提供了中心化的配置功能，应用中的所有微服务均可以依赖该服务器来获取配置。因为它是中心化的，所以是一个一站式的配置商店，所有的服务都可以使用它，另外它还能够为特定服务提供专门的配置。

使用Config Server的第一步就是创建并运行该服务器。