此文章主要讲解 springcloud 中的分布式配置中心 Config 的相关知识,一般和 SpringCloud Bus 一同使用,绝代双骄。
什么是配置中心
配置中心概述
对于传统的单体应用而言,常使用配置文件来管理所有配置,比如 SpringBoot 的
application.yml
文件,但是在微服务架构中全部手动修改
的话很麻烦而且不易维护。微服务的配置管理一般有以下需求:
- 集中配置管理,一个微服务架构中可能有成百上千个微服务,所以
集中配置管理
很重要。
- 集中配置管理,一个微服务架构中可能有成百上千个微服务,所以
- 不同环境不同配置:比如数据源配置在不同环境(开发、测试、生产)中是不同的。
- 运行期间可动态调整。比如可以根据各个微服务的负载情况,动态调整数据源连接池的大小等。
- 配置修改后可以自动更新。比如配置内容发生改变,微服务可以自动更新配置。
综上所述,对于微服务架构来说,一套统一的、通用的管理配置机制是不可缺少的重要组成部分。常见的做法就是通过配置服务器进行管理。
常见的配置中心
Spring Cloud Config
- Spring Cloud Config 是分布式系统中的外部配置提供服务器和客户端支持。
Apollo(阿波罗)
- Apollo(阿波罗)是携程框架部门研发的分布式配置中心,能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性,适用于微服务配置管理场景。
Nacos
Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。
Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。
Spring Cloud Config
简介
Spring Cloud Config项目是一个解决分布式系统的配置解决方案。
它包含了 Client 和 Server 两个部分,Server 提供配置文件的存储,以接口的形式将配置文件的内容提供出去;Client 通过接口获取数据,并依据此数据初始化自己的应用。
Spring Cloud Config 为分布式系统的外部配置提供服务器和客户端支持。使用 Config Server,您可以为所有环境中的应用程序管理其外部属性。它非常适合 Spring 应用,也可以使用在其他语言的应用上。随着应用程序通过从开发到测试和生产的部署流程,您可以管理这些环境之间的配置,并确定应用程序具有迁移时需要运行的一切。服务器存储后端的默认
使用Git
,因此他轻松的支持标签版本的配置环境以及可以访问用于管理内容的各种工具。Spring Cloud Config服务端的特性:
- Http,为外部配置提供基于资源的 API(键值对或者等价的 YAML 内容)。
- 属性值的加密和解密(对称加密和非对称加密)。
- 通过使用@EnableConfigServer 在 Spring Boot 应用中非常简单的嵌入。
Spring Cloud Config客户端的特性:
- 绑定 Config 服务端,并使用远程的属性源初始化 Spring 环境。
- 属性值的加密和解密(对称加密和非对称加密)。
能干嘛?
入门案例
Git 配置
首先在github
或者gitee
上新建一个仓库 springcloud-config
然后使用 git 命令克隆到本地,命令
1 | git clone https://gitee.com/xiaojinggege/springcloud-config.git |
注意上面的操作不是必须的,只要 github 或者 gitee 上有就可以,克隆到本地只是修改文件。
在本地新建多个环境的配置文件,添加一点内容:
1 | config-dev.yml |
保存格式必须为UTF-8
,然后将文件 push 到 gitee 上
git 命令:
1 | git add . |
搭建工程
服务端配置
新建模块
cloud-config-center3344
POM 文件
1 |
|
YML 文件
1 | server: |
主启动类
1 |
|
添加映射
【C:\Windows\System32\drivers\etc\hosts】
文件中添加:
1 | 127.0.0.1 config-3344.com |
测试
启动微服务 3344
访问 http://config-3344.com:3344/master/config-dev.yml 文件,前提是 gitee 上有这个文件
文件命名和访问的规则
1 | /{application}/{profile}[/{label}] |
根据分支:
不加分支名默认是master。
客户端配置
这里的客户端指的是使用 Config Server 统一配置文件
的项目。
新建模块
cloud-config-client-3355
POM 文件
1 | <dependencies> |
配置 bootstrap.yml
bootstrap.yml 是
系统级别
的资源配置项,application.yml 是用户级别
的资源配置项。Spring Cloud 会创建一个“Boostrap Context”,作为 Spring 应用的“Application Context”的父上下文。初始化的时候,“Boostrap Context”负载从外部源加载配置属性并解析配置。这两个上下文共享一个从外部获取的“Environment”。
“Boostrap”属性有高优先级,默认情况下,不会覆盖本地配置项。“Bootstrap Context”和“Application Context”有着不同的约定,所以新增了一个“bootstrap.yml”,保证“BootStrap Context”和“Application Context”配置的分离。
要将Client模块下的application.yml改为bootstrap.yml
,很关键。因为 bootstrap.yml 比 application.yml 优先加载。bootstrap.yml优先级高于application.yml
。
1 | server: |
主启动类
1 |
|
Controller
用来测试读取配置信息
1 |
|
测试
访问: http://localhost:3355/configInfo ,这样就可以获取到信息。
手动刷新
出现问题
也就是 github 上面配置更新了,config Server 项目上是动态更新的,但是,client 端的项目中的配置,目前还是之前的,读取的是缓存,它不能动态更新,必须重启才行。
概述
我们已经在客户端获取到了配置中心的值,但是当我们修改 git 中的值的时候,服务端(Config Server)能实时的获取到最新的值,但是客户端(Config Client)读取的是缓存,无法实时获取最新值
。SpringCloud 已经为我们解决了这个问题,那就是客户端使用 POST 去触发 refresh,获取最新数据,需要依赖spring-boot-starter-actuator
。
解决
1、client 端一定要有如下依赖:
1 | <dependency> |
2、client 端增加 yml 配置如下,即在 bootstrap.yml 文件中增加如下内容:
1 | # 暴露监控端点 |
3、在 Controller 上添加注解 @RefreshScope
开启动态刷新。
测试
在 Git 服务器上修改配置之后,需要使用curl -X POST "http://localhost:3355/actuator/refresh"
向客户端发送一个 POST 请求。
两个必须:
- 必须是 POST 请求
- 请求地址:http://localhost:3355/actuator/refresh
其他问题
假如有多个微服务客户端,每个微服务都要执行一次 POST 请求手动刷新?
可否广播,一次通知,处处生效?
当微服务数量庞大,又是一个新的问题。
这样就引入了后面的消息总线Bus
!
配置中心的高可用
概述
在之前的代码中,客户端都是直接调用配置中心的 Server 端来获取配置信息。这样就存在了一个问题,客户端和服务端的耦合性太高,如果 Server 要做集群,客户端只能通过原始的方式来路由,Server 端改变 IP 地址的时候,客户端也需要修改配置,不符合 Spring Cloud 服务治理的概念。
Spring Cloud 提供了这样的解决方案,我们只需要将 Server 端当做一个服务注册到 Eureka 中,Client 端去 Eureka 中去获取配置中心 Server 端的服务即可。
服务端改造
1、导入 Eureka Client 的依赖
1 | <!-- 导入Eureka Client对应的坐标 --> |
2、application.yml
1 | server: |
客户端改造
1、bootstrap.yml
1 | spring: |
发布时间: 2021-01-20
最后更新: 2024-06-24
本文标题: SpringCloud Alibaba入门到精通(十)- 配置中心Config(不推荐)
本文链接: https://blog-yilia.xiaojingge.com/posts/fb877733.html
版权声明: 本作品采用 CC BY-NC-SA 4.0 许可协议进行许可。转载请注明出处!
