• 对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配置文件如下:

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

  • 相关阅读:
    第二阶段冲刺进程2
    第二阶段冲刺进程1
    Alpha版使用说明
    回复每组的意见的评价
    每个组针对本组提出的意见的整理
    软件项目第一次Sprint总结
    站立会议7
    站立会议6
    团队博客11
    团队博客10
  • 原文地址:https://www.cnblogs.com/songxh-scse/p/7406641.html
Copyright © 2020-2023  润新知