前言

为什么这个时候要写个这个文章呢，事件的起因完全是因为一点神奇的操作，大致经过是这样的，现在所在的公司是一个正转java的公司，既然转java了，那DDD是否要落地？落地了DDD是否要落地微服务？那么故事的开始就来了。

从结构上划分，一个完整的微服务解决方案至少包含以下几个方面：配置中心、服务注册与发现、网关路由、统一鉴权、链路追踪、熔断限流、分布式事务、消息队列等，问题的关键就在于我们的架构师终于引入了nacos的服务以后，很开心的告诉我们要统一使用nacos作为配置中心，然后很神奇的说了句，这个nacos的配置更新可以不重启服务直接生效。

当时因为陷于业务开发，既然有了这样的公共设施用就用吧（以前都是用的apollo）,所以对于架构的声明是有点疑问的，毕竟就算你nacos再牛逼也不能在spring boot的框架下做到不符合框架的事情吧？？至少在我使用apollo的时候也知道，配置中心的client是可以及时更新本地配置，要生效也是借助于@RefreshScope，相关原理也是基于框架的可刷新Bean，但是看架构师的样子，好像不需要自己怎么处理就可以生效，那么问题的关键肯定在我或者架构师都不知道的地方生效了，废话不多说，咱直接开始demo验证。

启动Nacos服务

此处为了方便，直接使用了Docker部署的模式，参考文档见Nacos官网。

创建demo项目

相关技术	版本
java	11
spring boot	2.6.4
spring cloud	2021.0.1
spring-cloud-starter-alibaba-nacos	2021.0.1.0

为了排除所有其他影响，依赖里面遵循最小原则法:

nacos配置：

测试用的代码：

初始结果：

第一步，我们现在更改nacos中的配置：

可以看到我们的程序中会有一个通知：

此时结果：

通过以上结果，这时候我就觉得很正确了，毕竟在我的理解中，spring boot支持的自动更新本身是基于更新事件的刷新，本质上就是对已加载的bean进行重新生成覆盖的更新，对于未进行@RefreshScope修饰的对象是不会生成可更新的代理对象的，因此直接@Value注入的对象的属性并没有随着配置中心的更新而更新。

好，效果已经处理了，那么是什么原因让我们的架构师如此笃定的认为配置是自动更新的，但是却不说任何附加条件呢？

我们来看下架构师展示的场景：

场景其实很简单，就是我们在使用日志组件的时候，经常会出现的一种情况就是，我们需要在生产环境排查问题，这个时候怎么办呢？按照规范，为了排查问题我们会写很多的Debug日志输出，但是在上线以后，这些日志输出不应该打印Debug级别，默认的就是info级别的日志(甚至为了问题的聚焦，有些组织会只打印Error级别的日志)，这个时候排查问题就需要一个不需要重启，然后答应Debug级别的日志。

所以在上面的例子中，如果我们现在需要排查问题了，我们改了nacos中的配置:

此时再去请求接口的时候：

当然直到这里，其实如果使用的是自带的日志框架的情况下，就算没有了解这么细，同样和架构师说的话是没有问题的，但是以上效果之所以能成功，完成是因为日志组件中使用的注入方式：

所以所谓的配置自动更新其实并不是nacos的功劳，他所理解的自动更新，只是nacos在客户端的情况下，能够与服务端保持一种类似订阅更新事件的状态，当服务端更改配置以后，客户端会刷新本地配置，然后通过spring boot的刷新事件，进行更新操作：

为此，为了不弄错，我专门又去看了我以前用的apollo配置：

可以看出，此处的实现与nacos反而不一样，此处的更新实现反而是对于bean生命周期创建过程的处理。

所以到了这里就可以明白了，nacos并不能直接刷新配置，其还是借助了spring boot的架构（这些设计师是真的强大），而为什么会写这篇文章呢？？因为后来有个小同志在使用的时候，想改了个配置，然后在群里艾特架构师说咋没生效，可能经过了10几分钟，架构师又去看了下文档？然后姗姗来迟的说了句：你要加@RefreshScope才行。

可能真的是我对架构的期望过高了？还是我们的架构其实没有去深入落地？现在真的是很反感PPT架构师，没有落过地，甚至没有自己验证过的技术方案都能拿出来进行宣讲，然后出了问题就解决不了，甚至自己都不知道为啥，现在的架构师这么好当嘛？？？