14.1 共享配置

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

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

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

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

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

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

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

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

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

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

最后更新于