一文吃透微服务配置中心：SpringCloudConfig

配置中心:Spring Cloud Config

我们知道，一个微服务系统可能由成千上万的服务组成，每个服务都会有自己的配置，不同服务之间的有些配置是相同的，比如数据库。如果对于每个服务，我们都复制相同的配置，一旦该配置发生了变化,那么每个服务都需要修改，代价可想而知。

Spring Cloud已经考虑到了这一点，它为我们提供了一整套解决方案，那就是强大的Spring CloudConfig。

Spring Cloud Config简介

Spring Cloud Config是一个高可用的分布式配置中心，它支持将配置存放到内存(本地)，也支持将其放到SVN、Git等版本管理工具进行统一管理。对于Spring Cloud Config，其官方网站是这样介绍的:

Centralized external configuration management backed by a git repository. The configuration resourcesmap directly to Spring Environment but could be used by non-Spring applications if desired.

大致含义是:通过Git仓库以支持集中式外部配置管理器，配置资源直接映射到Spring环境，但如果有必要，可以由非 Spring应用程序使用。

那么，本篇将引入 Spring Cloud Config组件，带领读者领略它的风采!

创建配置中心

创建配置中心一般分为以下几个步骤。

(1)创建Git仓库。为了方便测试,笔者已事先创建好Git仓库,地址为
https:/github.com/lynnlovemin/SpringCloudActivity.git。

(2)创建配置中心服务端。

在原有工程中创建一个moudle，命名为config，在pom.xml加入配置中心的依赖:

org.springframework.cloud
spring-cloud-config-server

commoncom. lynn.blog
1.8-SNAPSHOT

在上述依赖中，我们加入了
spring-cloud-config-server依赖，该依赖为配置中心的服务端依赖，有了它我们就可以将当前工程作为配置中心的服务端工程。

(3)创建启动类ConfigApplication:

@EnableConfigServer
public class ConfigApplication extends Application{
public static void main(String[] args){
Application.startup(ConfigApplication.class,args);
}
}

可以看到，我们添加了@EnableConfigServer注解，用来启用配置中心服务端。启动类ConfigApplication继承了Application类。

其实，Application类是一个公共的启动父类，所有工程的启动入口都继承了该类并提供了一个静态方法以调用SpringApplication。我们提供这样一个类主要是因为每个SpringCloud子工程的启动类都需要加入了@SpringCloudApplication注解，于是每个子工程的启动类只要继承了Application类，就无须再添加@SpringCloudApplication注解，Application类的代码如下:

@SpringCloudApplication
@Componentscan(basePackages = "com.lynn.blog")public abstract class Application {
public static void startup(class cls,string[] args){
SpringApplication.run(cls,args);
}
}

我们将Application 设置为抽象类，因为它无须实例化并且提供了静态方法 startup，该方法调用了SpringApplication.run方法，因此在ConfigApplication中直接调用startup方法就可以启动该应用。

读者应该也会注意到，Application类除了添加了@SpringCloudApplication 注解外，还添加了@ComponentScan注解，该注解可以在应用启动后，指定扫描的根包名。由于每个工程的根包名都不一样，比如 register工程为 com.lynn.blog.register，config 工程为 com.lynn.blog.config，而Application类是放到common工程中的，其根包名为com.lynn.blog.common，所以如果不指定扫描的包名，Spring容器会默认扫描com.lynn.blog.common包，导致每个子工程的服务和控制器都无法被扫描到，从而无法注人。虽然根包名都不一样，但是它们都处于com.lynn.blog包下，因此我们可以指定根包名为com.lynn.blog，这样Spring就可以扫描到整个项目。

(4)创建application.yml并增加如下内容:

server:
port: 8102spring:
application:
name: configcloud:
client:
ip-address:127.e.e.1config:
server:
git:
uri: https://github.com/lynnlovemin/SpringCloudActivity.git#配置存放到这个目录下
searchPaths: configusername:***牢**password:**零宗**
#使用master分支的配置label: master
eureka:
instance:
prefer-ip-address: trueclient:
register-with-eureka: truefetch-registry : true
service-url:
defaultZone: http://admin: admin123@localhost:8101/eureka/

