首先先介绍下实现后的效果:
1、在需要动态配置属性的类上添加注解@RefreshScope表示此类Scope为refresh类型的
2、启动工程,修改config-server对应的配置文件,这里修改的是system.order.serverName
3、以post的方式调用refresh接口,返回修改后的key值
4、访问infoTest接口,可以看到修改后的值

详细流程:

依次启动config-server,eureka-server后,再启动订单服务order-service,首先访问http://localhost:8100/infoTest 查看serverName的值:

然后修改config-server工程下的order-service-dev.properties中的system.order.serverName为Order Service modified,通过postman使用POST的方式调用refresh接口,可以看到返回了修改的属性的key,继续访问http://localhost:8100/infoTest 显示新的数据如下:

可以看到对应的属性值已经变化了。


基本使用演示完了,下面该对属性刷新原理进行详细探究:
1、先从基本入口refresh接口入手,在项目启动时可以看到log

1
Mapped "{[/refresh || /refresh.json],methods=[POST]}" onto public java.lang.Object org.springframework.cloud.endpoint.GenericPostableMvcEndpoint.invoke()

可以知道refresh对应的handler是GenericPostableMvcEndpoint的invoke方法
2、继续进入GenericPostableMvcEndpoint看invoke源码:

1
2
3
4
5
6
7
8
9
10
@RequestMapping(method = RequestMethod.POST)
@ResponseBody
@Override
public Object invoke() {
if (!getDelegate().isEnabled()) {
return new ResponseEntity<>(Collections.singletonMap(
"message", "This endpoint is disabled"), HttpStatus.NOT_FOUND);
}
return super.invoke();
}

非常简单,直接调用父类的invoke方法,继续跟进到AbstractEndpointMvcAdapter类,发现最后调用的是delegate的invoke方法,而且delegate是从构造方法传入的。

1
2
3
4
5
6
7
protected Object invoke() {
if (!this.delegate.isEnabled()) {
// Shouldn't happen - shouldn't be registered when delegate's disabled
return getDisabledResponse();
}
return this.delegate.invoke();
}

3、步骤2可以看出最终调用的是对应泛型的invoke方法,那么找到注入refresh接口的地方,通过查询哪里使用到此类,查找到LifecycleMvcEndpointAutoConfiguration,通过refreshMvcEndpoint方法注入了refresh接口

1
2
3
4
5
@Bean
@ConditionalOnBean(RefreshEndpoint.class)
public MvcEndpoint refreshMvcEndpoint(RefreshEndpoint endpoint) {
return new GenericPostableMvcEndpoint(endpoint);
}

4、可以那么GenericPostableMvcEndpoint中的delegate就是RefreshEndpoint,转至研究RefreshEndpoint

1
2
3
4
5
6
7
8
9
10
@ManagedOperation
public String[] refresh() {
Set<String> keys = contextRefresher.refresh();
return keys.toArray(new String[keys.size()]);
}

@Override
public Collection<String> invoke() {
return Arrays.asList(refresh());
}

发现invoke方法很简单,只是返回一个修改过的属性key的集合对象。核心方法contextRefresher.refresh()

5、跟进到contextRefresher.refresh()方法,这里就是核心了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public synchronized Set<String> refresh() {
//获取目前系统的配置
Map<String, Object> before = extract(
this.context.getEnvironment().getPropertySources());
//获取最新配置
addConfigFilesToEnvironment();
//对比目前系统配置和最新配置,返回修改后的属性
Set<String> keys = changes(before,
extract(this.context.getEnvironment().getPropertySources())).keySet();
//通知系统配置变更
this.context.publishEvent(new EnvironmentChangeEvent(keys));
//对应的bean刷新
this.scope.refreshAll();
return keys;
}

6、核心就是获取最新的配置,那么是如何获取的呢?之前
还以为是通过直接调用config配置加载呢,那么继续看addConfigFilesToEnvironment源码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
private void addConfigFilesToEnvironment() {
ConfigurableApplicationContext capture = null;
try {
StandardEnvironment environment = copyEnvironment(
this.context.getEnvironment());
//这里就是核心了,启动SpringBoot环境
SpringApplicationBuilder builder = new SpringApplicationBuilder(Empty.class)
.bannerMode(Mode.OFF).web(false).environment(environment);
// Just the listeners that affect the environment (e.g. excluding logging
// listener because it has side effects)
builder.application()
.setListeners(Arrays.asList(new BootstrapApplicationListener(),
new ConfigFileApplicationListener()));
capture = builder.run();
if (environment.getPropertySources().contains(REFRESH_ARGS_PROPERTY_SOURCE)) {
environment.getPropertySources().remove(REFRESH_ARGS_PROPERTY_SOURCE);
}
MutablePropertySources target = this.context.getEnvironment()
.getPropertySources();
String targetName = null;
for (PropertySource<?> source : environment.getPropertySources()) {
String name = source.getName();
if (target.contains(name)) {
targetName = name;
}
if (!this.standardSources.contains(name)) {
if (target.contains(name)) {
target.replace(name, source);
}
else {
if (targetName != null) {
target.addAfter(targetName, source);
}
else {
if (target.contains("defaultProperties")) {
target.addBefore("defaultProperties", source);
}
else {
target.addLast(source);
}
}
}
}
}
}
finally {
ConfigurableApplicationContext closeable = capture;
closeable.close();
}

}

通过以上代码可知,刷新不是我之前想象的直接调用config获取最新配置的,而是通过重新创建一个SpringBoot环境(非WEB),等到SpringBoot环境启动时就相当于重新启动了一个非web版的服务器。此时config会自动加载到最新的配置。这个过程类似于启动服务器。
等到服务器启动成功后,获取到最新的配置,然后跟原来的配置进行对比,返回修改过的key值。

7、获取到修改后的配置后,发出EnvironmentChangeEvent事件,ConfigurationPropertiesRebinder监听了此事件,调用rebind方法进行配置重新加载

8、this.scope.refreshAll();首先销毁scope为refresh的bean。然后发出RefreshScopeRefreshedEvent事件,通知bean生命周期已经变更,已知两个类EurekaDiscoveryClientConfiguration.EurekaClientConfigurationRefresher接收了此事件,EurekaClientConfigurationRefresher接收到此事件后,进行对eureka服务器重连的操作。


总结:通过以上步骤,配置刷新基本流程就是再起一个SpringBoot环境,加载最新配置,与目前环境配置对应,筛选出变化后的属性,将scope类型为refresh的bean销毁。等到下一次获取时bean时重新装配bean,这样最新配置就注入ok了。具体其他细节自己Debug就行了。


本文中的代码已提交至: https://gitee.com/cmlbeliever/springcloud 欢迎Star