以下部分纯属个人理解,但是结果都是经过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配置文件如下:
spring.application.name = test 1 spring.cloud.config.lable = master 2 spring.cloud.config.profile = dev 3 spring.cloud.config.uri = http://localhost:8881/ 4
解释:1和3组成了访问的配置文件名,如test-dev.properties
2决定了git的分支,此处为master分支
4表示config-server的地址
请求的URI就是由这个配置决定的,网上关于这点的说明很多,此处不再赘述
2、server配置文件如下:
spring.cloud.config.server.git.uri = https://github.com/lucknot/songxh_scse/ 1 spring.cloud.config.server.git.searchPaths = test 2
解释:1表示git仓库的地址,这里是我的github仓库地址(并没有干货)
2表示配置搜索的文件夹,在client请求配置时,只会在这个文件夹下进行搜索
事实上将1和2拼接在一起就组成了搜索配置属性的URL地址。
针对配置文件需要说明以下,label表示的分支只与client的配置相关:client中配置的是哪个分支就取哪个分支的配置
ps:在写这篇博客的时候突然想到一个问题,client在像server请求时是否只是请求需要的属性的值,还是请求对应的属性文件。个人感觉是取对应文件名的配置文件,在client拿到配置文件后再将读取对应的属性,与spring boot中从配置文件中读取属性类似(事实上就是两个上下文,spring cloud的上下文有高优先级)。