这篇文章主要介绍“选择Spring Cloud Config作为配置中心的原因是什么”,在日常操作中,相信很多人在选择Spring Cloud Config作为配置中心的原因是什么问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”选择Spring Cloud Config作为配置中心的原因是什么”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
成都创新互联公司是一家专业提供四方台企业网站建设,专注与成都网站建设、做网站、H5响应式网站、小程序制作等业务。10年已为四方台众多企业、政府机构等服务。创新互联专业网站建设公司优惠进行中。
一、Spring Cloud Config项目是一个解决分布式系统的配置解决方案。它包含了Client和Server两个部分,Server提供配置文件的存储,以接口的形式将配置文件的内容提供出去;Client通过接口获取数据,并依据此数据初始化自己的应用。
服务端也称为分布式配置中心,它是一个独立的微服务应用,用来连接配置仓库并为客户端提供获取配置信息、加密/解密信息等访问接口。
客户端则是微服务架构中的各个微服务应用或基础设施,它们通过指定的配置中心来管理应用资源与业务相关的配置内容,并在启动的时候从配置中心获取和加载配置信息。
二、Spring Cloud Config 默认采用 Git 来存储配置信息,所以使用 Spring Cloud Config 构建的配置服务器,天然就支持对微服务用于配置信息的版本管理,并且可以通过 Git 客户端工具来方便地管理和访问配置内容。
「注意:除了使用 Git 外,Spring Cloud Config 也同样支持其他存储方式比如:SVN、本地化文件系统等。」
首先我们新建一个配置文件system-dev.properties,内容如下
jdbc.driverClassName: com.MySQL.jdbc.Driver jdbc.url: jdbc:mysql://127.0.0.1:3306/testproject jdbc.username: root jdbc.password: root
然后我们将该配置文件上传了github,Demo地址:https://github.com/Maybe728/Spring_Cloud
第一步,新建一个SpringCloudConfigServer模块
pom.xml代码如下:
4.0.0 com.cnblogs.hellxz ConfigServer 1.0-SNAPSHOT org.springframework.cloud spring-cloud-starter-parent Dalston.SR5 org.springframework.cloud spring-cloud-config-server org.springframework.boot spring-boot-maven-plugin org.apache.maven.plugins maven-compiler-plugin 1.8
通过@EnableConfigServer可以激活配置中心服务。配置中心可以单独做服务,也可以嵌入到其它服务中。推荐用单独做服务方式使用配置中心。
package com.javaer.study; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.config.server.EnableConfigServer; /** * @Author 公众号 | Java学习部落 **/ @SpringBootApplication @EnableConfigServer public class SpringCloudConfigServerApplication { public static void main (String[] args) { SpringApplication.run (SpringCloudConfigServerApplication.class, args); } }
由于配置文件的存储的多样性,下面主要介绍Git配置形式如何配置。当然了所有的配置都配置在application.yml中。
application.yml 配置内容如下
spring: application: name: configserver cloud: config: server: git: # 配置文件只搜索url目录下的searchPaths uri: https://github.com/Maybe728/Spring_Cloud.git # 对应 {label} 部分,即 Git 的分支 label: master # 指定搜索路径,如果有多个路径则使用,分隔 search-paths: springcloud-config-git/config-repo # 对于使用git,svn做为后端配置,从远程库获取配置文件,需要存储到本地文件 basedir: /tmp/spring-cloud-repo # 配置中心通过git从远程git库,有时本地的拷贝被污染,这时配置中心无法从远程库更新本地配置,设置force-pull=true,则强制从远程库中更新本地库 force-pull: true # git 仓库用户名(公开库可以不用填写) username: # git 仓库密码(公开库可以不用填写) password:
spring.cloud.config.server.git.url
:指定配置文件所在远程git库的url地址
spring.cloud.config.server.git.label
:即 Git 的分支
spring.cloud.config.server.git.searchPaths
:和上面的参数url配合使用,定位git库的子目录。指定搜索路径,如果有多个路径则使用,分隔
spring.cloud.config.server.git.basedir
:对于使用git,svn做为后端配置,从远程库获取配置文件,需要存储到本地文件。默认存储在系统临时目录下,目录名的前缀为config-repo-,如在linux下时可能是/tmp/config-repo-。因为/tmp下的内容有可能被误删,所有为了保险,最好修改存储目录。如果你修改存储目录,你可以修改spring.cloud.config.server.git.basedir
spring.cloud.config.server.git.force-pull
:配置中心通过git从远程git库读取数据时,有时本地的拷贝被污染,这时配置中心无法从远程库更新本地配置。设置force-pull=true,则强制从远程库中更新本地库
最后我们启动程序后访问:http://localhost:8080/system-dev.properties
「成功!!!!!」
在浏览器中输入如下URL,可以访问到配置文件
/{application}/{profile}[/{label}]
/{application}-{profile}.yml
/{label}/{application}-{profile}.yml
/{application}-{profile}.properties
/{label}/{application}-{profile}.properties
下面通过具体例子说明以上url的意思。如果我们的配置文件名称system-dev.properties,则其和URL中各个字段对应的值为:
「application: system」
「profile: dev」
配置中心服务端配置成功后,然后其它服务从配置中心获取配置文件,这样的服务被称为**「客户端」**。
下面我们来搭建一个Config Client。
首先新建一个SpringCloudConfigClient项目:
「pom.xml」
4.0.0 org.springframework.boot spring-boot-starter-parent 2.4.1 com.javaer.study springcloudconfigclient 0.0.1-SNAPSHOT springcloudconfigclient Demo project for Spring Boot 1.8 2020.0.0 org.springframework.cloud spring-cloud-config-server org.springframework.cloud spring-cloud-starter-config org.springframework.boot spring-boot-starter-test test org.springframework.cloud spring-cloud-dependencies ${spring-cloud.version} pom import org.springframework.boot spring-boot-maven-plugin spring-milestones Spring Milestones https://repo.spring.io/milestone
请将配置中心的相关配置配置在bootstrap.yml中,不要配appliaction.yml。
因为服务启动时,会从bootstrap中读取配置,然后从远程配置中心读取配置文件,最后再从appliaction中获取配置,如果有相同的配置项,则后面的会覆盖前面读到的值。
所以如果配置中心的配置配置在appliaction,则配置项不会有任何效果。
「bootstrap.yml」
server: port: 8888 spring: cloud: # 配置服务器的地址 config: uri: http://127.0.0.1:8080 # 要读取配置文件读取的值 name: cloud-config # 如果不设置此值,则系统设置此值为 spring.profiles.active profile: dev # 可以使用之前的版本。默认值可以是git label, branch name or commit id。可以使用多个Label,多个Label可以使用逗号分隔 # label: # true: 如果访问配置中心失败,则停止启动服务 fail-fast: true # 配置重试,默认是重试6次,最初是延迟1s再次重试,如果再失败,则延迟1.1*1s、1.1*1.1*1s、… 。可以使用这个配置 retry: initial-interval: 2000 # 最多重试次数 max-attempts: 6 # 最大重试间隔 max-interval: 4000 # 每次重试时间是之前的倍数 multiplier: 1.2
重要参数的解释如下:
「配置中心的url」:即从哪里读取配置文件,通过“spring.cloud.config.url”配置
「要读取哪些配置文件,由以下参数共同决定」
“spring.cloud.config.name
”:配置文件名称,对应上文的读取URL中的{applicaion}值
“spring.cloud.config.profile
”:配置文件的profile,对应上文的URL中的{profile}值
“spring.cloud.config.label
”:可以使用之前的版本。默认值可以是git label, branch name or commit id。可以使用多个Label,多个Label可以使用逗号分隔
「快速失败」
如果要求客户端访问配置中心失败,则立即停止启动服务,则设置“spring.cloud.config.label”为 true
「重试」
如果访问配置失败,则自动重试。默认是重试**「6」次,最初是延迟「1s」**再次重试,如果再失败,则延迟1.1*1s、1.1*1.1*1s、…
。
通过下面参数可以修改值:
“spring.cloud.config.retry.initial-interval
”:第一次失败,延迟多久重试
“spring.cloud.config.retry.max-attempts
”:最多重试次数
“spring.cloud.config.retry.max-interval
”: 最大重试间隔
“spring.cloud.config.retry.multiplier
”: 每次重试时间是之前的倍数
「如果要实现重试功能,需要引入新的jar」
org.springframework.boot spring-boot-starter-aop org.springframework.retry spring-retry
创建一个获取配置信息成功后存放配置信息的对象
@Component public class JdbcConfigBean { @Value("${jdbc.url}") private String url; @Value("${jdbc.username}") private String username; @Value("${jdbc.password}") private String password; @Value("${jdbc.driverClassName}") private String driverClassName; public String getUrl() { return url; } public void setUrl(String url) { this.url = url; } public String getUsername() { return username; } public void setUsername(String username) { this.username = username; } public String getPassword() { return password; } public void setPassword(String password) { this.password = password; } public String getDriverClassName() { return driverClassName; } public void setDriverClassName(String driverClassName) { this.driverClassName = driverClassName; } @Override public String toString() { return "JdbcConfigBean [url=" + url + ", username=" + username + ", password=" + password + ", driverClassName=" + driverClassName + "]"; } }
创建一个Controller
package com.javaer.study; import org.springframework.web.bind.annotation.RequestMapping; /** * @author 公众号 | Java学习部落 **/ public class SpringCloudConfigController { @RequestMapping ("/config") public JdbcConfigBean config() { return new JdbcConfigBean (); } }
最后我们启动**「SpringCloudConfigClient」**,在浏览器输入http://127.0.0.1:8888/config,就会看到配置信息。
首先我们需要搭建一个Eureka Server,这个不细说,因为在之前讲解Eureka的时候阿里面试官问我:到底知不知道什么是Eureka,这次,我没沉默已经详细的搭建过了,不会的可以去看看,顺便补充下Eureka的相关知识。
接下来我们就要对配置中心进行改造了。
「改造服务端」
第一步引入Eureka客户端依赖
org.springframework.cloud spring-cloud-starter-netflix-eureka-client
第二步在配置中心中添加如下配置
eureka: instance: preferIpAddress: true client: serviceUrl: # 注册到 eureka defaultZone: http://localhost:8761/eureka
第三步在启动类加入@EnableDiscoveryClient激活对注册中心支持
package com.javaer.study; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.client.discovery.EnableDiscoveryClient; import org.springframework.cloud.config.server.EnableConfigServer; /** * @Author 公众号 | Java学习部落 **/ @SpringBootApplication @EnableConfigServer @EnableDiscoveryClient public class SpringCloudConfigServerApplication { public static void main (String[] args) { SpringApplication.run (SpringCloudConfigServerApplication.class, args); } }
「服务端改造完成!!!」
「改造客户端」
第一步同样引入Eureka Client 依赖
org.springframework.cloud spring-cloud-starter-netflix-eureka-client
第二步修改配置
eureka: client: serviceUrl: # 指向注册中心的地址 defaultZone: http://127.0.0.1:8761/eureka instance: preferIpAddress: true server: port: 8888 spring: cloud: # 配置服务器的地址 config: uri: http://127.0.0.1:8080 username: user password: 111111 # 要读取配置文件读取的值 name: system # 如果不设置此值,则系统设置此值为 spring.profiles.active profile: dev discovery: #表示开启服务发现,对比上篇也主要是这里的改变,从指定config服务地址到注册中心服务ID enabled: true serviceId: config-serve # 可以使用之前的版本。默认值可以是git label, branch name or commit id。可以使用多个Label,多个Label可以使用逗号分隔 # label: # true: 如果访问配置中心失败,则停止启动服务 fail-fast: true # 配置重试,默认是重试6次,最初是延迟1s再次重试,如果再失败,则延迟1.1*1s、1.1*1.1*1s、… 。可以使用这个配置 retry: initial-interval: 2000 # 最多重试次数 max-attempts: 6 # 最大重试间隔 max-interval: 4000 # 每次重试时间是之前的倍数 multiplier: 1.2
最后一步在启动类加入@EnableDiscoveryClient激活对注册中心支持。
「客户端改造完成!!!」
Config Server自带了一个健康状态指示器,用于检查所配置的EnvironmentRepository是否正常工作。
可使用Config Server的/health端点查询当前健康状态。
默认情况下,健康指示器向EnvironmentRepository请求的{application}是app,{profile}和{label}是对应 EnvironmentRepository实现的默认值。
对于Git,{profile}是default,{label}是master。
Config Server 有一个“属性覆盖”的特性,它可以让开发人员为所有的应用提供配置属性,只需要通过 spring.cloud.config.server.overrides 属性来设置键值对的参数,这些参数会以 Map 的方式加载到客户端的配置中。
利用该特性可以方便地为 Spring Cloud 应用配置一些共同属性或是默认属性。
通过该属性配置的参数(优先级高于 Git 仓库里面的配置),同时也不会被 Spring Cloud 的客户端修改。
所有 Spring Cloud 客户端从 Config Server 中获取配置信息时,都会取得这些配置信息。
我们知道,一般来说,配置中心的信息都是很敏感很机密的,比如数据库账号密码的配置,redis账号密码的配置等等,所以对配置信息做一定的安全保护是十分有必要的。
由于微服务是构建在Spring Boot之上,所以整合Spring Security是最方便的方式。
首先在服务端引入Spring Security依赖
org.springframework.boot spring-boot-starter-security
然后再配置文件中增加Spring Security配置
security: basic: enabled: true #启用基本认证(默认) user: #配置security用户名密码,默认值为“user”的用户名和随机生成的密码 name: user password: 111111
启动服务,测试一下。请求http://localhost:8080/system-dev.yml,会出现登陆界面
「成功!!!」
**「同时」我们在「SpringCloudConfigClient」工程中,我们修改「bootstrap.yml」配置文件(在这里配置了Config Server的访问信息),为其添加认证,我们选择添加「spring.cloud.config.username」和「spring.cloud.config.password」**属性
server: port: 8888 spring: cloud: # 配置服务器的地址 config: uri: http://127.0.0.1:8080 username: user password: 111111 # 要读取配置文件读取的值 name: system # 如果不设置此值,则系统设置此值为 spring.profiles.active profile: dev # 可以使用之前的版本。默认值可以是git label, branch name or commit id。可以使用多个Label,多个Label可以使用逗号分隔 # label: # true: 如果访问配置中心失败,则停止启动服务 fail-fast: true # 配置重试,默认是重试6次,最初是延迟1s再次重试,如果再失败,则延迟1.1*1s、1.1*1.1*1s、… 。可以使用这个配置 retry: initial-interval: 2000 # 最多重试次数 max-attempts: 6 # 最大重试间隔 max-interval: 4000 # 每次重试时间是之前的倍数 multiplier: 1.2
Spring Cloud Config 的客户端会预先加载很多其他信息,然后再开始连接 Config Server 进行属性的注入。当我们构建的应用较为复杂的时候,可能在连接 Config Server 之前花费较长的启动时间,而在一些特殊场景下,我们又希望可以快速知道当前应用是否能顺利地从 Config Server 获取到配置信息,这对在初期构建调试环境时,可以减少很多等待启动的时间。
首先如果我们不启动服务端 Config-Server,直接启动客户端应用时 如果未配置spring.cloud.config.fail-fast=true
这个参数,在配置加载报错之前,客户端应用便已经加载了很多内容,比如 Controller 的请求等。
如果配置了spring.cloud.config.fail-fast=true
参数,启动客户端后前置的加载内容会少很多,很快就报错。这样有效避免了当 Config-server 配置有误时,不需要多等待前置的一些加载时间,实现了快速返回失败信息。
「这个就是我们说的请求配置失败快速响应!!!」
有时可能因为网络波动等其他间歇性原因导致连接失败,Config 客户端还提供了重试功能,避免一些间歇性问题引起的失败导致客户端应用服务启动的情况。
要实现这个功能,首先我们要在在客户端的**「pom.xml」**中增加 spring-retry 和 spring-boot-starter-aop 依赖:
org.springframework.retry spring-retry org.springframework.boot spring-boot-starter-aop
然后配置了失败快速响应参数即可。
spring.cloud.config.fail-fast=true
重点配置解读。
spring.cloud.config.retry.multiplier
:初始重试间隔时间(单位为毫秒),默认值为 1000 毫秒
spring.cloud.config.retry.initial-interval
:下一间隔的乘数,默认为 1.1(当最初间隔为 1000 毫秒时,下一次失败的间隔为 1100 毫秒)
spring.cloud.config.retry.max-interval
:最大间隔时间,默认为 2000 毫秒
spring.cloud.config.retry.max-attempts
:最大重试此时,默认为 6 次
现在我们思考下这个问题:
如果在服务运行过程中,我们需要将验证码的失效时间从1分钟调整为2分钟,那么服务端如何在不重启服务的情况下就能使修改的配置动态生效呢?
这就是我们接下来要说的**「动态刷新」**
实现动态刷新配置有两种方式
使用Actuator
使用Spring Cloud Bus(后续会有专文介绍,再次不做讲解)
接下来我们就来使用Actuator来是实现动态刷新配置
首先我们在客户端的 pom.xml 中新增 spring-boot-starter-actuator 监控模块
org.springframework.boot spring-boot-starter-actuator
❝
spring-boot-starter-actuator 监控模块中包含了 /refresh 端点的实现,该端点将用于实现客户端应用配置信息的重新获取与刷新。
❞
接着编辑 application.properties 文件,添加如下配置开启 /refresh 端点:
management.endpoints.web.exposure.include=refresh
很简单到这儿客户端改造就结束了,我们只需要重启客户端,然后修改git中的配置信息,在重新获取配置信息我们就会发现已经配置信息已经修改了。
我们使用 /actuator/env 与 /actuator/refresh 两个接口可以实现单个服务实例配置的动态更新,但在微服务架构中,服务实例可能达几十甚至几百个,一个个调用来做动态更新就有点太不方便了。
到此,关于“选择Spring Cloud Config作为配置中心的原因是什么”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注创新互联网站,小编会继续努力为大家带来更多实用的文章!