SpringCloud（六）——config统一配置中心

SpringCloud（六）——config统一配置中心

前言

config统一配置中心的功能是将系统的核心配置文件（即系统中的统一配置）放在远端存放，一般会选择使用git作为远程存放配置文件的存放点。

该组件诞生的原因是系统中的一些相关配置可能不是一成不变的，比如一些网购平台会在特定的日子做一些活动，这些活动开始的时候会在系统中添加一些功能，并且可能会改变页面的布局等，这需要前后端一些修改，这些修改一般存在是将活动的相关的页面和功能做一些新的服务来实现，所以一般会在网关组件中设置一些定时生效的配置（这些配置是属于断言中的一些配置，大家可以自行查看，比较简单）。这些配置原则上就是修改了配置文件，如果一些服务拥有上百个节点，那么在修改配置重启的时候就需要修改上百个配置文件，且需要重启上百个服务。

config统一配置中心诞生的意义就是解决这一类问题。

config统一配置中心基础配置

该组件需要一个从远端配置文件存放点获取配置文件的服务，该服务具备的功能如下：

• 首先可以从远端配置中心获取配置文件（本人使用git）；
• 获取配置文件后，其他服务可以通过consul注册中心获取到该服务缓存在本地的配置文件。

其他服务具备的功能：

• 首先可以从统一配置中心获取到对应的配置文件（配置中心存放很多配置文件，各个服务只从中抽取自己需要的）；
• 由于配置文件在远端存放，本地的服务在启动过程中会因为配置缺失而报错（默认情况下，配置文件的获取是在项目启动完成后获取），所以必须让服务在启动的时候根据本地配置去获取远端配置文件。

配置步骤

configserver

首先需要创建一个confgserver服务，用于从git中获取配置文件缓存到本地：

• 引入依赖：

<!--config server -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
</dependency>

• 入口类加入注解：

@SpringBootApplication
@EnableDiscoveryClient
//  开启统一配置中心注解，该注解表示服务启动后便会根据当前配置文件中的相关配置去指定地址获取对应的配置文件
@EnableConfigServer   
public class ConfigServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConfigServerApplication.class,args);
    }
}

• 书写配置文件：

# 基础配置
server.port=8091
spring.application.name=CONFIGSERVER
# consul
spring.cloud.consul.port=8500
spring.cloud.consul.host=localhost

# 配置远程仓库地址       git如何注册申请自己找视频，git如何使用可以找视频或者看博客中  《工具使用》专栏中的笔记
spring.cloud.config.server.git.uri=https://gitee.com/XXX/testconfig.git
spring.cloud.config.server.git.default-label=master
# 私有仓库必须配合仓库的用户名和密码
spring.cloud.config.server.git.username=用户名（一般使用的是登录的邮箱）
spring.cloud.config.server.git.password=自己的密码

上面的配置中，标识这该服务可以通过对应的git仓库地址中的master分支获取配置文件（这个时候是将所有的配置文件拉取到本地）。

【注】：如果创建对应的git仓库是私有仓库，则在陪孩子文件中必须书写仓库的用户名和密码；如果定义的是公有仓库，则不需要配置用户名和密码。

configclient

【注】：configclient这个服务仅仅是作为在微服务系统中的各个服务的一个模板，即真正的微服务中没有configclient服务，因为每个需要获取配置文件的单个服务都是configclient。

• 引入依赖：

<!--configclient-->
<!--注意，客户端的依赖于统一配置中心的依赖有区别-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-config</artifactId>
</dependency>

• 书写配置文件：

# 如果该服务使用的是远端配置文件，则配置文件名必须为 bootsrap
# 且 从SpringCloud2020开始，内部bootstrap依赖被移除，所以需要手动引入bootstrap

# 开启允许根据服务ID获取配置
spring.cloud.config.discovery.enabled=true

# 根据服务ID来获取
spring.cloud.config.discovery.service-id=CONFIGSERVER

# consul
spring.cloud.consul.host=localhost
spring.cloud.consul.port=8500

