Spring Cloud Config配置信息自动更新原理解析

2024-06-17 14:44

本文主要是介绍Spring Cloud Config配置信息自动更新原理解析,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

我们知道Spring Cloud Config是Spring Cloud提供的配置中心实现工具,我们可以通过它把配置信息存放在Git等第三方配置仓库中。每当Spring Cloud Config客户端启动时,就会发送HTTP请求到服务器端获取配置信息,这点比较好理解。但事实上,在Git中更改了配置信息之后,客户端并不会主动再次请求最新配置,而是使用缓存到本地的原有配置信息。


那么问题就来了,在这种情况下,Spring Cloud Config是如何能够实时获取更改后的配置呢?这就是今天我们要讨论的内容。通过理解Spring Cloud Config配置信息自动更新的执行过程,有助于我们深入把握框架的底层原理。

在对底层原理进行详细展开之前,我们先来给出Spring Cloud Config应对这一问题的具体做法。事实上,Spring Cloud Config能够做到配置信息的自动更新,是依赖于Spring Cloud中的另一个组件,即Spring Cloud Bus。

Spring Cloud Bus是Spring Cloud中用于实现消息总线的专用组件,集成了RabbitMQ、Kafka等主流消息中间件。当我们在Spring Cloud Config 服务器端代码工程的类路径中添加Spring Cloud Bus的引用并启动应用程序之后,Spring Boot Actuator就为我们提供了/actuator/bus-refresh端点,通过访问该端点就可以达到对客户端所有服务实例的配置信息进行自动更新的效果。在这种方案中,服务端会主动通知所有客户端进行配置信息的更新,这样我们就无需关注各个客户端,而只对服务端进行操作即可。

是不是听起来有点神奇?整个实现过程我们至少要搞清楚三大问题,如下图所示。


针对这三个问题,接下去我们将结合源码逐一展开讨论。

问题一:如何自动调用服务器端所暴露的/actuator/bus-refresh端点?

在现代软件开发过程中,开放式平台是一种常见的软件服务形态。我们可以把Spring Cloud Config Server所提供的HTTP端点视为一种开放式的接口,以供Git等第三方工具进行访问和集成。基于这种思想,我们可以把服务器端/actuator/bus-refresh端点对外进行暴露,然后第三方工具通过这个暴露的端点进行集成。例如,在Github中就设计了一种Webhook机制,并提供了用户界面供我们配置所需要集成的端点以及对应的操作,操作方法如下图所示。


我们可以在上图的Payload URL中设置/actuator/bus-refresh端点地址。所谓的Webhook,实际上就是一种回调。通过Webhook,当我们提交代码时,Github就会自动调用所配置的HTTP端点。也就是说,可以根据配置项信息的更新情况自动实现对/actuator/bus-refresh端点的访问。基于Github的配置仓库实现方案,我们可以得到如下图所示的系统结构图。


现在,配置信息一旦有更新,Spring Cloud Config Server就能从Github中获取最新的配置信息了。

问题二:客户端如何得知服务器端的配置信息已经更新?

接下来我们关注第二个问题,即客户端如何得知服务器端的配置信息已经更新?我们首先需要明确调用了/actuator/bus-refresh端点之后,系统内部会发生了么。这里我们快速浏览Spring Cloud Bus中的代码工程,发现存在一个RefreshBusEndpoint端点类,如下所示。

@Endpoint(id = "bus-refresh")

public class RefreshBusEndpoint extends AbstractBusEndpoint {

@WriteOperation

public void busRefreshWithDestination(@Selector String destination) {

//发布RefreshRemoteApplicationEvent事件

publish(new RefreshRemoteApplicationEvent(this, getInstanceId(), destination));

}

@WriteOperation

public void busRefresh() {

//发布RefreshRemoteApplicationEvent事件

publish(new RefreshRemoteApplicationEvent(this, getInstanceId(), null));

}

}

显然,RefreshBusEndpoint类对应于我们前面访问的/bus-refresh端点。可以看到,Spring Cloud Bus在这里做的事情仅仅只是发布了一个新的RefreshRemoteApplicationEvent事件。

既然发送了事件,我们就需要寻找该事件的监听者。我们在Spring Cloud Bus中找到了RefreshRemoteApplicationEvent事件的监听器RefreshListener,如下所示。

public class RefreshListener implements ApplicationListener<RefreshRemoteApplicationEvent> {

@Override

public void onApplicationEvent(RefreshRemoteApplicationEvent event) {

//执行配置属性的刷新操作

Set<String> keys = contextRefresher.refresh();

}

}

