-
服务端也称为分布式配置中心,它是一个独立的微服务应用,用来连接配置仓库并为客户端提供获取配置信息、加密信息等访问接口;
-
客户端则是微服务架构中的各个微服务应用或基础设施,它们通过指定的配置中心来管理应用资源与业务相关的配置内容,并在启动的时候从配置中心获取和加载配置信息。
SpringCloudConfig实现了对服务端和客户端中环境变量和属性配置的抽象映射,所以它除了适用于Spring构建的应用程序之外,也可以在任何其他语言运行的应用程序中使用。由于Spring Cloud Config实现的配置中心默认采用Git来存储配置信息,所以使用Spring Cloud Config 构建的配置服务器,天然就支持对微服务应用配置信息的版本管理,并且可以通过Git 客户端工具来方便地管理和访问配置内容。当然它也提供了对其他存储方式的支持,比如SVN仓库、本地化文件系统。接下来,我们从一个简单的入门示例开始学习Spring Cloud Config服务端以及客户端的详细构建与使用方法。
1.创建一个基础的SpringBoot web项目,命名为config-server
2.添加maven依赖
org.springframework.boot
spring-boot-starter-parent
2.5.2
com.cloud
config-server
0.0.1-SNAPSHOT
config-server
org.springframework.boot
spring-boot-starter-web
org.springframework.boot
spring-boot-starter-test
test
org.springframework.cloud
spring-cloud-config-server
3.0.0
org.springframework.cloud
spring-cloud-dependencies
2020.0.2
pom
import
3.在主配置类添加注解
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.config.server.EnableConfigServer;
@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {
public static void main(String[] args) {
SpringApplication.run(ConfigServerApplication.class, args);
}
}
修改application.properties文件
server.port=7001
应用名称
spring.application.name=config-server
注册服务的时候使用服务的ip地址
eureka.instance.prefer-ip-address=false
eureka.client.service-url.defaultZone=http://peer2:1112/eureka/
配置git仓库信息
你自己创建的远程仓库
spring.cloud.config.server.git.uri=https://gitee.com/ninesuntec/spring-cloud-config/
配置仓库下的相对搜索位置
spring.cloud.config.server.git.search-paths=spring_cloud_in_action/config-repo
访问git仓库的用户名
spring.cloud.config.server.git.username=登录git的邮箱
访问仓库的密码
spring.cloud.config.server.git.password=登录git的密码
下面是我的仓库数据:
注意:我圈起来的部分均是需要自己创建的目录
为了验证上面完成的分布式配置中心config-server,根据Git配置信息中指定的仓库位置,在spring_ cloud_ in_ action/config-repo下根据不同环境新建下面4个配置文件:
-
didispace.properties
-
didispace-dev.properties
-
didispace-test.properties
-
didispace-prod.properties
并且在这4个配置文件中均设置了一个from属性,分别如下所示
-
from=git-default-1.0
-
from=git-dev-1.0
-
from=git-test-1.0
-
from=git-prod-1.0
为了测试版本控制,在该Git仓库的master分支中,我们为from属性加入1.0的后缀,同时创建一个config-label-test分支,并将各配置文件中的值用2.0作为后缀。
git指令如下:
- 1.创建分支
git branch config-label-test
- 2.推送到云端
git push origin config-label-test
在config-label-test同样创建4个文件,但是内容的后缀改为2.0
from=git-default-2.0
from=git-dev-2.0
from=git-test-2.0
from=git-prod-2.0
完成这些准备工作之后,我们可以通过浏览器进行访问:
上面的url会映射{application}-{profile} .properties对应的配置文件,其中{ label}对应Git 上不同的分支,默认为master。
我们可以尝试构造不同的url来访问不同的配置内容,比如,要访问 config-label-test 分支,ninesuntec应用的prod环境,就可以访问这个url:
http://localhost:7001/didispace/prod/config-label-test/
并获得如下返回信息:
接下来我们尝试访问主分支上的didispace-dev.properties文件的内容
http://localhost:7001/didispace-dev.properties
我们再次尝试访问config-label-test分支上的内容
http://localhost:7001/config-label-test/didispace-dev.properties
创建一个新的springBoot web 应用命名为config-client,添加以下依赖
<?xml version="1.0" encoding="UTF-8"?><project xmlns=“http://maven.apache.org/POM/4.0.0” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=“http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd”>
4.0.0
org.springframework.boot
spring-boot-starter-parent
2.5.4
<java.version>11</java.version>
org.springframework.boot
spring-boot-starter-web
org.springframework.boot
spring-boot-starter-test
test
org.springframework.cloud
spring-cloud-starter-config
3.0.4
org.springframework.cloud
spring-cloud-starter-bootstrap
3.0.3
org.springframework.cloud
spring-cloud-dependencies
2020.0.2
pom
import
添加bootstrap.properties
spring.application.name=didispace
注册服务的时候使用服务的ip地址
eureka.instance.prefer-ip-address=true
eureka.client.service-url.defaultZone=http://peer2:1112/eureka/
#指定的环境
spring.cloud.config.profile=dev
#指定分支,当使用git的时候,默认是master
spring.cloud.config.label=master
#Config server的uri
spring.cloud.config.uri=http://localhost:7001/
配置项目启动端口号
server.port=7002
注意:spring.application.name要和你git仓库中的配置前缀相对应
这里需要格外注意,上面这些属性必须配置在 bootstrap.properties 中,这样config-server中的配置信息才能被正确加载
修改主配置类
@SpringBootApplication
@EnableDiscoveryClient
public class ConfigClientApplication {
public static void main(String[] args) {
SpringApplication.run(ConfigClientApplication.class, args);
}
}
创建一个RESTful接口来返回配置中心的from 属性
通过@value ("${from} ")绑定配置服务中配置的from属性,具体实现如下:
//@RefreshScope是为了可以动态刷新这个Controller的Bean
@RefreshScope
@RestController
public class TestController {
@Value(“${from}”)
private String from;
@RequestMapping(value = “from”, method = RequestMethod.GET)
public String from() {
return this.from;
}
}
重启项目访问http://localhost:7002/from
除@Value之外,我们还可以通过Environment对象来获取配置属性,比如:
//@RefreshScope是为了可以动态刷新这个Controller的Bean
@RefreshScope
@RestController
public class TestEnviromentController {
@Autowired
private Environment env;
@RequestMapping(value = “from-env”, method = RequestMethod.GET)
public String from() {
return env.getProperty(“from”, “undefined”);
}
}
接下来我们深入理解一下这个架构是怎么运作起来的,主要包含以下几个要素:
-
远程Git仓库:用来存储配置文件的地方,上例中我们用来存储针对应用名为didispace的多环境配置文件:didispace-{profile }.properties。
-
Config Server:这是我们上面构建的分布式配置中心,config-server工程,在该工程中指定了所要连接的Git仓库位置以及账户、密码等连接信息。
-
本地Git仓库:在 Config Server 的文件系统中,每次客户端请求获取配置信息时,Config Server从 Git仓库中获取最新配置到本地,然后在本地Git仓库中读取并返回。当远程仓库无法获取时,直接将本地内容返回。
-
Service A、Service B:具体的微服务应用,它们指定了Config Server 的地址,从而实现从外部化获取应用自己要用的配置信息。这些应用在启动的时候,会向ConfigServer请求获取配置信息来进行加载。
客户端应用从配置管理中获取配置信息遵从下面的执行流程:
-
1.应用启动时,根据bootstrap.properties中配置的应用名{application }、环境名{profile}、分支名{ label},向Config Server请求获取配置信息。
-
2.Config Server根据自己维护的Git仓库信息和客户端传递过来的配置定位信息去查找配置信息。
-
3.通过git clone命令将找到的配置信息下载到Config Server的文件系统中。
-
4.Config Server 创建Spring 的 ApplicationContext实例,并从Git 本地仓库中加载配置文件,最后将这些配置内容读取出来返回给客户端应用。
-
5.客户端应用在获得外部配置文件后加载到客户端的Applicationcontext实例,该配置内容的优先级高于客户端Jar包内部的配置内容,所以在Jar包中重复的内容将不再被加载。
Config Server巧妙地通过git clone 将配置信息存于本地,起到了缓存的作用,即使当Git服务端无法访问的时候,依然可以取 Config Server 中的缓存内容进行使用。
由于配置中心存储的内容比较敏感,做一定的安全处理是必需的。为配置中心实现安全保护的方式有很多,比如物理网络限制、OAuth2授权等。不过,由于我们的微服务应用和配置中心都构建于Spring Boot基础上,所以与Spring Security结合使用会更加方便。
我们只需要在config-server配置中心的pom.xml中加入spring-boot-starter-security 依赖,不需要做任何其他改动就能实现对配置中心访问的安全保护。
org.springframework.boot
spring-boot-starter-security
2.5.4
当我们重启项目之后,会给出一个默认的随机生成的密码,但是我们在实际开发中 一般会自己去定义一个用户名和密码
设置访问配置的用户名和密码
spring.security.user.name=root
spring.security.user.password=123456
由于我们设置了用户名和密码,所以在client进行连接时如果没有设置响应的安全信息,那么获取配置就会返回401错误
解决方式如下:在config-client的配置中添加:
设置安全访问的用户名和密码
spring.cloud.config.username=root
spring.cloud.config.password=123456
当要将配置中心部署到生产环境中时,与服务注册中心一样,我们也希望它是一个高可用的应用。
Spring Cloud Config实现服务端的高可用非常简单,主要有以下两种方式:
- 传统模式:不需要为这些服务端做任何额外的配置,只需要遵守一个配置规则,将所有的Config Server都指向同一个Git仓库,这样所有的配置内容就通过统一的共享文件系统来维护。而客户端在指定Config Server位置时,只需要配置Config Server上层的负载均衡设备地址即可,就如下图所示的结构。
- 服务模式:除了上面这种传统的实现模式之外,我们也可以将Config Server作为一个普通的微服务应用,纳入 Eureka 的服务治理体系中。这样我们的微服务应用就可以通过配置中心的服务名来获取配置信息,这种方式比起传统的实现模式来说更加有利于维护,因为对于服务端的负载均衡配置和客户端的配置中心指定都通过服务治理机制一并解决了,既实现了高可用,也实现了自维护。
由于这部分的实现需要客户端的配合,具体示例我将会在下面的“客户端详解”一节中的“服务化配置中心”小节中进行展示。
服务化配置中心
在本节中我们将config-server注册到服务中心,并且通过服务发现来访问config-server并获取git仓库中的配置信息。
1.服务端配置
在config-server的pom文件中添加以下依赖:
## 最后自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Java工程师,想要提升技能,往往是自己摸索成长,自己不成体系的自学效果低效漫长且无助。
因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,不论你是刚入门Android开发的新手,还是希望在技术上不断提升的资深开发者,这些资料都将为你打开新的学习之门!
如果你觉得这些内容对你有帮助,需要这份全套学习资料的朋友可以戳我获取!!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
服务化配置中心
在本节中我们将config-server注册到服务中心,并且通过服务发现来访问config-server并获取git仓库中的配置信息。
1.服务端配置
在config-server的pom文件中添加以下依赖:
## 最后自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Java工程师,想要提升技能,往往是自己摸索成长,自己不成体系的自学效果低效漫长且无助。
因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
[外链图片转存中…(img-arwNGFeD-1715080482292)]
[外链图片转存中…(img-OqFkWdb9-1715080482292)]
[外链图片转存中…(img-lB4xMeqA-1715080482293)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,不论你是刚入门Android开发的新手,还是希望在技术上不断提升的资深开发者,这些资料都将为你打开新的学习之门!
如果你觉得这些内容对你有帮助,需要这份全套学习资料的朋友可以戳我获取!!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!