Micronaut如何从分布式配置源运行时更新属性及关联配置类

你之前尝试的三种方案无效/有问题的核心原因如下：

• 直接发布RefreshEvent不生效：Spring Cloud 内置的刷新逻辑只会触发已注册到上下文的PropertySourceLocator重新拉取配置，你自定义的ConfigurationClient如果没有按Spring Cloud扩展规范注册为可刷新属性源，发事件不会触发配置重新加载。
• 直接在事件中手动设置属性键值不生效：@ConfigurationProperties标注的类是在Bean初始化阶段完成属性绑定的，仅修改Environment中的属性值，不会触发已初始化Bean的重新绑定逻辑。
• 全量调用ApplicationContext.refresh()导致服务无响应：这个方法会重载整个Spring容器，所有单例Bean都会被销毁重建，过程中请求处理线程会被阻塞，生产环境严禁直接调用。

正确的实现按以下步骤落地即可：

1. 封装可刷新的属性源加载器 #

将你已实现的ConfigurationClient加载逻辑封装为Spring Cloud标准的PropertySourceLocator，保证配置加载逻辑和Spring Cloud刷新生命周期对齐：

public class AzureAppConfigPropertySourceLocator implements PropertySourceLocator {
    private final ConfigurationClient azureConfigClient;

    public AzureAppConfigPropertySourceLocator(ConfigurationClient azureConfigClient) {
        this.azureConfigClient = azureConfigClient;
    }

    @Override
    public PropertySource<?> locate(Environment environment) {
        // 复用现有逻辑从Azure App Config拉取全量配置
        Map<String, Object> configMap = azureConfigClient.getConfigurationSettings().stream()
                .collect(Collectors.toMap(
                        ConfigurationSetting::getKey,
                        ConfigurationSetting::getValue,
                        (oldVal, newVal) -> newVal
                ));
        return new MapPropertySource("azureAppConfigSource", configMap);
    }
}

在bootstrap自动配置中注册这个Locator，保证引导阶段和刷新阶段都能调用到配置拉取逻辑。

2. 给需要动态更新的配置类标记刷新范围 #

所有需要运行时更新属性的@ConfigurationProperties类，必须添加@RefreshScope注解，这类Bean会被Spring托管为可刷新代理：

@Component
@ConfigurationProperties(prefix = "biz.config")
@RefreshScope
public class BizProperties {
    private String switchFlag;
    private Integer threshold;
    // 省略getter、setter
}

注意：不要全局给所有Bean加@RefreshScope，仅标记配置类、以及强依赖动态配置的业务Bean即可，减少不必要的Bean重建开销。

3. 用标准刷新器触发配置更新 #

收到Service Bus的配置变更通知时，不要手动发事件或者重载上下文，直接注入Spring Cloud内置的ContextRefresher，调用其refresh()方法即可：

@Component
public class ConfigChangeMessageListener {
    private final ContextRefresher contextRefresher;

    public ConfigChangeMessageListener(ContextRefresher contextRefresher) {
        this.contextRefresher = contextRefresher;
    }

    // 你的Service Bus消息监听逻辑
    @ServiceBusListener(topic = "config-change", subscription = "app-node")
    public void handleConfigChange(ServiceBusMessage message) {
        // refresh()方法会完成两个核心动作：
        // 1. 触发所有已注册的PropertySourceLocator重新拉取配置，更新Environment内的属性值
        // 2. 清空所有@RefreshScope标记的Bean缓存，下次这些Bean被调用时会重建、绑定最新配置
        Set<String> changedKeys = contextRefresher.refresh();
        // 可在此处打印变更的key列表，用于问题排查
    }
}

关键注意事项 #

• 刷新逻辑是轻量增量执行的，仅重建@RefreshScope标记的Bean，不会重载整个Spring上下文，不会阻塞正常业务请求，生产环境可用。
• 不要通过反射直接修改@ConfigurationProperties类的字段值，这种方式绕过Spring生命周期管理，很容易出现多实例属性不一致的问题。
• 如果普通业务Bean依赖了动态配置类，要么通过注入代理的方式获取最新值，要么给对应业务Bean也加上@RefreshScope，否则会一直持有初始化时的旧配置值。
• 如果直接使用官方提供的Spring Cloud Azure App Configuration Starter，上述逻辑已经被内置实现，只需要配置开启配置监听、配置对应Service Bus连接信息即可，不需要手动实现刷新逻辑。

内容的提问来源于stack exchange，提问作者LPal