从类的定义中不难看出该监听器就是用来处理RefreshRemoteApplicationEvent事件。可以看到,在它的onApplicationEvent方法中同样也是调用了ContextRefresher中的refresh方法进行配置属性的刷新。

请注意,RefreshRemoteApplicationEvent是一个远程事件,将通过消息中间件进行发送,并被Spring Cloud Config客户端所监听,处理流程如下图所示。


问题三:客户端如何实时获取服务器端所更新的配置信息?

最后需要明确的第三个问题是,客户端如何获取服务器端所更新的配置信息,这就需要梳理Spring Cloud Config Server与注册中心之间的关系。

我们知道配置中心作为整个微服务架构运行所需的基础服务,需要确保其可用性。因为配置服务本身也是一个独立的微服务,所以Spring Cloud Config实现高可用的方式很简单。跟其他微服务一样,它把自己注册到注册中心上,让其他服务提供者或消费者通过注册中心进行服务发现和获取。


显然,在这种方式下,注册中心的服务治理机制同时提供了服务器端的负载均衡和客户端的配置功能,从而也就间接实现了高可用性。从另一个角度,我们也可以理解为可以通过注册中心获取所有Spring Cloud Config客户端服务的实例,从而在分布式环境下为获取配置信息提供了一种简便的手段。

Spring Cloud Config提供了一个工具类ConfigServerInstanceProvider来完成与注册中心之间的交互,如下所示。

public class ConfigServerInstanceProvider {

private final DiscoveryClient client;

  

@Retryable(interceptor = "configServerRetryInterceptor")

public List<ServiceInstance> getConfigServerInstances(String serviceId) {

List<ServiceInstance> instances = this.client.getInstances(serviceId);

if (instances.isEmpty()) {

//抛出异常

}

return instances;

}

}

在这里,我们看到了熟悉的DiscoveryClient,DiscoveryClient通过同样熟悉的getInstances方法从注册中心中获取Spring Cloud Config服务器实例,如下所示。

List<ServiceInstance> instances = this.client.getInstances(serviceId);

ConfigServerInstanceProvider的调用者是DiscoveryClientConfigServiceBootstrapConfiguration。我们来看这个Spring Boot自动配置类的定义,如下所示。

public class DiscoveryClientConfigServiceBootstrapConfiguration

implements SmartApplicationListener {

public void startup(ContextRefreshedEvent event) {

refresh();

}

}

可以看到,如果系统中生成了ContextRefreshedEvent事件就会触发如下所示的refresh方法。

private void refresh() {

try {

获取Spring Cloud Config客户端服务实例

String serviceId = this.config.getDiscovery().getServiceId();

List<String> listOfUrls = new ArrayList<>();

List<ServiceInstance> serviceInstances = this.instanceProvider.getConfigServerInstances(serviceId);

//遍历服务实例列表

for (int i = 0; i < serviceInstances.size(); i++) {

ServiceInstance server = serviceInstances.get(i);

String url = getHomePage(server);

  //获取配置路径

if (server.getMetadata().containsKey("configPath")) {

String path = server.getMetadata().get("configPath");

if (url.endsWith("/") && path.startsWith("/")) {

url = url.substring(0, url.length() - 1);

}

url = url + path;

}

  //填充配置路径

listOfUrls.add(url);

}

String[] uri = new String[listOfUrls.size()];

uri = listOfUrls.toArray(uri);

this.config.setUri(uri);

}

}

在上述refresh方法中,Spring Cloud Config首先会获取配置文件中配置项spring.cloud.config.discovery.serviceId所指定的服务实例id,然后根据serviceId从ConfigServerInstanceProvider中获取注册服务的实例对象集合serviceInstances,最后循环遍历serviceInstances来更新存储在内存中的配置属性值。

至此,我们通过解答三个问题,引出了Spring Cloud Config中实现配置信息自动更新的三个步骤,并基于框架内部一系列组件之间的交互过程剖析了底层实现原理。

总结

作为一个配置中心技术实现上的难点,今天的内容基于Spring Cloud Config框架剖析了实现配置信息自动更新的工作原理。我们抛出了三个与这个主题相关的核心问题,然后基于源码对这些问题都做了一一解答。

