对spring cloud config的一点理解

　　如下部分纯属我的理解，可是结果都是通过demo验证。

1、spring cloud config介绍

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

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

2、spring cloud config逻辑介绍

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

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

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

　　

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

　　二、server根据配置从git拉取全部文件（git clone的过程）

　　三、git将整个仓库下发

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

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

　　一、client向server发送refresh请求

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

　　三、git下发更新

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

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

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

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

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

　　　三、还有一个坑点，我在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：“变了，这是新的值。（没变）”。

3、配置文件介绍

一、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就是由这个配置决定的，网上关于这点的说明不少，此处再也不赘述

二、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的上下文有高优先级）。