Spring Cloud Config默认的配置仓库为Git，因此无须在配置中告诉Spring Cloud Config，直接设置Git仓库的地址、用户名和密码即可。

在上述配置中，
spring.config.server.git.uri为Git仓库所在的 HTTP地址，searchPaths为该仓库的根目录，username为Git仓库用户名，password为Git仓库密码，spring.config.label为分支名，本示例设置为master（主干)分支。图8-1展示了Git仓库的截图。

可以看到，具体的配置文件其实是放到仓库的config目录下的，因此上述配置的searchPaths需要指定为config。

现在分别启动register和l config，并访问localhost:8101，就可以看到如图8-2所示的界面。

至此，配置中心服务端搭建完成。

接下来，我们改造test工程。将工程的配置放到Git仓库中并验证程序是否能够通过配置中心将配置拉取下来。

(1)在我们的Git仓库下创建一个文件，命名为test.yml，将本地配置文件内容复制到test.yml 中并删除test工程的application.yml，如图8-3所示。

(2)在resources下创建 bootstrap.yml 文件，内容如下（注意，这里必须命名为bootstrap.yml，而不是 application.yml ):

spring:
cloud :
config:
#要拉取的配置文件名,多个配置文件以逗号隔开name : test
label : masterdiscovery :
enabled: true
#配置中心spring.application.name指定的名字serviceId: config
eureka:
client:
service-url:
defaultzone: http: / / admin : admin123@localhost:8101/eureka/

其中，sping.cloud.config.name表示要拉取的配置文件名。前面我们已经创建了test.yml，因此这里指定了文件名为test，我们也可以指定多个配置文件，中间以逗号隔开。由于不同的工程可能有相同的配置信息，所以可以考虑增加一个数据库的配置文件，在有数据库连接需求的工程上增加该配置文件。这样的话，如果数据库信息发生改变，只需要改变数据库的配置文件即可，大大提升了应用的可扩展性。

Spring.cloud.config.label指定了要拉取的分支，本示例指定为主干分支，discovery.enabled指定是否拉取配置，serviceId指定了配置中心的名字，该名字为config工程spring. application.name指定的名字。

配置中心同样支持多环境配置，增加test-dev.yml配置文件，在 bootstrap.yml中添加代码
spring.cloud.config.profile=devR就会拉取test-dev.yml 的信息。

(3)启动test，可以看到控制台打印出了启动端口9999:

Tomcat initialized with port(s):9999(http)

这时如果将test.yml文件中的端口号改为9998，重启test后可以看到其启动端口已设置为9998,那么说明test已成功从Git仓库拉取了对应的配置。

对配置内容进行加密

