14.1 共享配置

正如您在第 5 章中看到的那样，您可以在几个不同的属性配置来源中，通过设置具体属性字段来配置 Spring 应用程序。如果配置的属性需要更改，或在不同运行时环境有不同值，使用 Java 系统属性或操作系统的环境变量，是比较合适的。对于不太可能改变的属性，或特定于应用程序的值，将这些属性放置在 application.properties 或 application.yml 中，然后与应用程序一起打包部署，也是个不错的选择。

对于简单的应用程序，这些选择是可以的。但是当你设置系统环境变量或 Java 系统属性时，您必须接受：要更改这些属性将需要重新启动应用程序。如果您选择将属性配置打包到 JAR 或 WAR 文件中，一旦这些属性需要更改，则必须重新打包部署应用程序。如果您需要回滚对配置的更改，也会受到上述约束。

这些限制在某些应用中是可以接受的。在其他情况下，仅仅为了更改一个简单的属性而重启应用程序，是不方便的，也是有缺陷的。此外，在微服务架构的应用程序中，属性管理分布在多个代码库和部署实例中，使得要在多个服务的每个实例中，重复进行相同的更改是不合理的。

某些属性还可能是敏感信息，例如：数据库密码和其他类型的机密值。尽管这些值在写入单个应用程序属性时可以加密，但应用程序在能够被调用前必须包含解密能力。即使这样，有些属性可能需要对应用程序开发人员保密，因此在环境变量中设置它们，或者使用与其他程序相同的版本控制系统来管理它们，都是非常不可取的。

相反，在集中式配置管理时，请考虑这些场景是如何运行的：

• 配置不再与应用程序代码一起打包和部署，使更改或回滚配置成为可能，而无需重建或重新部署应用程序。配置可以随时更改，而无需 重新启动应用程序。

• 共享公共配置的微服务不需要管理自己的配置副本，可以共享相同的属性。如果需要更改属性，可以在单个位置修改，修改会适用于所有微服务。

• 敏感配置信息可以加密，并与应用程序代码解耦。未加密的值可以按需提供给应用程序，而不是要求应用程序携带解密代码。

Spring Cloud Config Server 提供了一个集中式配置服务，让微服务可以依赖于它们。因为它是集中式、一站式配置，在所有服务中都能用，而且也能够提供特定于服务的单独配置。

使用 Config Server 的第一步是把它创建并运行起来。