SpringCloud 详解配置刷新的原理

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/believer123/article/details/78411312

首先先介绍下实现后的效果：
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

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

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

    @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是从构造方法传入的。

    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接口

    @Bean
    @ConditionalOnBean(RefreshEndpoint.class)
    public MvcEndpoint refreshMvcEndpoint(RefreshEndpoint endpoint) {
        return new GenericPostableMvcEndpoint(endpoint);
    }

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

    @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()方法，这里就是核心了

    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源码：

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

---