配置中心

Spring Cloud 入门 ---- Config 配置中心

介绍

微服务意味着要将单体应用中的业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的微服务，由于每个服务都需要必要的配置信息才能运行，所以一套集中式的、动态的配置管理设施是必不可少的。Spring Cloud 提供了 ConfigServer 来解决这个问题。

官网：https://docs.spring.io/spring-cloud-config/docs/2.2.5.RELEASE/reference/html/

是什么

Spring Cloud Config 为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为 的所有环境提供一个 。

怎么用

Spring Cloud Config 分为 和 两部分。

服务端也称为 ，用来连接配置服务器并为客户端提供获取配置信息，加密/解密信息等访问接口。

客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息，配置服务器默认采用 git 来存储配置信息，这样就有助于对环境配置的版本进行管理，并可以通过 git 客户端工具来方便的管理和访问配置内容。

图解：

能干嘛

• 集中管理配置文件
• 不同环境不同配置，动态化的配置更新，分环境部署；比如：dev/test/prod/beta/release
• 运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息
• 当配置发生变动时，服务不需要重启即可感知到配置的变化，并应用新的配置
• 将配置信息以 REST 接口的形式暴露

Config 配置总控中心搭建

创建配置仓库

一、在 github 上创建配置仓库（springcloud-config），并新建几个配置文件

内容如下：以下为演示内容，实际工作中按需要配置。

二、将配置中心内容拉取到本地项目下

创建配置中心模块

导入 pom 依赖

添加 yml 配置文件

主启动 开启基于注解的配置中心功能

启动服务，访问：http://localhost:3344/master/config-dev.yml 如果能够得到配置中心对应的信息，则服务创建成功。

以上我们成功的从配置中心读取到了 分支下的 配置文件；关于配置文件的读取规则将在下面介绍。

配置的读取规则

官网：https://docs.spring.io/spring-cloud-config/docs/2.2.5.RELEASE/reference/html/#_spring_cloud_config_server

/{application}/{profile}[/{label}] /{application}-{profile}.yml /{label}/{application}-{profile}.yml /{application}-{profile}.properties /{label}/{application}-{profile}.properties

label：分支；application：服务名；profile：环境(dev/test/prod)

这里我们重点介绍前面三种：

/{application}/{profile}[/{label}]，例如：http://localhost:3344/config/dev/master 可以看到得到的信息将是一个包含配置信息的 json 串。

/{application}-{profile}.yml，例如：http://localhost:3344/config-dev.yml 可以看到由于没有指定分支，将访问默认的 master 分支下的 config-dev.yml 配置文件，并直接返回配置文件的信息。

/{label}/{application}-{profile}.yml，例如：http://localhost:3344/master/config-dev.yml ，这种我们前面测试过，将返回我们指定的 master 分支【也可以指定其它分支】下的 config-dev.yml 配置文件的信息。

测试了实际存在的文件，接下来我们测试个在 github 中不存在的文件，例如：http://localhost:3344/master/abcdef-dev.yml 可以看到当我们访问的配置文件不存在时，将返回一个空的对象。

以上就是常用的几种配置读取规则的介绍，个人推荐使用第三种：/{label}/{application}-{profile}.yml

Config 客户端配置与测试

创建客户端模块

导入 pom 依赖

创建 bootstrap.yml

application.yml 是用户级的资源配置项；bootstrap.yml 是系统级的，

Spring Cloud 会创建一个 ，作为 Spring 应用的 的 。初始化的时候 负责从外部加载配置属性并解析配置。这两个上下文共享一个外部获取的 。

属性有更高优先级，默认情况下，它们不会被本地配置覆盖。 和 有着不同的约定，所以新增一个 文件，保证 和 配置的分离。

因为 bootstrap.yml 是比 application.yml 先加载的。bootstrap.yml 优先级高于 application.yml。

启动类

业务类

启动服务，访问：http://localhost:3355/configInfo 可以看到通过 bootstrap.yml 指定的配置文件，我们读取到了配置中心中配置文件的信息。

修改 profile 为 test ，重启服务并访问：http://localhost:3355/configInfo 如图：可以看到我们读取到了配置中心 test 环境的配置文件信息。

分布式配置的动态刷新问题

config 配置中心 与 config 客户端启动好后，既可以测试是否能读取 github 上的配置。随之而来的一个问题是：当修改并提交 githup 上的配置信息时，3344 配置中心可以实现自动更新；但是 3355 客户端始终是原来的配置，配置信息没有更新；需要 3355 重启或者重新加载，配置信息才会更新。下面我们将验证这种情况：

