原文:https://www.cnblogs.com/hellxz/p/9306507.html 我在这略作修改
随着线上项目变的日益庞大,每个项目都散落着各种配置文件,如果采用分布式的开发模式,需要的配置文件随着服务增加而不断增多。某一个基础服务信息变更,都会引起一系列的更新和重启,运维苦不堪言也容易出错。配置中心便是解决此类问题的灵丹妙药。
市面上开源的配置中心有很多,BAT每家都出过,360的QConf、淘宝的diamond、百度的disconf都是解决这类问题。国外也有很多开源的配置中心Apache的Apache Commons Configuration、owner、cfg4j等等。这些开源的软件以及解决方案都很优秀,但是我最钟爱的却是Spring Cloud Config,因为它功能全面强大,可以无缝的和spring体系相结合,够方便够简单颜值高我喜欢。
Spring Cloud Config
在我们了解spring cloud config之前,我可以想想一个配置中心提供的核心功能应该有什么
- 提供服务端和客户端支持
- 集中管理各环境的配置文件
- 配置文件修改之后,可以快速的生效
- 可以进行版本管理
- 支持大的并发查询
- 支持各种语言
Spring Cloud Config可以完美的支持以上所有的需求。
Spring Cloud Config项目是一个解决分布式系统的配置管理方案。它包含了Client和Server两个部分,server提供配置文件的存储、以接口的形式将配置文件的内容提供出去,client通过接口获取数据、并依据此数据初始化自己的应用。Spring cloud使用git或svn存放配置文件,默认情况下使用git,我们先以git为例做一套示例。
使用IDEA自动构建springboot项目勾选config中的config-server
这样也不用去搞pom 是那个版本的了,自己自动构建好了,基本网上的教程中的注解都可以匹配引入到,然后按网上的做一个配置文件
一开始我用的properties 方式配置,但是始终无法正确启动,三番五次,放弃,按照yml方式将配置,最终成功启动,但是git 的路径用户名密码都是一样的粘贴出来的
报的错是 you need git url 但是我明明是配置过的,改成yml 方式之后也是用的同样的url 之后就可以正常启动了。
server:
port: 8040
spring:
application:
name: spring-config-server
cloud:
config:
server:
git:
uri: https://github.com/gfdsfsdeous/fdsrain.git
search-paths: conf-repo
username: XXXXX@Gmail.com
password: XXXXpassword
启动之后直接访问在这之前需在git上先新建文件夹conf-repo search-paths指的是你的库的相对地址url 指的是这个库中的url在下图中,用户名密码配上就可以了。
配置规则详解
还记得最开始我们建的那几个测试文件的命名规则么?
- hellxztest.yml
- hellxztest-dev.yml
- hellxztest-stable.yml
- hellxztest-prod.yml
这里的application可以自定义为其它的名称,这里可以用应用的名称,即应用名
,后边的dev、stable、prod这些都可以视为一个应用下多个不同的配置文件,可以当做环境名,以下均用环境名
代称。
Config支持我们使用的请求的参数规则为:
- / { 应用名 } / { 环境名 } [ / { 分支名 } ]
- / { 应用名 } - { 环境名 }.yml
- / { 应用名 } - { 环境名 }.properties
- / { 分支名 } / { 应用名 } - { 环境名 }.yml
- / { 分支名 } / { 应用名 } - { 环境名 }.properties
注意:
- 第一个规则的分支名是可以省略的,默认是master分支
- 无论你的配置文件是properties,还是yml,只要是应用名+环境名能匹配到这个配置文件,那么就能取到
- 如果是想直接定位到没有写环境名的默认配置,那么就可以使用default去匹配没有环境名的配置文件
- 使用第一个规则会匹配到默认配置
- 如果直接使用应用名来匹配,会出现404错误,此时可以加上分支名匹配到默认配置文件
- 如果配置文件的命名很由多个-分隔,此时直接使用这个文件名去匹配的话,会出现直接将内容以源配置文件内容直接返回,内容前可能会有默认配置文件的内容(已测试)