Spring微服务实战第3章 使用Spring Cloud配置服务器控制配置

第3章　使用Spring Cloud配置服务器控制配置

本章主要内容

• 将服务配置与服务代码分开
• 配置Spring Cloud配置服务器
• 集成Spring Boot微服务
• 加密敏感属性

在某种程度上来说，开发人员是被迫将配置信息与他们的代码分开的。毕竟，自上学以来，他们就一直被灌输不要将硬编码带入应用程序代码中的观念。许多开发人员在应用程序中使用一个常量类文件来帮助将所有配置集中在一个地方。将应用程序配置数据直接写入代码中通常是有问题的，因为每次对配置进行更改时，应用程序都必须重新编译和重新部署。为了避免这种情况，开发人员会将配置信息与应用程序代码完全分离。这样就可以很容易地在不进行重新编译的情况下对配置进行更改，但这样做也会引入复杂性，因为现在存在另一个需要与应用程序一起管理和部署的制品。

许多开发人员转向低层级的属性文件（即YAML、JSON或XML）来存储他们的配置信息。这份属性文件存放在服务器上，通常包含数据库和中间件连接信息，以及驱动应用程序行为的相关元数据。将应用程序分离到一个属性文件中是很简单的，除了将配置文件放在源代码控制下（如果需要这样做的话），并将配置文件部署为应用程序的一部分，大多数开发人员永远不会再对应用程序配置进行实施。

这种方法可能适用于少量的应用程序，但是在处理可能包含数百个微服务的基于云的应用程序，其中每个微服务可能会运行多个服务实例时，它会迅速崩溃。

配置管理突然间变成一件重大的事情，因为在基于云的环境中，应用程序和运维团队必须与配置文件的“鼠巢”进行斗争。基于云的微服务开发强调以下几点。

（1）应用程序的配置与正在部署的实际代码完全分离。

（2）构建服务器、应用程序以及一个不可变的镜像，它们在各环境中进行提升时永远不会发生变化。

（3）在服务器启动时通过环境变量注入应用程序配置信息，或者在微服务启动时通过集中式存储库读取应用程序配置信息。

本章将介绍在基于云的微服务应用程序中管理应用程序配置数据所需的核心原则和模式。

3.1　管理配置（和复杂性）

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

通过建立要遵循的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中，发生了以下几件事情。

（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）到许可证服务，以提供应用程序配置数据。

3.2　构建Spring Cloud配置服务器

Spring Cloud配置服务器是基于REST的应用程序，它建立在Spring Boot之上。Spring Cloud配置服务器不是独立服务器，相反，开发人员可以选择将它嵌入现有的Spring Boot应用程序中，也可以在嵌入它的服务器中启动新的Spring Boot项目。

首先需要做的是建立一个名为confsvr的新项目目录。在confsvr目录中创建一个新的Maven文件，该文件将用于拉取启动Spring Cloud配置服务器所需的JAR文件。代码清单3-1列出的是关键部分，而不是整个Maven文件。

代码清单3-1　为Spring Cloud配置服务器创建pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://
    ➥  maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.thoughtmechanix</groupId>
  <artifactId>configurationserver</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <packaging>jar</packaging>

  <name>Config Server</name>
  <description>Config Server demo project</description>

  <parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>1.4.4.RELEASE</version>    ⇽---  将要使用的Spring Boot版本
  </parent>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-dependencies</artifactId>
        <version>Camden.SR5</version>    ⇽---  将要使用的Spring Cloud版本
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <start-class>com.thoughtmechanix.confsvr.
    ➥  ConfigServerApplication </start-class>    ⇽---  配置服务器将要使用的引导类
    <java.version>1.8</java.version>