Spring Cloud Config在Git仓库下默认是以明文存在的。在某些场景下，我们需要对一些敏感数据(如数据库账号、密码等）进行加密存储。

Spring Cloud Config支持对配置内容进行加密存储，下面我们就来看一下如何使用加密功能。8.3.1安装JCE

由于Config Server依赖Java Cryptography Extension(简称JCE )，所以在使用加密功能前我们应先安装JCE。JCE的安装非常简单，只需要下载JCE包(详见
http://www.oracle.com/technetwork/javaljavase/downloads/jce8-download-2133166.html )，如图8-4所示。

然后解压并替换JDK安装目录下jre/lib/security的两个jar包，如图8-5所示。

如果没有security目录，则手动创建该目录。

最后需要重启IDEA，否则可能会报错:

{
"description" :“No key was installed for encryption service","status":"NO_KEY"
}

至此，JCE就安装完成了。Config Server同时支持对称加密和非对称加密，第4章已经介绍过两者的区别。

对称加密

Config Server默认的加密算法为对称加密算法。首先，在config 工程下新增bootstrap.yml，并设置对称加密的密钥:

encrypt:
key : springcloud

启动config，Config Server会开启encrypt和 decrypt两个端点，通过postman°可以测试其加密和l解密效果，如图8-6和图8-7所示。

对配置内容加密

我们可以使用{cipher}标识对配置内容进行加密，修改Git仓库的test.yml文件,增加内容如下:

data:
message: '{cipher} b47b603d1c5551773a2385c6dafebcebf1b5a980ed08171c47ceeb226dd9f7ed'

其中，
b47b603d1c5551773a2385c6dafebcebf1b5a9800de8171c47c0eb226dd9f7ed 为前面通过postman加密后的字符串。

重启config工程,在浏览器中访问
localhost:8102/test-default.yml,可以看到如图8-8所示的内容。

通过图8-8可以看到，Config Server已经将我们加密的内容解密为明文了。

非对称加密

Config Server同样支持非对称加密。与对称加密方法不同，非对称加密的思想是生成两个key :公钥和私钥。公钥用于加密，私钥用于解密。因此，非对称加密安全性更高，同时效率也相对较差。

(1)进入Java安装目录通过keytool生成keystore:

keytool -genkeypair -alias serverkey -keyalg RSA -keystore D:/server.jks

根据提示输入相应内容，如图8-9所示。其中，-keystore后面紧跟密钥文件的路径。如果生成失败,请尝试用管理员权限启动cmd命令行。

(2)将server.jks复制到config工程的resources目录下，如图8-10所示。

(3)修改bootstrap.yml，增加以下内容:

encrypt:

keyStore:

location: classpath : server.jks

password: 111111alias: serverkeysecret: 111111

其中，password 为上面设置的密钥库口令，而secret为上面设置的密钥口令，读者一定要区分密钥库口令和密钥口令，两个口令可以相同也可以不同; location为密钥文件路径，由于Maven编译后，会将resources 的所有文件复制到classes目录下，因此这里指定classpath即可; alias为上面命令中-alias后面设置的字符串。

(4)修改pom.xml文件:

src/main/resourcestrue

**/*.jks



src/main/resourcesfalse

**/*.jks

由于第一个配置中设置了为true，Maven在编译时不会原样复制，而会做一定的处理再复制到classes下,所以为了保证密钥文件不被破坏,需要利用排除.jks结尾的文件。设置filtering为true时，Maven 会替换placeholder占位符，再复制,在第一个配置中排除了.jks文件，Maven不会复制.jks文件，因此还需要将filtering 设置为false，并通过

(5)启动config 工程，分别访问地址localhost:8102/encrypt 和 localhost:8102/decrypt，能够得到加密和解密后的结果，如图8-11和图8-12所示。

如果报以下错误，请读者用mvn clean package命令重新编译打包工程:

配置自动刷新

有些时候，我们可能会通过修改一些配置来达到我们的期望，如数据库地址发生变化时需要修改配置。如果不进行任何处理，那么每次修改配置都需要重启服务，而一个大型系统可能有成千上万个服务，每个服务都需要重启的话，代价无疑是很巨大的。

Spring Cloud Config 为我们提供了配置的刷新机制，不用重启服务就可以在线修改配置文件。

使用refresh端点刷新配置

我们首先研究手动刷新配置，其方法非常简单。

(1)添加Actuator依赖(Actuator自带refresh端点):

org.springframework.boot
spring-boot-starter-actuator

该依赖已在common 工程中添加，这里单独说明是为了告诉读者refresh端点依赖哪个包。(2)在test工程下创建一个控制器，便于我们测试:

@RestController
@RefreshScope
public class Testcontroller {
@Value("$idata.message}")private String port;
@RequestMapping("test")public String test(){
return port;
}
}

可以发现，在TestController中新加入了@RefreshScope注解，作用是告诉refresh端点刷新该类所引用的配置。

(3)在Git仓库的test.yml中开启refresh端点，并将data.message 的值修改为test1:

management:
endpoints :
web:
exposure:
include: refresh,health,info

在Spring Boot 2.0以后，Actuator默认只启动health和info两个端点，无法自动开启refresh端点,需要额外增加配置。

(4)测试。

①分别启动register、config和 test三个工程。②访问localhost:9999/test，返回数据testl。

③修改test.yml，将data.message的值改为test2，并重新执行步骤②，发现返回数据并未发生改变。

④用postman请求refresh端点，如图8-13所示。

⑤再次执行步骤②，发现返回了数据test2，说明配置已经生效。

Spring Cloud Bus自动刷新配置

通过上一节，我们已经实现了配置的刷新。虽然修改配置后无须重启服务，但也需人工干预，手动刷新配置，而且所有节点都必须配置refresh端点，这并不是我们想要的结果。本节，我将通过SpringCloud Bus和 Git仓库的Webhooks，实现配置的自动刷新,即修改配置后无须任何操作即可使配置生效。

Spring Cloud Bus使用轻量级的消息代理(如RabbitMQ、Kafka等）连接分布式系统的节点。通过Spring Cloud Bus可以向每个服务广播消息，如状态的变更。

本文使用RabbitMQ进行消息的分发，读者在集成Spring Cloud Bus之前需优先安装RabbitMQ,安装教程请参照本文第10章。

接下来我们集成Spring Cloud Bus。

(1)在 common工程中添加依赖:

org.springframework.cloud
spring-cloud-starter-bus-amqp

前面已经提过，Spring Cloud Bus集成了消息队列，而 amqp正是RabbitMQ的Spring Cloud依赖。

(2)在config工程的 application.yml中增加如下配置:

management:
endpoints:
web:
exposure:
include: refresh, health,info, bus-refresh
spring:
rabbitmq:
host: 127.e.8.1port: 5672
username: guestpassword: guestvirtualHost:/
publisherConfirms: true

读者应该已经发现，在上述配置中，include后面多配置了一个端点bus-refresh，Spring CloudConfig是通过bus-refresh端点和 RabbitMQ进行通信的。

spring.rabbitmq为RabbitMQ的基本配置,其中 host为RabbitMQ服务地址,如果安装到本地，则为127.0.0.1或localhost; port为RabbitMQ的端口，默认端口为5672，username为RabbitMQ访问用户名;password为密码; virtualHost为虚拟主机，读者可以理解为每个virtualHost都是一个独立的RabbitMQ服务器，默认为“/”; publisherConfirms 设置为true，表示需要确认消息,也就是说消费者认了该消息，RabbitMQ才会认为该消息已经被接受，否则将会在RabbitMQ服务器中挂起。

(3)测试。

按照7.4.1节的测试方法进行测试，只是需要将refresh端点改成bus-refresh，如图8-14所示。

可以发现，配置也发生了变化，我们只需要调用Config Server的 bus-refresh端点即可完成整个系统的配置刷新。

结合Git仓库的 Webhooks，就可以实现配置的自动刷新，如图8-15所示。

Payload URL设置为远程HTTP bus-refresh端点，当有新配置被提交时，Webhooks会自动请求bus-refresh端点，从而实现配置的自动刷新。

添加用户认证

在前面的配置中，我们的配置中心是可以任意访问的，虽然可以对内容进行加密设置，但为了进一步保护我们的数据，可以对配置中心设置安全认证，即输人用户名和密码才能进行访问。

(1)在config工程中添加依赖:

org.springframework. boot
spring-boot-starter-security< /dependency>

前面已经提到该依赖是权限验证依赖，此处不再解释。

(2)为application.yml增加以下内容:

spring:
security:
user:
name: admin#安全认证用户名
password: admin #安全认证密码

上述配置我们通过name 和 password 分别设置好用户名和密码。这样当我们启动config 并访问localhost:8102/时，将会和注册中心一样出现登录框。我们的服务若要访问配置中心，则需要配置用户名和密码，下面以 test工程为例讲解如何配置，方法很简单,只需要在bootstrap.yml添加以下内容即可:

spring:
cloud:
config:
#配置中心用户名
username: admin
#配置中心密码
password: admin

我们分别在username 和 password配置项中设置Config Server的用户名和密码。

这时启动test工程，可以看到test工程已成功拉取配置文件。

小结

本章主要介绍了Spring Cloud Config的基本用法，涵盖了Config的方方面面，从配置的拉取、内容的加密到安全认证，读者可以根据自身项目的实际要求来选择是否加密，是否进行安全认证。

本文给大家讲解的内容是springcloud实战：配置中心：SpringCloudConfig

1. 下篇文章给大家讲解的是springcloud实战：服务网关：SpringCloudGateway；
2. 觉得文章不错的朋友可以转发此文关注小编；
3. 感谢大家的支持！