在8.1节，我测试了配置中心的手动刷新。但是问题是每个配置中心的使用者都需要执行一下refresh。

如果使用者节点特别多，也不不能一个个的去refresh。

所以我们可以考虑有一个组件，可以管理所有使用者的refresh端点，执行一次刷新，所有的使用者节点都能执行刷新操作。

Springcloud已经实现了这个功能，如下：

各个配置中心的使用者都通过消息总线接收消息。在一个使用者节点上（如图ServiceA-3）上执行/bus/refresh操作。

会像消息总线发送更新配置消息。其他节点（ServiceA-1，ServiceA-2）接收到消息，也会重新拉取新的配置内容。

需要使用到消息中间件 kafka。搭建步骤请看：

config server项目

1，项目增加依赖

 <dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-actuator</artifactId>
 </dependency>
	<!-- kafka依赖 -->
 <dependency>
 <groupId>org.springframework.cloud</groupId>
 <artifactId>spring-cloud-starter-bus-kafka</artifactId>
 </dependency>

2，配置

server:
 port: 8888
spring:
 application:
 name: config-server
 cloud:
 config:
 server:
 git:
 uri: https://github.com/jedyang/springcloud_learn
 username:
 password:
 stream:
 kafka:
 binder:
 brokers: x.x.x.x:9092
management:
 endpoints:
 web:
 exposure:
 include: "*"
 security:
 enabled: false #是否需要权限拉去，默认是true,如果不false就不允许你去拉取配置中心Server更新的内容

主要就是配置kafka的地址，正常生产环境一般是3节点集群，以逗号隔开就好了

然后暴露下端点，我直接用了*

3，启动

• /actuator/refresh ：刷新单个节点
• /actuator/bus-refresh: 刷新所有节点

节点使用者：

继续使用Ribbon项目测试，

先增加bus-kafka的依赖

 <dependency>
 <groupId>org.springframework.cloud</groupId>
 <artifactId>spring-cloud-starter-bus-kafka</artifactId>
 </dependency>

修改配置文件

spring:
 application:
 name: ribbon-consumer
 cloud:
 stream:
 default-binder: kafka
 kafka:
 binder:
 brokers: x.x.x.x:9092

主要修改点配置kafka地址

因为是要测试批量刷新。所以我们修改一下配置文件，再多启动一个服务

通过配置profile的方式，分别启动两个使用配置中心的ribbon消费者引用

测试

先分别测试一下：

好，现在两个应用都是返回的当前配置参数：1.1.1.1:3306:test:newconfig

然后，修改一下配置

spring.jdbc.password = bustest

先用/actuator/refresh单个刷新一下试试

先只在8781上单点刷新

分别查看

分别查看，发现8781已经是新的配置，而8783还是以前的配置，没有更新

现在，再改一下配置

spring.jdbc.password = bustest2

现在在8781上使用bus-refresh

可以看到，两个应用都得到了新的配置

看一下日志，两个应用都是解注册和重新注册的过程

这样，还是有一点不方便的是，不能够自动刷新。

其实解决这个问题也简单，就是利用github或gitlab上的webhook功能，可以配置在代码push时，触发一些地址的回调。

将你的bus-refresh地址填到回调地址里就好。

感觉这个不是很实用。这里配置的触发条件太宽松了，还是自己手动刷新一下好了。

总结：

批量刷新功能，主要就是需要接入一个消息中间件。目前可以选择的是kafka和rabbitmq。

引入依赖，加一下配置。还是比较简单的。

但是每次刷新一个配置，会使应用从注册中心进行一次下线重新注册流程。怀疑这里面会有坑，如果此时有大流量的请求过来，可能会有问题。我们在生产环境的业务代码不使用SpringCloud的配置中心，而是选择专门的配置中心中间件，百度的disconf、携程的apollo建议了解下。