剑起
众所周知，当前各个互联网企业采用的配置中心中，无外乎 Nacos 和 Apollo 最为知名。今天不去比较优劣，因为适合自己的才是最好的，而是在两个框架出现过渡时，有些用法或者编码习惯需要调整，否则配置文件就自己单飞了。
最近因为公司技术栈过渡原因，我们从 Nacos 转为 Apollo 作为配置中心，这期间原来为了从编码规范的习惯不少类采用ConfigurationProperties注解修饰，而在接入 Apollo 配置中心后，猛然发现@RefreshScope无法自动热更新，这无疑是致命的。
剑来
下面演示Nacos 迁移到 Apollo不生效的场景
@Component
@RefreshScope
@ConfigurationProperties(prefix = "elasticsearch.check")
public class EsCheckConfig {
// 迁移Apollo 后如果不做额外的配置 手动修改值是无法被感知的
private Integer flag;
}
分析： 采用 SpringCloud 原生注解@RfreshScope，迁移到 Apollo 后对自定义配置的控制权都完全丢失，所以丢失相应的功能也能理解；既然不是一个体系，也不必考虑太多。
正确的打开方式
- 完全之策
直接依赖 SpringBoot 原生的@Value 注解,而这注定有几个问题
1. 虽然同样解决了问题，好像大家都知道的完全之策，更像是废话
2. 可偏执的我们总想知道@ConfigurationProperties 这家伙能不能热更新。
3. 如果像我们在已经搭建的体系下，去使用@Value方式，必然耗费一番功夫，而且几乎需要走一遍所有用例，确保迁移正确。
- 他山之石-稳定版
import com.ctrip.framework.apollo.model.ConfigChange;
import com.ctrip.framework.apollo.model.ConfigChangeEvent;
import com.ctrip.framework.apollo.spring.annotation.ApolloConfigChangeListener;
import lombok.extern.slf4j.Slf4j;
import org.springframework.cloud.context.scope.refresh.RefreshScope;
import org.springframework.stereotype.Component;
import java.util.Set;
@Slf4j
@Component
public class ApolloConfig {
private final RefreshScope refreshScope;
private final EsCheckConfig esCheckConfig;
public ApolloConfig(RefreshScope refreshScope, EsCheckConfig esCheckConfig) {
this.refreshScope = refreshScope;
this.esCheckConfig = esCheckConfig;
}
@ApolloConfigChangeListener
private void someOnChange(ConfigChangeEvent changeEvent) {
// 这部分是为了解决ConfigurationProperties 无法获取 apollo 变动的日志
Set<String> changedKeys = changeEvent.changedKeys();
changedKeys.forEach(k -> {
ConfigChange change = changeEvent.getChange(k);
log.info(change.toString());
});
// apollo 自带的热刷新
refreshScope.refresh("esCheckConfig");
// refreshScope.refreshAll();
}
}
这下虽然满足了诉求，而这又带了几个问题【以下是戏精环节】
- 这 TMD 太离谱了，我那么多ConfigurationProperties 修饰的类，都要注入一遍？好，Apollo 还算良心，看到上面的注释了嘛，有了
refreshAll()
好像再也不需要注入所有的类，于是长呼一口气，等等 我草这玩意儿是不是没更新都会刷新一遍，Yes！但凡大中型企业的配置，没有上万也有上千。
- 还有个问题，这只能解决你当下服务的配置，那么多微服务如果不依赖一个公共的底层服务去处理，那也是掩耳盗铃。
哦，对了上面还有简陋版
区别在于refreshScope.refresh("esCheckConfig")底层也是使用了this.applicationContext.publishEvent 不同的是在 spring 的发布事件基础上加锁了，Apollo 开发者也是细腻和全面，不过有谁一天无聊的操作同一个配置呢？如果只有几个人维护的话用下面倒也未尝不可
public class ApolloConfig implements ApplicationContextAware {
private ApplicationContext applicationContext;
@ApolloConfigChangeListener
private void someOnChange(ConfigChangeEvent changeEvent) {
Set<String> changedKeys = changeEvent.changedKeys();
changedKeys.forEach(k -> {
ConfigChange change = changeEvent.getChange(k);
log.info(change.toString());
});
// 更新@ConfigurationProperties注解的bean
this.applicationContext.publishEvent(new EnvironmentChangeEvent(changedKeys));
}
}
所以，实际开发中该怎么做？笔者探寻一圈，难以两全，所以有了下文
剑魂
使用@Value一定没毛病的老铁哈哈哈，所以在你编码习惯上就应该有这样的意识，如果还在使用@ConfigurationProperties的老铁还是尽早悬崖勒马，否则早晚要陷入我等这样的困境，实在是想用，就要实时记得用apollo 自带的热更新去检查
当然了，如果像Redis、MySQL 的这样固定的配置，@ConfigurationProperties也是没毛病，当你要修改这些基础配置时，重启在所难免，
遗憾的是 SpringBoot 都集成了
还有，细心的童鞋应该还发现上面一段记录ConfigChangeEvent打印变更key 的先后信息，这个在使用@ConfigurationProperties避免带来的隐患，该注解修饰下的对象被 spring代理。
因此当你发生值变更的时候，what 你啥也感知不到，好像啥也没发生，这样的事情你允许在生产环境吗？所以使用@value吧，直到 SpringBoot 也能自带支持@ConfigurationProperties热更新那一天!
