传统的是本程序加载配置文件到内存，采用配置中心之后，业务端为客户端，配置服务中心根据客户端的配置参数，帮客户端从git获取对应配置文件内容，返回，然后客户端将获取的配置内容放在本程序内存中，之后的用法和传统用法就一样了
客户端请求连上服务端发出{application}/{profile}[/{label}]参数：---》服务端匹配出地址（简单的application匹配不需要pattern，需要区分环境，版本采用pattern：这个表达式和配置服务器/{application}/{profile}[/{label}]这种匹配，一个匹配一个git库地址）--》到了git库之后有根据{application}/{profile}[/{label}]找对应名称的文件
注意：一般git修改之后客户端时拿不到最新修改的（除非重启），此时可以用命令：配置服务器:端口/refresh刷新----用此可以实现nacos的实时更新配置功能，从而config也可实现灰度发布（类似
nacos一样，直接修改zuul配置）
灰度发布的落脚点在于通过控制代理实现前端和后端服务的切换---nginx,zuul（修改的方式有abtestgateway--修改nginx配置,nacos，springcloudconfig--修改zuul配置）
1，启动好服务端
服务端注解
@EnableConfigServer
服务端配置（大致）
application.properties
server.port: 8888
spring.cloud.config.server.git.uri: file://${user.home}/config-repo
其中${user.home}/config-repo是包含YAML和属性文件的git仓库。
获取配置文件的表达方式：
curl localhost:8888/foo/development----这个请求就相当于配置文件中配好的参数或启动命令行的环境参数（程序中就不在有具体的配置文件，都存在git中，
在启动请求git的时候就加载到程序缓存中---中途git修改后不启动不会同步）
一般是应用名，环境名，分支名 ---在连接对应的git（）后找这个git下应用名，环境名一直的文件（前面的服务是配置服务器）
配置服务器中配置有git服务地址，客户端或直接浏览器访问配置服务器+/{application}/{profile}自动可以获取配置服务器中git对应的配置文件（对应的文件为application-profile.properties）
git中的文件名也需要是applicationName等命名
1，没有后缀名用/---应用名/环境名/分支名 最后组成从git中需要获取的文件名称
/{application}/{profile}[/{label}]
2，有后缀名用-- 分支名在最前面（有的话）
/{application}-{profile}.yml
/{label}/{application}-{profile}.yml
/{application}-{profile}.properties
/{label}/{application}-{profile}.properties
{application}映射到客户端的“spring.application.name”;
{profile}映射到客户端上的“spring.profiles.active”（逗号分隔列表）;
{label}这是一个服务器端功能，标记“版本”的一组配置文件。
file:
yaml配置中有些级别的关键字是固定的，有些是可以随意写的，固定的是框架中需要对应的，随意写的是作为我们输入的变量传入框架的，
一般会是map或list方式传入
spring:
cloud:
config:
server:
git:
uri: https://git/common/config-repo.git ---默认地址 https://git/application/prifilel/label/config-repo.git
repos:
team-a: ---传入的临时变量部分（无意义，框架用其分类而已）
pattern: team-a-* ---专门匹配：配置服务器/{application}/{profile}[/{label}]
cloneOnStart: true
uri: http://git/team-a/config-repo.git
force-pull: true ---可以在本地文件被改变时拉取 可以用file：///直接用服务端的本地文件不用git
searchPaths: foo,bar* ---搜索文件的目录
team-b:
pattern: team-b-*
cloneOnStart: false
uri: http://git/team-b/config-repo.git
team-c:
pattern: team-c-*
uri: http://git/team-a/config-repo.git
示例二：
客户端传入的/{application}/{profile}[/{label}]和git的匹配规则
uri中label或者profile有/的用(_)；https://git/application/prifilel/for(_)bar/config-repo.git
下面的例子只有application
spring:
cloud:
config:
server:
git:
uri: https://github.com/spring-cloud-samples/config-repo
repos:
simple: https://github.com/simple/config-repo
special:
pattern: special*/dev*,*special*/dev*
uri: https://github.com/special/config-repo
local:
pattern: local*
uri: file:/home/configsvc/config-repo
spring profiles进行不同环境版本配置分离、切换,通过spring.profiles.active=dev,mysql,如果配置文件基于文件的,服务器将优先根据{applicationName}.yml,
在根据application.yml创建一个Environment对象,如果这些yml文件中有了指定的spring profiles,那么这些profiles将有较高优先级（都会加载有profile可以覆盖纯applicationname.xml）
spring.profile.avtive是指定spring boot运行的环境,而spring.cloud.config.profile是客户端指定拉取资源库的profile配置,如果有多个profiles,最后一个起作用
注意：
使用基于VCS的后端（git，svn）文件被检出或克隆到本地文件系统。默认情况下，它们放在系统临时目录中，前缀为config-repo-。
在linux上，例如可以是/tmp/config-repo-
为避免此问题，请通过将spring.cloud.config.server.git.basedir或spring.cloud.config.server.svn.basedir设置为不在系统临时结构中的目录来更改Config Server所使用的目录。
配置中心的客户端，服务端都会配置application，profile，lable服务端是默认的，客户端不传的时候用服务端的配置
2，客户端使用
客户端加载后属性在容器中，可以直接用@value或者占位符获取
1，添加依赖
2，开启注解
3，客户端配置（大致）
远程加载的配置文件优先于本地的配置文件--活动配置文件优先于默认配置，如果存在多个配置文件，则最后一个配置文件
spring:
application:
name: foo
profiles:
active: dev,mysql
参考：
https://www.cnblogs.com/shamo89/p/8016908.html
https://www.cnblogs.com/huangjuncong/p/9069749.html