事实上,Spring Cloud Config作为Spring自研的配置中心框架,其内部大量使用了Spring现有的功能特性,比方说本讲中提到的Spring容器的事件发布和监听机制,又比方说Spring Boot Acuator中的端点机制以及Spring Cloud Bus所具备的消息通信总线机制。我们需要首先对Spring容器相关的知识体系有足够的了解,才能更好的理解Spring Cloud Config的设计和实现方式。

这篇关于Spring Cloud Config配置信息自动更新原理解析的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1069734

相关文章

网页解析 lxml 库--实战

lxml库使用流程 lxml 是 Python 的第三方解析库,完全使用 Python 语言编写,它对 XPath表达式提供了良好的支 持,因此能够了高效地解析 HTML/XML 文档。本节讲解如何通过 lxml 库解析 HTML 文档。 pip install lxml lxm| 库提供了一个 etree 模块,该模块专门用来解析 HTML/XML 文档,下面来介绍一下 lxml 库

JVM 的类初始化机制

前言 当你在 Java 程序中new对象时,有没有考虑过 JVM 是如何把静态的字节码(byte code)转化为运行时对象的呢,这个问题看似简单,但清楚的同学相信也不会太多,这篇文章首先介绍 JVM 类初始化的机制,然后给出几个易出错的实例来分析,帮助大家更好理解这个知识点。 JVM 将字节码转化为运行时对象分为三个阶段,分别是:loading 、Linking、initialization

Spring Security 基于表达式的权限控制

前言 spring security 3.0已经可以使用spring el表达式来控制授权,允许在表达式中使用复杂的布尔逻辑来控制访问的权限。 常见的表达式 Spring Security可用表达式对象的基类是SecurityExpressionRoot。 表达式描述hasRole([role])用户拥有制定的角色时返回true (Spring security默认会带有ROLE_前缀),去

浅析Spring Security认证过程

类图 为了方便理解Spring Security认证流程,特意画了如下的类图,包含相关的核心认证类 概述 核心验证器 AuthenticationManager 该对象提供了认证方法的入口,接收一个Authentiaton对象作为参数; public interface AuthenticationManager {Authentication authenticate(Authenti

Spring Security--Architecture Overview

1 核心组件 这一节主要介绍一些在Spring Security中常见且核心的Java类,它们之间的依赖,构建起了整个框架。想要理解整个架构,最起码得对这些类眼熟。 1.1 SecurityContextHolder SecurityContextHolder用于存储安全上下文(security context)的信息。当前操作的用户是谁,该用户是否已经被认证,他拥有哪些角色权限…这些都被保

Spring Security基于数据库验证流程详解

Spring Security 校验流程图 相关解释说明(认真看哦) AbstractAuthenticationProcessingFilter 抽象类 /*** 调用 #requiresAuthentication(HttpServletRequest, HttpServletResponse) 决定是否需要进行验证操作。* 如果需要验证,则会调用 #attemptAuthentica

Spring Security 从入门到进阶系列教程

Spring Security 入门系列 《保护 Web 应用的安全》 《Spring-Security-入门(一):登录与退出》 《Spring-Security-入门(二):基于数据库验证》 《Spring-Security-入门(三):密码加密》 《Spring-Security-入门(四):自定义-Filter》 《Spring-Security-入门(五):在 Sprin

Java架构师知识体认识

源码分析 常用设计模式 Proxy代理模式Factory工厂模式Singleton单例模式Delegate委派模式Strategy策略模式Prototype原型模式Template模板模式 Spring5 beans 接口实例化代理Bean操作 Context Ioc容器设计原理及高级特性Aop设计原理Factorybean与Beanfactory Transaction 声明式事物

Zookeeper安装和配置说明

一、Zookeeper的搭建方式 Zookeeper安装方式有三种,单机模式和集群模式以及伪集群模式。 ■ 单机模式:Zookeeper只运行在一台服务器上,适合测试环境; ■ 伪集群模式:就是在一台物理机上运行多个Zookeeper 实例; ■ 集群模式:Zookeeper运行于一个集群上,适合生产环境,这个计算机集群被称为一个“集合体”(ensemble) Zookeeper通过复制来实现

CentOS7安装配置mysql5.7 tar免安装版

一、CentOS7.4系统自带mariadb # 查看系统自带的Mariadb[root@localhost~]# rpm -qa|grep mariadbmariadb-libs-5.5.44-2.el7.centos.x86_64# 卸载系统自带的Mariadb[root@localhost ~]# rpm -e --nodeps mariadb-libs-5.5.44-2.el7