一、将环境改回 dev 环境，并访问：http://localhost:3344/master/config-dev.yml 与 http://localhost:3355/configInfo 可以看到读取到的配置中心信息是一致的。

二、修改 github 上 config-dev.yml 的配置信息，修改如下，并访问：http://localhost:3344/master/config-dev.yml 与 http://localhost:3355/configInfo 可以看到 3344配置中心的信息更新了，而 3355 客户端信息还是原来的。

三、重启 3355 客户端，并访问：http://localhost:3344/master/config-dev.yml 与 http://localhost:3355/configInfo 这时可以看到 3344 与 3355 读取到的都是更新后的信息。

通过以上的案例我们证实了 修改 github 上配置信息时，配置中心的信息会实时更新，而客户端信息则不会；需要重启服务才会更新，而重启这种方法明显是不合理的，在生产环境中我们总不能改下配置就重启下服务。在下面我们将介绍具体的解决方案。

Config 动态刷新之手动版

pom 中引入 actuator 监控，若已引入则跳过该步骤

修改 bootstrap.yml ，暴露监控端口号（客户端）：

业务类Controller 中添加注解 @RefreshScope

重新启动客户端，此时修改 github 上配置信息，config 配置中心会自动更新配置信息，客户端需要发送一个："http://localhost:3355/actuator/refresh 请求，即可更新配置信息。下面我我们将来验证：

一、修改 github 上 config-dev.yml 配置信息，如下：

二、访问：http://localhost:3344/master/config-dev.yml 与 http://localhost:3355/configInfo 可以看到 3344 配置中心信息已经更新【虽然产生了中文乱码问题】，3355 依然是之前的配置信息。

三、使用postman 发送一个 post 请求：http://localhost:3355/actuator/refresh ，然后再访问：http://localhost:3355/configInfo 可以发现 3355 的配置信息也已经更新成功。

通过如上实验可知，当更新 github 上的配置文件信息后，我们可以通过发送 post 请求刷新客户端的配置信息；虽然还是有点麻烦，但是相对于重启服务已经算是一个比较能接受的了。但是新的问题随之而来：如果有多个微服务客户端，每个微服务都要执行一次post请求去手动刷新？是否可以广播，一次通知，处处生效？这些问题都将在下一节：Spring Cloud Bus 中解决

Config 配置中心添加安全认证

与 Eureka 类似，我们可以通过整合 SpringSecurity 来为配置中心添加安全认证。

修改 config 配置中心

添加 SpringSecurity pom 依赖

修改 yml 配置spring security登录用户名和密码；由于之前我们 Eureka Client 连接注册中心时添加了这个配置，所以这里不需要重复添加，当然我们也可以将之前 连接 Eureka Client 的用户名 密码配置修改为其它的自定义配置信息，如下：主要修改了 eureka 的 defaultZone 与 security

重启 配置中心模块，访问：http://localhost:3344/config-dev.yml 发现直接进入了登录界面，输入我们配置的用户名与密码才能访问配置文件信息。

修改 config 客户端模块

在 bootstrap.yml 文件中添加配置信息，配置 config配置中心连接的用户名与密码

重启服务，服务能正常启动；访问：http://localhost:3355/configInfo ，发现能正常读取到配置信息，则证明我们 安全认证配置成功。

Config 配置中心集群搭建

在微服务架构中，所有的服务都从配置中心获取配置，配置中心一旦宕机，会发生很严重的问题，所以配置中心需要搭建集群来避免单机故障造成整个分布式系统出现问题，下面我们搭建一个双节点的配置中心集群来演示配置中心集群的搭建。

配置中心修改

修改配置中心的配置文件名称为 ，并复制一份为 并修改端口号为 3345。

修改原来服务的启动配置，并 copy 该服务创建第二个服务节点。

启动这两个配置中心模块，登录 Eureka 注册中心，即可查看服务是否注册成功。

客户端修改

修改 bootstrap.yml 配置文件，添加从注册中心获取配置中心地址的配置。注意：service-id 即为配置中心注册到 Eureka 的服务别名。

重启 客户端模块，访问：http://localhost:3355/configInfo 可以看到能够正常获取到 github 上的配置信息。

关掉配置中心节点 3344 模拟配置中心节点突然挂掉的情况，修改 github 上的配置信息，并调用 http://localhost:3355/actuator/refresh 刷新客户端，访问：http://localhost:3355/configInfo 发现能够正常读取到修改后的配置信息，则证明我们的集群配置成功。

至此，关于 config 配置中心 的介绍完毕。