在上一节中我们学习了在Spring Cloud微服务系统架构中使用Config Server进行本地仓库配置读取和线上环境的远程仓库git配置读取，让我们在多个微服务下也可以进行配置信息的集中管理。但是还有一个问题，那就是Config Server从git读取配置文件是项目启动的时候进行的，如果项目启动后我们修改了配置信息，那么服务还是使用原来的配置信息，想要修改的配置即时生效我们还需要重启服务项目进行手动刷新。为了解决这个问题，Spring Cloud提供了一些解决方式，例如，提供@RefreshScope注解可以实现配置修改之后自动刷新、提供Spring Cloud Bus消息总线配合Config Server进行多端配置的自动刷新。下面我们就来看看如何在Spring Cloud系统中实现配置的自动刷新。
1. 使用@RefreshScope实现配置刷新 在使用@RefreshScope之前我们先了解下这个注解。
对于@RefreshScope注解，官方是这样解释的：在被此注解修饰的范围中的所有Bean仅在首次访问时初始化，因此该范围强制使用延迟初始化（延迟加载）。
这个注解会为涉及作用域中的每个Bean创建一个代理对象。
如果一个Bean被刷新，那么下次访问该Bean（即执行一个方法）时，就会创建一个新实例。
所有生命周期方法都应用于Bean实例，因此在刷新时会调用在Bean工厂的销毁回调方法，然后在创建新实例时正常调用初始化回调，新的Bean实例是根据原始Bean定义创建的，因此任何外部化的内容（属性占位符或字符串文本中的表达式）在创建时都会重新计算。
上面的描述说明了该注解的工作原理，具体实现配置自动刷新的代码参考RefreshScope类、GenericScope类以及Scope接口的代码即可，这里就不展示了。
在Spring Cloud 2.0之前，我们只需要加入Actuator依赖，然后在使用的地方加上@RefreshScope注解就可以使用Spring Cloud 暴露的接口“/refresh”来刷新配置。
但是Spring Cloud 2.0之后，需要我们主动暴露Actuator的端点才可以。
接下来我们通过一个案例来使用@RefreshScope，具体步骤如下。
① 在服务config-client的pom.xml文件中加入Actuator依赖，如程序清单14-10所示。
并在使用配置的地方添加@RefreshScope注解，如程序清单14-11所示。
② 在application.yml或bootstrap.yml中，暴露Actuator的“refresh”端点信息，如程序清单14-12所示。
③ 进行测试。我们依次启动项目eureka-server、config-server、config-client。先在浏览器中访问“http://localhost:7031/config/getVersion”，查看配置信息，如图所示。
然后在远程git上修改配置信息mylog的version为V3.0.0，并通过Postman等工具使用POST请求访问“/actuator/refresh”，如图所示。
我们再次在浏览器中访问“http://localhost:7031/config/getVersion”，可以发现配置信息已经更新，如图所示。
然后在远程git上修改配置信息mylog的version为V3.0.0，并通过Postman等工具使用POST请求访问“/actuator/refresh”，如图所示。
然后在远程git上修改配置信息mylog的version为V3.0.0，并通过Postman等工具使用POST请求访问“/actuator/refresh”，如图所示。
我们发现使用@RefreshScope注解之后，不需要重启项目就可以从git获取最新配置，但是目前还是存在两个问题。
问题一：需要我们使用Postman等工具手动调用POST请求接口“/actuator/refresh”才能刷新配置。
问题二：每次调用/actuator/refresh接口只能通知一个Config Client进行刷新，要刷新所有的Config Client就需要一个一个地调用。
问题一的解决方法：手动调用接口来刷新的问题，我们可以很容易地解决，因为不管是开源的GitHub和Gitee还是自建的GitLab都提供了“WebHook”功能。
WebHook可以在我们修改git的文件的时候触发一个行为帮我们调用一个接口，这样就很好地解决了手动刷新的问题。
标签：配置,Spring,刷新,Bean,RefreshScope,Bus,Cloud From： https://www.cnblogs.com/cnetsa/p/16983003.html