SpringCloud分布式配置中心浅谈

一、什么是分布式配置中心?

Spring Cloud Config为服务端和客户端提供了分布式系统的外部化配置支持。配置服务器为各应用的所有环境提供了一个中心化的外部配置。它实现了对服务端和客户端对Spring Environment和PropertySource抽象的映射,所以它除了适用于Spring构建的应用程序,也可以在任何其他语言运行的应用程序中使用。作为一个应用可以通过部署管道来进行测试或者投入生产,我们可以分别为这些环境创建配置,并且在需要迁移环境的时候获取对应环境的配置来运行。

二、使用配置中心的好处

当我们系统业务扩展到一定程度的时候;免不了会增加很多的配置文件和信息,例如证书文件、接口对接的参数信息、数据库连接信息等;传统的单体式架构系统,SSH、SSM还是Struts等,只能是一个文件一个文件的增加堆积到项目系统中。每次更改配置信息的时候,都要重启服务器,影响线上业务浪费时间等。当配置文件数量达到一定程度的时候,整个项目就会看起来非常臃肿冗余,更甚者可能会拿错配置信息导致程序崩溃等。那么,这时候分布式系统采用的配置中心的优势就突出出来了。由业务拆分的多个模块系统的各配置文件,全部配置在配置中心统一管理;与程序分离,做到动态配置获取配置信息。无需重启服务器即可动态刷新加载配置信息。

GitLab的使用见另一篇文章:GitLab的使用和优势

三、SrpingCloudConfig基本配置原理

git 上存放我们的远程配置文件 

config-server 连接到 git 

config-client 连接到config-server 

当我们启动config-client 服务的时候,client 会通过连接的 config-server 拿到远程git 上面的配置文件,然后通过 Spring 加载到对象中

1、搭建Config Server注册中心

pom.xml依赖

        org.springframework.cloud

        spring-cloud-config-server

创建Spring Boot的程序主类,并添加@EnableConfigServer注解,开启Config Server

@EnableConfigServer

@SpringBootApplication

public class Application {

    public static void main(String[] args) {

        new SpringApplicationBuilder(Application.class).web(true).run(args);

    }

}

application.properties中配置服务信息以及git信息;由于开发完成后,Config Server的svn权限以及配置信息等,都已做了限制权限,没法查阅。

简单介绍下:

# gitLab管理配置,仓库位置,连接信息,url等

# gitLab用户名

# gitLab密码

配置仓库中,根据不同环境新建了下面四个配置文件:

didispace.properties

didispace-dev.properties

didispace-test.properties

didispace-prod.properties

同时创建一个config-label-test分支,并将各配置文件中的值用2.0作为后缀

URL与配置文件的映射关系如下:

/{application}/{profile}[/{label}]

/{application}-{profile}.yml

/{label}/{application}-{profile}.yml

/{application}-{profile}.properties

/{label}/{application}-{profile}.properties

搭建好config Server后,就把服务注册到Eureka;经过zuul进行路由转发,以供各个服务模块可以调用。

Zuul的原理和使用介绍见另一篇文章:SpringCloud的路由网关Zuul简单使用介绍

2、客户端config Client调用服务端Server获取配置

整个系统只能有一个Config Server服务中心,其他模块只能作为客户端config Client注册到Eureka中,然后读取服务中心的配置信息。(SpringCloud的生态决定,不能有多个服务中心)

pom.xml依赖

        org.springframework.cloud

        spring-cloud-starter-config

创建bootstrap.properties配置,来指定config server

#bootstrap.properties的加载也是先于application.properties

#bootstrap.properties配置,来指定config server

#对应前配置文件中的{application}部分

spring.application.name=didispace

#对应前配置文件中的{profile}部分

spring.cloud.config.profile=test

#对应前配置文件的git分支

spring.cloud.config.label=config-label-test

#配置中心的地址

spring.cloud.config.uri=http://localhost:7001/

#spring boot port

server.port=7002

spring.application.name:对应前配置文件中的{application}部分

spring.cloud.config.profile:对应前配置文件中的{profile}部分

spring.cloud.config.label:对应前配置文件的git分支

spring.cloud.config.uri:配置中心的地址

上面这些属性必须配置在bootstrap.properties中,config部分内容才能被正确加载。因为config的相关配置会先于application.properties,而bootstrap.properties的加载也是先于application.properties。


创建最基本的Spring Boot启动主类

@SpringBootApplication

public class Application {

    public static void main(String[] args) {

        new SpringApplicationBuilder(Application.class).web(true).run(args);

    }

}


config-client 工程中添加依赖监控模块,其中包含了/refresh刷新API

            org.springframework.boot

            spring-boot-starter-actuator

            true

在需要自动更新配置变量的Java类上,使用注解 @RefreshScope 修饰


 以后当我们再更新git上面的配置文件后,在 config-client 端执行POST 请求 http://localhost:8080/refresh 就可以更新刷新配置变量到内存中了。


这样就做到,配置一个Config Server注册中心,在Gitlab下配置各模块和对应环境的配置信息;Confid Client通过Eureka经由Zuul网关路由读取到对应的配置;达到动态分布式配置中心读取的效果。


关注个人技术公众号:nick_coding1024

不定期分享最新前沿技术框架和bat大厂常用技术等,加群不定期分享行业内大牛直播讲课以及获得内退一线互联网公司机会。

---------------------CSDN技术博客

原文:https://blog.csdn.net/xuri24/article/details/84957157

你可能感兴趣的:(SpringCloud分布式配置中心浅谈)