接上篇《33.编写Config Client》 Spring Cloud版本为Finchley.SR2版
目录
一、Spring Cloud Config的多种远端仓库支持
二、测试仓库配置的准备工作
三、获取不同仓库的配置信息
四、Config配置模式匹配
上两篇我们搭建了一个私有远端仓库，并编写了Spring Cloud Config的Server服务端提供配置服务端点，编写Spring Cloud Config的Client客户端，并对接Server服务端获取远端仓库的配置。本篇我们来着重讲解一下有关Spring Cloud Config的私有远端仓库（这里我们用的Git）的一些配置。
本部分官方文档：https://cloud.spring.io/spring-cloud-static/Finchley.SR4/single/spring-cloud.html#_git_backend
注：好像Finchley.SR2的文档已经挂了，最新的是Finchley.SR4的文档。
一、Spring Cloud Config的多种远端仓库支持
通过Spring Cloud的官方文档我们可以看到，Spring Cloud Config可以支持多种远端仓库的对接。例如git（git仓库，github、gitlab、gitee等）、svn、本地文件存储（File System）等方式。
由于篇幅有限，我们这里不再探讨svn和本地存储的配置方式，着重讲解git的配置，原因是git作为版本控制工具，在Spring Cloud的生态圈中有很多天然的优点，以及官方也推荐我们使用git。
使用git作为Spring Cloud Config的远程仓库，有一些好处：
（1）版本审计
譬如我们可以查看每个配置的修改轨迹、修改历史，也可以查看每个配置在某个时间是哪个用户修改的。
（2）做分布式
我们可以使用git做分布式处理，git本身也支持本地仓库和远端仓库，可以做到离线工作，在线更新。而svn本身没有本地仓库，又不好做分布式处理，使用本地文件存储又无法实现高可用（除非用类似NFS的分布式文件管理系统），所以git是最合适的。
加上官方的推荐，所以这里我们只来深入了解Git的一些配置。
想了解其它配置的小伙伴，可以查看这篇博文：https://www.cnblogs.com/zuowj/p/10432445.html#s-1.1
二、测试仓库配置的准备工作
我们需要创建几个不同的仓库环境，来测试我们的配置，具体准备如下：
我们先在gitee(码云)上新建几个项目：simple、special
然后把这两个仓库clone到D盘（安装Git工具等在上上篇有讲解）：
然后把 文件夹中的application.yml配置文件分别放入simple、special的文件夹：
里面的内容分别修改为：
type: simple
type: special
然后把变更全部提交：
至此准备工作已经做好。
三、获取不同仓库的配置信息
准备工作做好后，我们打开STS（或Eclipse），找到之前我们的microserver-config-server工程：
上面我们备份了之前的application.yml为application.yml.bak。
然后我们打开application.yml文件，修改uri，将后面原来的“Spring-Cloud-Config-Test”改为通配符{application}：
server:
port: 8090
spring:
cloud:
config:
server:
git:
uri: https://gitee.com/jackzhucoder/{application}
其实不难发现，我们之前三个仓库的地址分别为：
https://gitee.com/jackzhucoder/Spring-Cloud-Config-Test.git
https://gitee.com/jackzhucoder/simple.git
https://gitee.com/jackzhucoder/special.git
除了仓库名不同，其前缀都是相同的，那么上面带通配符{application}的意思，就是可以通过这个动态参数，来获取跨仓库的配置。
回忆一下之前的Config Server配置的映射规则：
/{application}/{profile}[/{label}]
/{application}-{profile}.yml
/{label}/{application}-{profile}.yml
/{application}-{profile}.properties
/{label}/{application}-{profile}.properties
按照这个规则，如果我们访问Config Server的http://127.0.0.1:8090/simple-default.yml，理应会显示simple仓库下的默认application.yml中的内容“type: simple”。
我们重启一下服务试验一下是不是这样：
发现没有问题。这里我们就实现了一个Git仓库对应一个微服务的概念，我们每个微服务创建属于自己的一个git仓库即可。不了解git仓库配置的，通过application名称，也可以轻松的找到该仓库。并且git仓库之间是相互隔离的，我修改A服务的配置，并不会影响到B服务。
不同版本的配置文件，我们使用application-{profile}.yml来创建配置文件，使用http://127.0.0.1:8090/simple-{profile}.yml的方式来访问即可。
当然，如果再细分的话， 我们可以一个环境创建一个git仓库，可以创建名为“simple-dev”仓库，作为托管开发环境配置文件的仓库，访问时依然可以通过http://127.0.0.1:8090/simple-{profile}.yml的方式访问。这里不再赘述试验。
四、Config配置模式匹配
1、pattern
我们在配置文件中，不仅可以配置远程仓库的uri地址，还可以根据不同的情况配置不同仓库的地址，并且可以为仓库配置pattern模式匹配，即使用类似正则表达式的方式，来设置哪些请求可以映射到该uri对应的远程仓库。下面我们来实际操作一下，让大家好理解。
我们在刚刚本地的special文件夹下创建“special-dev.yml”和“special-test.yml”文件：
其中的内容分别为：
type: special-dev
type: special-test
然后提交至远程仓库：
然后把microserver-config-server工程的application.yml配置文件，修改为：
server:
port: 8090
spring:
cloud:
config:
server:
git:
uri: https://gitee.com/jackzhucoder/Spring-Cloud-Config-Test
repos:
simple: https://gitee.com/jackzhucoder/simple
special:
pattern: special*/dev*,special*/test*
uri: https://gitee.com/jackzhucoder/special
上面的配置，我们第一个uri是我们的主仓库，所有没有命中的请求的默认配置都是在主仓库中获得，而后面的repos是从仓库，即其它应用的仓库，可以根据{application}来命中，也可以根据配置的pattern模式匹配来命中。
重启服务，我们来访问http://127.0.0.1:8090/simple-default.yml、http://127.0.0.1:8090/special-default.yml，发现指向了Spring-Cloud-Config-Test仓库的默认application.yml配置：
这是因为主动请求default类型的配置，如果子仓库没有配置，就会降级获取到主仓库中的default配置。
而当我们访问http://127.0.0.1:8090/simple-dev.yml、http://127.0.0.1:8090/simple-test.yml时，会访问到simple仓库中的默认文件application.yml中的内容：
访问http://127.0.0.1:8090/special-dev.yml、http://127.0.0.1:8090/special-test.yml、http://127.0.0.1:8090/special-dev111.yml、http://127.0.0.1:8090/special111-dev.yml、http://127.0.0.1:8090/special-test111.yml、http://127.0.0.1:8090/special111-test.yml可以看到以下效果：
这说明我们的default的模式匹配很成功(匹配到的就匹配上了，没有匹配的显示默认)。
如果我们尝试访问模式匹配外的请求，如http://127.0.0.1:8090/1111special-dev.yml，则会访问不到special的dev，直接降级匹配到主仓库的dev配置：
测试完毕。
2、searchPaths
关于模式匹配，还有一个searchPaths参数，配置如：
spring:
cloud:
config:
server:
git:
uri: https://gitee.com/jackzhucoder/Spring-Cloud-Config-Test
searchPaths: foo,bar*
这是什么意思呢，这里就是搜索路径的意思，默认Config仓库只会检索根目录的文件，不会检索子目录的文件，加上searchPaths后，我们就可以指定去检索哪些子目录了，即我们可以在我们的仓库中可以创建新的目录，把不同的内容放置在不同的目录中，并暴露检索位置。
如我们在本地Spring-Cloud-Config-Test下创建一个foo和bar的文件夹，里面放上foo-dev.yml和bar-dev.yml文件，内容为type: foo-dev.yml和type: bar-dev.yml：
然后提交至远程仓库：
然后修改配置为上面带searchPaths的配置（把之前的配置备份为bak）：
server:
port: 8090
spring:
cloud:
config:
server:
git:
uri: https://gitee.com/jackzhucoder/Spring-Cloud-Config-Test
searchPaths: foo,bar*
重启服务，然后分别访问http://127.0.0.1:8090/foo-dev.yml和http://127.0.0.1:8090/bar-dev.yml，可以看到能检索到文件夹目录下的文件：
这样的好处是以文件夹分类的方式管理我们的远程配置文件。
最后，searchPaths中也可以使用通配符，如searchPaths: '{application}'。
3、其它参数
（1）cloneOnStart：
默认情况下，服务器在首次请求配置时克隆远程存储库。可以将服务器配置为在启动时克隆存储库，需要将 clone-on-start设置为true。
server:
port: 8090
spring:
cloud:
config:
server:
git:
uri: https://gitee.com/jackzhucoder/Spring-Cloud-Config-Test
repos:
simple: https://gitee.com/jackzhucoder/simple
special:
pattern: special*/dev*,special*/test*
uri: https://gitee.com/jackzhucoder/special
clone-on-start：true
在上面的配置中，服务器在启动时克隆jackzhucoder的special仓库。其他存储库将不被克隆，直到请求该存储库配置。
（2）username和password
目前我们的git仓库是公开的，如果我们是私有仓库，需要配置相应私库的账号密码，格式如下：
spring:
cloud:
config:
server:
git:
uri: https://gitee.com/jackzhucoder/Spring-Cloud-Config-Test
username：xxxx
password: xxxx
参考：《51CTO学院Spring Cloud高级视频》
https://blog.csdn.net/u010811939/article/details/100171060
转载请注明出处：https://blog.csdn.net/acmman/article/details/105011416