# 确定需要获取的配置文件步骤
# 确定分支
spring.cloud.config.label=master
# 确定文件名
spring.cloud.config.name=configclient
# 确定配置文件的环境类型
spring.cloud.config.profile=prod

**【注】：**注意配置文件中前两行注释，在此做一下解释：传统的application.yml/properties配置文件表示使用已经配置好的配置来启动。因为配置文件中有很多配置都有默认值，这个时候，项目启动的时候会直接按照当前配置文件来启动。这时候，从远端配置中心获取配置的工作会在项目启动完成后开始。

而在这个时候，系统会发现项目配置文件缺失，所以会启动报错，结果就是拿不到对应的远端配置文件。

所以，想要在项目启动前就从统一配置中心中获取对应的配置来使用，就需要将配置文件的名字改为bootstrap.yml/properties，这是一个命名规范，不要探究它和前端框架的关系。bootstrap这个单词的含义是表示引导，即按照当前配置文件的引导来完成启动过程中的后续工作。

远端配置文件书写

# configclient文件
server.port=8090
spring.application.name=CONFIGCLIENT

# configclient-dev.properties 文件
demo.name=Lucy

# configclient-prod.properties 文件
demo.name=Bob

配置步骤小结

由于本人使用的SpringCloud版本是2020以后的版本，在使用的时候报了错，查看源码得知在这个版本开始将bootstrap依赖移除了，所以在使用过程中会出现了无法识别bootstrap的错误，这是时候只要手动将该依赖引入即可：

<!--bootstrap-->
<!--SpringCloud从2020版本开始移除了 bootstrap，导致无法识别该配置文件，所以手动引入即可-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>

配置生效

当上述项目测试成功后，我们发现，如果修改了远端的配置，就可以修改所有使用该配置的微服务。但是想要修改的配置生效，首先需要重启统一配置中心，然后再重启其他的微服务，在修改方面不但没有便捷，反而更加繁琐了。

其实，只需要将一个注解就可以解决这个问题。

首先，各个微服务使用的配置文件是统一配置中心从远端拉取到本地（即缓存在本地的配置文件），所以这个时候远端配置修改不会将本地的配置文件对应更新。

这个时候我们将各个微服务的控制器中加入一个注解@RefreshScope这样就可以单单重启统一配置中心，而不需要重启所有服务。该注解的功能为，在下一次访问到对应的控制器的时候刷新从本地引用的配置文件缓存。

但是这样就需要在所有的服务中的控制器中加入注解，感觉更麻烦了，很明显这是一个馊主意，所以针对这一情况还有另一个组件来配合解决该问题。

统一配置刷新组件

统一配置刷新的概念是为了解决远端仓库配置文件修改以后，统一配置中心无法自动刷新，且其他服务无法自动获取新配置文件的问题，解决该问题一般使用的是一种设计模式——发布者-订阅者模式，在这种模式中需要拥有消息（服务）的生产者（发布者）以及消息（服务）的调用者（订阅者）。

根据我们需要解决的核心问题：配置文件更新。可以得出的结论是：统一配置中心需要作为消息（服务）的生产者（订阅者），其他服务作为调用者（订阅者）。

现在角色已经区分完成，接下来需要解决的问题就是如何实现该设计模式——即，如何将统一配置中心和其他服务串联起来，目前我们发现，单单依靠现在的SpringCloud以及注册中心无法完成该实现，所以需要引入以下两个组件：

• SpringCloud Bus：Bus 中文翻译是消息总线，SpringCloud消息总线在分布式系统中使用一个轻量级的消息中间件来连接所有服务节点。
• RibbitMQ：为一款轻量级消息中间件，底层实现为队列，可以保证消息传递顺序。与SpringCloud Bus配合解决配置刷新的时候承担了消息注册中心的作用。（主要实现功能为异步处理）。

后续说明

由于该部分涉及知识点、技术过多，一篇笔记全部记录可能会导致读者思路混乱，所以下面放上链接，大家按照链接顺序查看。

RibbitMQ安装

SpringCloudBus使用

总结

本篇笔记没什么好总结的，就是一些简单的配置。但是一定要按照顺序来阅读