前言
现在的分布式系统中,通常会使用一个中间件作为配置中心,目的是实现在多服务器集群的场景下,只需要统一修改配置中心的配置文件,然后所有的服务器全部获取配置中心最新的配置文件信息,服务器不用重新启动,即可以在所有的服务器上面生效。要想实现这个功能,它的原理大概如下:
场景1:服务器首次启动-->获取配置中心最新的配置-->然后实例化bean,并根据配置文件信息初始化bean的所有的属性。这个场景很好理解,那些原本配置在本地的配置文件,也就是这样使用的,只不过配置中心的配置,需要远程获取一下。
场景2:配置中心配置信息修改->通知服务器获取最新的配置-->获取到最新的配置后,销毁所有的bean-->重新实例化所有的bean,然后根据最新的配置文件信息初始化所有的bean属性。这个过程就是SpringCloud框架,给我们实现的配置中心动态加载(刷新)配置文件。
注:下面所说的Spring框架包含:Spring FrameWork,Spring Boot,Spring Cloud。
Spring框架实现
在Spring框架中是这样实现的。
1.在类上加@RefreshScope注解。
2.在属性中引入@Value注解
3.手动调用刷新http://localhost:8080/refresh,我猜想这个接口会触发销毁所有注解了@RefreshScope注解的bean,然后再后续使用bean的时候在实例化,初始化。因为没有看源码,我猜想是这个原理。
![c094bb39f4d879fcdace3f07295399db.png](https://i-blog.csdnimg.cn/blog_migrate/2ac8247cabae17634a10362daa085174.jpeg)
新版本中需要引入actuator,并添加如下的配置,来暴露refresh接口。
![fa51b7d041d8974089725971d9e99527.png](https://i-blog.csdnimg.cn/blog_migrate/dd1dcb39f84b6be70984e3814135091a.jpeg)
![932882ea442fa42ba38f9456f0bbb60d.png](https://i-blog.csdnimg.cn/blog_migrate/ce8d19def2dac97689e92f8f637fc99e.jpeg)
源码分析
来看一下调用过程。
@Endpoint(id = "refresh")public class RefreshEndpoint { private ContextRefresher contextRefresher; public RefreshEndpoint(ContextRefresher contextRefresher) { this.contextRefresher = contextRefresher; } @WriteOperation public Collection refresh() { //refresh方法最终会调用此逻辑 Set keys = this.contextRefresher.refresh(); //实际调用ContextRefresher去做的刷新逻辑 return keys; }}//this.contextRefresher.refresh();方法public synchronized Set refresh() {Set keys = refreshEnvironment();this.scope.refreshAll();//实际调用这个方法去刷新return keys;}//this.scope.refreshAll();方法@ManagedOperation(description = "Dispose of the current instance of all beans "+ "in this scope and force a refresh on next method execution.")public void refreshAll() {super.destroy();//销毁所有的beanthis.context.publishEvent(new RefreshScopeRefreshedEvent());//发布刷新事件}
我自己的疑惑是:
我用zookeeper作为配置中心,我发现我在zookeeper上面修改了配置信息,在应用程序中自动就生效了,因为没有找到源码,我猜想是Spring框架最终底层是调用了refreshAll()方法,但是我发现对象是没有被重新实例化的,因为通过IDE调试时,对象的编码还是和以前一样,如下图。
![c805f91ddf6e0627f74cf1ac77811e39.png](https://i-blog.csdnimg.cn/blog_migrate/8221a710fe8e9e74f050f29c53bd4429.jpeg)
带着这个疑惑,继续看源码中...
后续:
1.当修改zookeeper配置中心的配置时,RefreshEventListener监听器会被触发,部分 源码如下:
private ContextRefresher refresh;public void handle(RefreshEvent event) { if (this.ready.get()) { // don't handle events before app is ready log.debug("Event received " + event.getEventDesc()); Set keys = this.refresh.refresh(); //实际调用ContextRefresher去做的刷新逻辑, //与手动调用 最终触发的逻辑是一样的。 log.info("Refresh keys changed: " + keys); }}
在ContextRefresher方法中会触发配置信息刷新的逻辑,部分源码如下:
public synchronized Set refreshEnvironment() { Map before = extract( this.context.getEnvironment().getPropertySources()); addConfigFilesToEnvironment(); //这个逻辑会触发重新去zookeeper获取最新的配置信息 Set keys = changes(before, extract(this.context.getEnvironment().getPropertySources())).keySet(); this.context.publishEvent(new EnvironmentChangeEvent(this.context, keys)); return keys;//返回值是value值改变了的key集合}