背景
==
有多少次因为配置文件忘记修改导致重新发布
有多少次因为无法实时修改配置导致重新发布
有多少次同一个配置在不同项目需要重复修改
有多少次因为配置导致项目启动失败！！！
配置服务中心
======
config官网文档
- 面对上面种种的问题
springcloud为我们提供一种解决方案---Springcloud Config它为分布式微服务提供了集中化的外部配置支持，配置服务器为微服务下所有环境提供配置中心 Springcloud Config分为服务端和客户端、服务端就是本节介绍的对象。而客户端就是嵌入在各个微服务中和服务端进行交互的从而实现配置的动态获取
pom
- 还是一样的味道我们通过
framework-root框架来实现我们config中心，首先继承framework-root然后在pom中添加如下坐标
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>application.yml
- 除了一些基本的参数设定以外我们需要指定config拉取的仓库即git相关信息
server:
port: 8070
spring:
application:
name: config-server
cloud.config.server.git:
uri: https://gitee.com/zxhTom/spring-cloud-demo
searchPaths: helloworldconfig启动类
@SpringBootApplication
@EnableConfigServer
public class ConfigApplication {
public static void main(String[] args) {
SpringApplication.run(ConfigApplication.class,args);
}
}测试
--
- 你没看错！就是这简单或者说还是之前的配方。我们只需要引包、配置、启动即可！这就是spring的强大之处或者说是
springboot的开箱即用的强大之处 - 我们访问
http://localhost:8070/master/config-server-dev.properties就会将https://gitee.com/zxhTom/spring-cloud-demo项目下master分支下的helloworldconfig文件夹下的config-server-dev.properties文件读取出来！ - 请注意下，笔者的
config仓库后续会有变动。最终读者的演示情况和笔者这里略有不同！！！
路径规则
- 上面我们已经可以通过接口的形式访问到我们的配置文件了。但是那只是其中一种方式我们换个接口同样可以访问到
http://localhost:8070/config-server-dev.yml。那么config的代理访问肯定是按照一定规律来的。我们访问官网，官网已经帮我们整理好了
/{application}/{profile}[/{label}]
/{application}-{profile}.yml
/{label}/{application}-{profile}.yml
/{application}-{profile}.properties
/{label}/{application}-{profile}.properties- 咋一看，心里万马奔腾这是啥玩意呀。再仔细看看你会发现官网总结的太到位了。首先官网整理出的是三种访问格式：
resultful、yml、properties。当我们的接口满足其中一种格式的时候就会被config解析出来并有对应变量管理。 - 为了充分演示出效果，小哲这里新建了几个配置文件。当我们访问如下接口时会出现哪几种情况
http://localhost:8070/config/server-dev. - 按照我们上面的格式进行匹配，首先是
resultful结构的，那么就只有一种匹配方式得出application=config;profile=server-dev,label=null。label是可填的默认是master。 - 最终我们可以看到我们分析是没有问题，其中多处一个
version字段，这个笔者猜测是git commitId,因为我发现和提交记录一样。 而对应的配置文件就是propertySources里的文件。细心的朋友一定会发现这里为什么是个数组呢？这里笔者在官网上没有找到说明但是经过测试笔者这里整理出springcloud config映射规则
//后缀包括两种 。 回去找{label}分支下如下格式的文件
{application}/{profile}.[properties|yml]
{application}.[properties|yml]- 另外两种方式和
resultful差不多，只不过他返回的信息时精简版的。只返回配置文件中内容的并集。这里需要注意相同内容取前者，那么谁先谁后呢？这就需要我们resultful格式接口告诉我们了。 - 记住这个时候我们访问
http://localhost:8070/config-server.properties。 然后通过resultful风格来确定是来源哪里.这里在强调下上面hello为什么是yml。还记得上面我提到在这么多文件中如果存在相同的配置会优先去首位的。这是什么意思呢？ - 我们通过
resultful可以看出来会读取三个文件的配置分别是config-server.properties、config-server.yml、config.properties。 - 我们在分别看下这三个文件中的内容，hello这个key出现在两个文件中。然后在
resultful接口我们可以看出config-server.yml排在config.properties前面，所以我们通过文件后缀方式访问到的数据配置hello=yml。
配置读取客户端
=======
- 上面我们也提到了关于
config存在两个角色，config中心是用来统一为微服务提供服务的，剩下的就是嵌入在微服务中的。在配置微服务的config客户端之前我们先来梳理下springboot的一个注意点。 springboot的配置文件除了在加载顺序有不同之外，还有一点是文件名的区别。在springboot中其实存在两种配置文件名称；我们常用的是application开头的配置文件（application.yml和application.properties）。springcloud程序会创建一个bootstrap上下文同时他也是application上下文的父类！它负责从外部源加载配置属性，并解密本地外部配置文件中的属性。这两个上下文共享一个Environment，它是任何Spring应用程序的外部属性的来源。在springcloud中bootstrap类型的配置文件优先级最高所以不需要担心会被本地的配置所覆盖。- 我们客户端想要读取
config-server中心的配置数据我们就需要在bootstrap配置文件中配置。
bootstrap.yml
zxhtom: hello-zxhtom
spring:
cloud:
config:
label: master
name: config-server
profile: dev //这里和config-server解析不一样的是，他将访问master分支下的config-server-dev.yml或者properties文件
uri: http://localhost:8070application.yml
zxhtom: hello-zxhtom2
server:
port: 80
tomcat:
max-threads: 10pom
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>测试
--
- 首先引入
pom包这里大家应该都没有问题，其次我们在application.yml和bootstrap.yml两个配置文件中配置相同的东西。这个时候在bootstrap中不配置config东西。此时我们访问zxhtom参数得到的结果是application中的。当我们将config配置加进来之后我们访问到的是git远程仓库的东西。关于演示笔者这里就不演示了。因为上面配置完成之后我们只需要写个接口获取参数就可以了。
小瑕疵
- 但是存在一个小瑕疵，当我们远程仓库配置修改后我们的服务也需要跟着修改！这好坑啊，感情玩了半天我还在原地打转啊。除了解决多模块相同配置重复修改的问题，重启的问题还是没能解决。难道我们就只能如此了吗？
- 上面我们已经实现
config-server来读取远程仓库配置了。也实现了客户端通过config-server读取远程配置了。但是当我们修改git远程仓库上配置时，我们的config-server会实时的修改配置值，客户端确无法实时更新！解决办法就是重启。
动态刷新
====
- 发现问题才能不断进步当然前提你得承认问题！这是一个伟大的哲学家说的(我自己) 。
- 首先我们需要引入
actuator模块，这个我们在讲解hystrix模块的时候在父项目root中引入了。当时笔者一直出了在高版本中actuator中需要加入actuator前缀。 - 然后我们在获取配置的接口类上添加
@RefreshScope。 记住这里一定要在这里加哦！！！ - 好了，到这里我们就解决了，现在启动我们的config客户端，在这里我们是
order模块。启动之后通过http://localhost/order/config/getConfig获取zxhtom这个值。
仍然不足
====
- 上面我们基于
actuator实现了动态刷新，但是这个动态刷新并不是自动刷新还是需要我们认为参与。实际项目生产使用中会有很多个微服务充电config-client角色。那么我们每次更新git仓库内容时是不是需要诶个调用接口呢？这显然是不行的。我也说了存在问题才能优化。那么我们该如何解决
奇技淫巧
====
脱离git
- 在
config-server中我们通过spring.cloud.config.server.git.uri中指定git远程仓库。如果我们在内网环境开发而且内网中我们没有自己搭建git服务呢。我们可以配置本地地址也可以实现读取指定外部仓库的。
spring.cloud.config.server.git.uri=file://xxxxxx/repository 多仓库
spring.cloud.config.server.git:
uri: https://gitee.com/zxhTom/spring-cloud-demo
searchPaths: helloworldconfig
repos:
dev:
pattern: dev/*
uri: file:///D:testrepositoryspring-cloud-demo
searchPaths: helloworldconfig- 上述配置
spring.cloud.config.server.git.uri是默认的仓库配置。然后根据repos来进行多仓库的配置。repos下跟了多少个就说明是多少个环境配置。比如我们上面的配置repos下只有dev一个配置，这个dev就是我们用于dev的环境。他的匹配模式是任何已dev开头的都将使用dev这个配置的仓库来进行我们上面匹配规则分析。
添加权限
- 如果你的公司没有单独部署git。如果你使用的就是
github这种公网性质。那么将我们项目中的配置放在这种地方是不是有点不安全呢？你的所有的服务的密码都被公开了。这样是极度不安全。那么我们要么自己单独部署git。要么将配置文件这个项目设置成私有 - 项目配置成私有我们config-server所在的服务可以通过ssh方式进行配置项目uri 。
- spring: cloud: config: server: git: username: xxxx password: xxxx
- 我们也可以通过如上配置方式将我们项目的用户名和密码配置，然后在通过http方式进行访问。这样也是可以的。
指定本地仓库位置
- 当我们通过接口访问获取远程仓库配置信息的时候，实际上config帮我们将远程仓库的文件拉取到本地路径上了。这个我们通过观察日志就可以看得出来。
- 可以证实我们没访问一次接口
config都会刷新本地文件库的。但是本地文件存储的位置其实是不固定的，项目每次启动当前项目所在的目录都会发生随机改变。文件路径为config-repo-随机id。会出现这么一种情况当我们重启的时候git挂了这个时候我们将无法获取但是因为随机id的原因我们将获取不到配置信息了。所以config` 可以让我们指定这个路劲。
spring.cloud.config.server.git.basedir: xxxxx 分模块读取配置
- 实际分布式项目中我们会有很多模块，如果我们都将放在同一层级的话会显得很多。这用并不是不能使用但是为了方便管理我们还是希望能够进行分类管理不同的服务请求过来进不同文件中进行匹配。
spring.cloud.config.server.git.searchPaths: '{application}'- 而application就是我们上文提到的通过地址分析中得到的那个application 。注意这里一定要加引号
总结
==
springcloud config模块极大的简化了我们微服务中重复配置的问题，默认使用的git来实现公共服务的获取的当然他也是支持svn，关于svn的整合呢笔者这里没有指出因为现在使用svn的公司应该很少了。如果非要使用svn的话也很简单。将uri地址换成svn的就可以了。前提引入如下包
<dependency>
<groupId>org.tmatesoft.svnkit</groupId>
<artifactId>svnkit</artifactId>
<version>1.8.10</version>
</dependency>- config作为配置中心将我们繁琐重复性的配置进行抽离。当然也不是一步到位的。随着业务的不断推进而做出改变的
我正在参与2023腾讯技术创作特训营第三期有奖征文，组队打卡瓜分大奖！
