对spring cloud config的一点理解

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

以下部分纯属个人理解，但是结果都是经过demo验证。

一、spring cloud config介绍

spring cloud是spring家族中的一个微服务工具包，其中包含了很多微服务的工具。偏向于与spring boot类似的配置方式，有许多许多默认配置。spring cloud config是其中的一个工具包，用于配置的拉取更新。

举一个小小的例子，当我们程序中有一个配置文件需要修改，但是服务已经启动，配置文件中的配置已经读取到内存中，为了修改配置，我们需要重启服务；如果是一台或者几台机器重启，还算容易，但是如果是一个集群，重启就变成一个非常耗时的工作；如果我们使用spring cloud config，就可以在服务运行时，拉取git（svn等，下面以git为例）的配置，修改内存中的配置。

二、spring cloud config逻辑介绍

config-server：提供对git的连接，配置拉取，这里的拉取是被动拉取。

config-client：连接config-server，通过URI请求对应的配置文件，获取配置属性

如图表示client从server拉取配置的过程：

1、client根据配置向server发送配置请求

2、server根据配置从git拉取所有文件（git clone的过程）

3、git将整个仓库下发

4、server解析client的URI请求，返回相应的配置属性或者错误信息（不存在相应的配置属性）

如图表示client发送刷新配置请求的过程：

1、client向server发送refresh请求

2、server向从git更新本地配置（git pull）

3、git下发更新

4、server对比更新，发现client需要的配置有更新时，会将更新信息发给client

理解：1、在client第一次向server发送URI请求时，server会根据配置的git地址，拉取对应仓库的所有文件（与git clone@{git adress}）（在config-server本地/tmp目录下可以找到git本地仓库）；

2、值得注意的是，在client发送刷新配置请求（refresh）时，server会根据本地仓库的情况处理：

（1）如果server本地仓库有未提交的commit和未commit的修改时，server就不会从git上拉取更新（不会git pull），只会将本地仓库中对应的配置属性传给client；

（2）如果server本地仓库没有任何修改和commit，server会从git上拉取更新（git pull），然后将本地仓库对应的配置属性传给client。

3、还有一个坑点，我在demo测试过程中发现，如果git仓库过大，拉取过程很长，在server拉取的时候会出错（有一个最大等待时长，超过会出现超时错误）。为了实现大的二进制文件的正常拉取，可以切到本地仓库地址，手动拉取一次更新。

（1）在创建本地仓库时就采用手动拉取的方式：在配置文件application.properties中，设置git的url地址为本地文件地址，初始化时，手动git clone远程仓库地址到设置的本地文件地址。在更新配置的时候，config-server也会自动从远程拉取更新。

（2）如果是更新的时候有大文件的修改导致不能拉取更新：application.properties配置文件中git的url为远程仓库地址，初始化时能够自动拉取，如果有大文件更新，利用git工具，手动切到本地/tmp目录下，利用git命令手动拉取更新就可以拉取大文件的更新，在之后的小文件更新中，config-server就能够正常自动更新。

总之就是，client向server发送一个URI请求：“我要**属性，你那里有吗？”，然后server根据自身的配置，拉取git仓库，然后去找client需要的那个属性，然后告诉client：“我这里有（没有）这个属性，（有就给client）”；刷新过程就是，client向server发送一个URI请求：“我请求的属性值变了吗？”，然后server处理之后，回复client：“变了，这是新的值。（没变）”。

三、配置文件介绍

1、client配置文件如下：

解释：1和3组成了访问的配置文件名，如test-dev.properties

2决定了git的分支，此处为master分支

4表示config-server的地址

请求的URI就是由这个配置决定的，网上关于这点的说明很多，此处不再赘述

2、server配置文件如下：

解释：1表示git仓库的地址，这里是我的github仓库地址（并没有干货）

2表示配置搜索的文件夹，在client请求配置时，只会在这个文件夹下进行搜索

事实上将1和2拼接在一起就组成了搜索配置属性的URL地址。

针对配置文件需要说明以下，label表示的分支只与client的配置相关：client中配置的是哪个分支就取哪个分支的配置

ps：在写这篇博客的时候突然想到一个问题，client在像server请求时是否只是请求需要的属性的值，还是请求对应的属性文件。个人感觉是取对应文件名的配置文件，在client拿到配置文件后再将读取对应的属性，与spring boot中从配置文件中读取属性类似（事实上就是两个上下文，spring cloud的上下文有高优先级）。