Question

对于在云中运行的微服务，管理应用程序配置是至关重要的，因为微服务实例需要以最少的人为干预快速启动。每当人们需要手动配置或接触服务以实现部署时，都有可能出现配置漂移、意外中断以及应用程序响应可伸缩性挑战出现延迟的情况。

通过建立要遵循的 4 条原则，我们来开始有关应用程序配置管理的讨论。

（1） 分离 ——我们希望将服务配置信息与服务的实际物理部署完全分开。应用程序配置不应与服务实例一起部署。相反，配置信息应该作为环境变量传递给正在启动的服务，或者在服务启动时从集中式存储库中读取。

（2） 抽象 ——将访问配置数据的功能抽象到一个服务接口中。应用程序使用基于 REST 的 JSON 服务来检索配置数据，而不是编写直接访问服务存储库的代码（也就是从文件或使用 JDBC 从数据库读取数据）。

（3） 集中 ——因为基于云的应用程序可能会有数百个服务，所以最小化用于保存配置信息的不同存储库的数量至关重要。将应用程序配置集中在尽可能少的存储库中。

（4） 稳定 ——因为应用程序的配置信息与部署的服务完全隔离并集中存放，所以不管采用何种方案实现，至关重要的一点就是保证其高可用和冗余。

要记住一个关键点，将配置信息与实际代码分开之后，开发人员将创建一个需要进行管理和版本控制的外部依赖项。我总是强调应用程序配置数据需要跟踪和版本控制，因为管理不当的应用程序配置很容易滋生难以检测的 bug 和计划外的中断。

偶发复杂性

我亲身体验过缺乏管理应用程序配置数据策略的危险。在某家财富 500 强金融服务公司工作期间，我被要求帮助一个大型 WebSphere 升级项目回到正轨。该公司在 WebSphere 上有超过 120 个应用程序，并且该公司需要在整个应用程序环境在供应商的维护期终止之前，将其基础设施从 WebSphere 6 升级到 WebSphere 7。

这个项目已经进行了 1 年，花费了 100 万美元的人力和硬件成本，只部署了 120 个应用程序中的 1 个。按照目前的轨迹，还需要两年时间才能完成升级。

当我开始与应用程序团队一起工作时，我发现的一个主要问题（也是仅有的一个问题），应用程序团队在属性文件中管理其数据库的所有配置以及其服务的端点。这些属性文件是手工管理的，不受源代码控制。120 个应用程序分布在 4 个环境中，每个应用程序有多个 WebSphere 节点，这个配置文件的“鼠巢”导致团队试图迁移 12 000（你没有看错，确实是 12 000）个配置文件，这些配置文件散落在数百个服务器以及运行在服务器上的应用程序中。这些文件仅用于应用程序的配置，甚至不包括应用程序服务器的配置。

我说服项目发起人，用两个月的时间将所有应用程序信息整合到具有 20 个配置文件的集中版本控制的配置库中。当我询问框架团队究竟是怎么形成这 12 000 个配置文件的境况时，该团队的首席工程师说，最初他们围绕一小部分应用程序设计了配置策略，但构建和部署的 Web 应用程序的数量在 5 年内爆炸式增长，尽管他们申请资金和时间来重新设计配置管理方法，但他们的业务合作伙伴和 IT 领导者从未将这件事视为优先事项。

不花时间来弄清楚如何进行配置管理可能会产生实实在在（而且代价昂贵）的下游影响。

3.1.1 配置管理架构

从第 2 章中可以看出，微服务配置管理的加载发生在微服务的引导阶段。作为回顾，图 3-1 展示了微服务生命周期。

图 3-1 应用程序配置数据在服务引导阶段被读取

我们先来看一下之前在 3.1 节中提到的 4 条原则（分离、抽象、集中和稳定），看看这 4 条原则在服务引导时是如何应用的。图 3-2 更详细地探讨了引导过程，并展示了配置服务在此步骤中扮演的关键角色。

图 3-2 配置管理概念架构

在图 3-2 中，发生了以下几件事情。

