标签:多少 文件中 html 病毒 mat ica 不能 config 公网
有多少次因为配置文件忘记修改导致重新发布
有多少次因为无法实时修改配置导致重新发布
有多少次同一个配置在不同项目需要重复修改
有多少次因为配置导致项目启动失败!!!
springcloud
为我们提供一种解决方案---Springcloud Config
它为分布式微服务提供了集中化的外部配置支持,配置服务器为微服务下所有环境提供配置中心Springcloud Config
分为服务端和客户端、服务端就是本节介绍的对象。而客户端就是嵌入在各个微服务中和服务端进行交互的从而实现配置的动态获取framework-root
框架来实现我们config中心,首先继承framework-root
然后在pom中添加如下坐标<dependency>
<groupid>org.springframework.cloud</groupid>
<artifactid>spring-cloud-config-server</artifactid>
</dependency>
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);
}
}
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
。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
配置文件中配置。zxhtom: hello-zxhtom
spring:
cloud:
config:
label: master
name: config-server
profile: dev //这里和config-server解析不一样的是,他将访问master分支下的config-server-dev.yml或者properties文件
uri: http://localhost:8070
zxhtom: hello-zxhtom2
server:
port: 80
tomcat:
max-threads: 10
<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
。 记住这里一定要在这里加哦!!!order
模块。启动之后通过http://localhost/order/config/getConfig
获取zxhtom这个值。actuator
实现了动态刷新,但是这个动态刷新并不是自动刷新还是需要我们认为参与。实际项目生产使用中会有很多个微服务充电config-client角色。那么我们每次更新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:\test\repository\spring-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-repo-随机id 。会出现这么一种情况当我们重启的时候git挂了这个时候我们将无法获取但是因为随机id的原因我们将获取不到配置信息了。所以
config` 可以让我们指定这个路劲。spring.cloud.config.server.git.basedir: xxxxx
spring.cloud.config.server.git.searchPaths: ‘{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>
【springcloud长文系列】不要每天重复修改配置了,试试config一处修改病毒式蔓延自动更新配置吧|智能化开发
标签:多少 文件中 html 病毒 mat ica 不能 config 公网
原文地址:https://www.cnblogs.com/zhangxinhua/p/14885463.html