Apollo/Nacos选型

热更新

Apollo
在属性上直接加@value注解，这个属性就会随着配置的更改动态更新
类实现ConfigChangeListener，在类中方法上@ApolloConfigChangeListener注解，注解在方法上，监控配置的变化，配置变化后会自定义方法来达到动态刷新bean的目的
Nacos
Nacos无需任何配置，即可对有@ConfigurationProperties注解的类进行配置的动态刷新
Nacos自2022.0.0.0-RC1版本后可通过spring.cloud.nacos.config.refresh-bahavior指定刷新模式，默认是all_beans(刷新所有bean)，可选specific_bean (只刷新有配置值更改的bean)

apollo

优势

提供出listener,使用者可灵活自行定制bean的刷新方式

劣势

apollo除@Value注解不提供动态刷新的默认实现方案，而@Value注解平常用的较少，就比较鸡肋，用户想要用@ConfigurationProperties配置类的方式动态刷新，必须要自己去实现

Nacos

优势

• 有动态刷新的默认实现，用户可直接使用，且从2022.0.0.0-RC1版本后可自选bean的刷新模式

劣势

不管选用哪种nacos的刷新方案，RefreshScope域都会全刷新，触发RefreshScopeRefreshedEvent事件的发布，如eureka会订阅该事件，并于该事件发布时，触发eurekaClient的重新注册，若是配置热更新的比较频繁，那么会触发eurekaClient的频繁重注册

动态热更新的时候，肯定是更新哪个配置，那么只将与这个配置对应的bean进行更新最好，若是用的nacos,那么可选用2022.0.0.0-RC1版本，bean的刷新行为选用specific_bean指定刷新，若是用的Apollo，需自己实现，也可参考nacos中的SmartConfigurationPropertiesRebinder类，进行自实现，配置动态刷新后，建议还是要发布下RefreshScopeRefreshedEvent事件，使得依赖该事件发布的其他组件，在配置刷新后，可重新配置与该之相关的的内容，避免真的更改了例如eureka的配置后，eureka因不能重注册client导致的配置无法生效的问题。这里比较坑的地方就是springcloud没有提供一种机制，可监听自己的配置更改及事件发布对应着触发事件，进行导致只是更改了用户自定义的一些配置也触发了eureka客户端重注册这种看似风马牛不相及的行为出现

对比

灰度发布：

发布新版本应用时，为了保证应用不中断，老版本不停机的同时，启动新版本，并对新版本的流量做控制，同时搜集新版本的运行情况，甚至对新版本做自动化测试，新版本测试无误之后，再将用户流量一点一点导入到新版本上，如果发现异常，应该能够快速切换为老版本 。

对比：

从配置中心角度来看，性能方面Nacos的读写性能最高，Apollo次之，Spring Cloud Confifig依赖Git场景不适合开 放的大规模自动化运维API。功能方面Apollo最为完善，nacos具有Apollo大部分配置管理功能，而Spring Cloud Confifig不带运维管理界面，需要自行开发。Nacos的一大优势是整合了注册中心、配置中心功能，部署和操作相比 Apollo都要直观简单，因此它简化了架构复杂度，并减轻运维及部署工作