（1）当一个微服务实例出现时，它将调用一个服务端点来读取其所在环境的特定配置信息。配置管理的连接信息（连接凭据、服务端点等）将在微服务启动时被传递给微服务。

（2）实际的配置信息驻留在存储库中。基于配置存储库的实现，可以选择使用不同的实现来保存配置数据。配置存储库的实现选择可以包括源代码控制下的文件、关系数据库或键值数据存储。

（3）应用程序配置数据的实际管理与应用程序的部署方式无关。配置管理的更改通常通过构建和部署管道来处理，其中配置的更改可以通过版本信息进行标记，并通过不同的环境进行部署。

（4）进行配置管理更改时，必须通知使用该应用程序配置数据的服务，并刷新应用程序数据的副本。

现在，我们已经完成了概念架构，这个概念架构阐示了配置管理模式的各个组成部分，以及这些部分如何组合在一起。我们现在要继续看看这些模式的不同解决方案，然后看一下具体的实现。

3.1.2 实施选择

幸运的是，开发人员可以在大量久经测试的开源项目中进行选择，以实施配置管理解决方案。我们来看一下几个不同的方案选择，并对它们进行比较。表 3-1 列出了这些方案选择。

表 3-1 用于实施配置管理系统的开源项目

项目名称	描 述	特 点
Etcd	使用 Go 开发的开源项目，用于服务发现和键值管理，使用 raft 协议作为它的分布式计算模型	非常快和可伸缩 可分布式 命令行驱动 易于搭建和使用
Eureka	由 Netflix 开发。久经测试，用于服务发现和键值管理	分布式键值存储 灵活，需要费些功夫去设置 提供开箱即用的动态客户端刷新
Consul	由 Hashicorp 开发，特性上类似于 Etcd 和 Eureka，它的分布式计算模型使用了不同的算法（SWIM 协议）	快速 提供本地服务发现功能，可直接与 DNS 集成 没有提供开箱即用的动态客户端刷新
ZooKeeper	一个提供分布式锁定功能的 Apache 项目，经常用作访问键值数据的配置管理解决方案	最古老的、最久经测试的解决方案 使用最为复杂 可用作配置管理，但只有在其他架构中已经使用了 ZooKeeper 的时候才考虑使用它
Spring Cloud Config	一个开源项目，提供不同后端支持的通用配置管理解决方案。它可以将 Git、Eureka 和 Consul 作为后端进行整合	非分布式键值存储 提供了对 Spring 和非 Spring 服务的紧密集成 可以使用多个后端来存储配置数据，包括共享文件系统、Eureka、Consul 和 Git

表 3-1 中的所有方案都可以轻松用于构建配置管理解决方案。对于本章和本书其余部分的示例，都将使用 Spring Cloud 配置服务器。选择这个解决方案出于多种原因，其中包括以下几个。

（1）Spring Cloud 配置服务器易于搭建和使用。

（2）Spring Cloud 配置与 Spring Boot 紧密集成。开发人员可以使用一些简单易用的注解来读取所有应用程序的配置数据。

（3）Spring Cloud 配置服务器提供多个后端用于存储配置数据。如果读者已经使用了 Eureka 和 Consul 等工具，那么可以将它们直接插入 Spring Cloud 配置服务器中。

（4）在表 3-1 所示的所有解决方案中，Spring Cloud 配置服务器可以直接与 Git 源控制平台集成。Spring Cloud 配置与 Git 的集成消除了解决方案的额外依赖，并使版本化应用程序配置数据成为可能。

其他工具（Etcd、Consul、Eureka）不提供任何类型的原生版本控制，如果开发人员想要版本控制的话，则必须自己去建立它。如果读者使用 Git，那么使用 Spring Cloud 配置服务器是一个很有吸引力的选择。

对于本章的其余部分，我们将要完成以下几项工作。

（1）创建一个 Spring Cloud 配置服务器，并演示两种不同的机制来提供应用程序配置数据，一种使用文件系统，另一种使用 Git 存储库。

（2）继续构建许可证服务以从数据库中检索数据。

（3）将 Spring Cloud 配置服务挂钩（hook）到许可证服务，以提供应用程序配置数据。