这篇文章接着手动刷新配置中心的那篇。
1 、不带profile的情况下：
SpringCloud Bus+WebHooks(web端的一个自动推送的一个通知，相当于是一个钩子，让请求路径交给它来回调执行)+ribbatMQ
1.1、加入依赖：
1.2、然后启动下项目cloud-config:这里就有监控的路径了。这时就可以启动webHook了
1.3、由于是生产环境，在局域网里面把它发布到外网上面是不行的，所以要用到内网穿透的配置。把内网映射到外网 在访问就可以了。
参考网址：https://natapp.cn/article/natapp_newbie
1.4、这个端口号需要修改和config-provider中的应该是一样的。
1.5、下面的就是内网穿透的网址了
这样访问的结果也是一样的。
1.6、在gitee里面配置webhook
1.7、这里需要加moniter，实现实时检测和监控的。
然后提交
2.0、这种情况是不带profile的情况，重启项目cloud-provider
2.1、更新下git上面的provider.yml的文件
这里返回的结果是provider，因为它请求的就是provider这个文件，返回的结果也是它。
配置服务的后台有刷新了：
然后配置服务的客户端也就是cloud-provider不用重启，在去访问，这时就可以不用重启cloud-provider的服务，就能够自动得到最新的配置信息了。
2、如果带有profile的话，现在没有好的办法，必须手动去刷新配置，也就是参考手动刷新配置中心的那篇文章。
总结：1、一开始如果远程上的git配置信息，不发生变化的时候，是没有rabbitMQ和bus的。当启动config的时候会向远程的git拉取数据，然后保存到本地的临时的git仓库里面来。然后配置中心的客户端去本地的临时文件中去获取信息。
2、一旦git上的配置信息如果发生更新的话，比如原来的名字是张三，现在改为李四了。在SpringCloud中提供了SpringCloud Bus 与RabbitMQ 当启动配置服务会主动向ribbatiMQ主动去写一条数据，就是创建一条队列出来，而客户端启动的时候也会主动去创建一个队列，这个队列创建起来是放消息的。通过actuator/bus-refresh这样的映射路径向我们配置的队列里面configQueue写入一条消息，这条信息是由客户端订阅端来订阅的。很多的客户端来订阅的。一对多订阅的过程中发现这里有消息了，就会发送一条通知过来，就有刷新的通知，只要订阅了这个通知的所有的订阅者都会接收这个消息，在这个queue里面是有一个时间的，当时间过期的话，可能就消费不了了，因为不可能让消息堆积起来。并且消息队列本来就存在消息堆积的过程 。这些消息就会给当前对应的客户端去异步的方式消费这条消息，当发送这个消息的同时就会同时的去消费了。在其实有一个RefreshXXXEvvent事件。触发这个事件，还有一个标识@RefreshScope标注的内容才会去被局部刷新。
3、webhook(钩子 git的功能）的作用只是相当于远端的git更新的时候会自动回调actuator/bus-refresh这个地址，自动去调用这个地址当你配置的内容发生变化的时候就会触发这个事件从而回调这个地址actuator/bus-refresh。
