在8.1节,我测试了配置中心的手动刷新。但是问题是每个配置中心的使用者都需要执行一下refresh。
如果使用者节点特别多,也不不能一个个的去refresh。
所以我们可以考虑有一个组件,可以管理所有使用者的refresh端点,执行一次刷新,所有的使用者节点都能执行刷新操作。
Springcloud已经实现了这个功能,如下:
各个配置中心的使用者都通过消息总线接收消息。在一个使用者节点上(如图ServiceA-3)上执行/bus/refresh操作。
会像消息总线发送更新配置消息。其他节点(ServiceA-1,ServiceA-2)接收到消息,也会重新拉取新的配置内容。
需要使用到消息中间件 kafka。搭建步骤请看:
config server项目
1,项目增加依赖
org.springframework.boot spring-boot-starter-actuator org.springframework.cloud spring-cloud-starter-bus-kafka
2,配置
server: port: 8888spring: 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:9092management: endpoints: web: exposure: include: "*" security: enabled: false #是否需要权限拉去,默认是true,如果不false就不允许你去拉取配置中心Server更新的内容
主要就是配置kafka的地址,正常生产环境一般是3节点集群,以逗号隔开就好了
然后暴露下端点,我直接用了*
3,启动
- /actuator/refresh :刷新单个节点
- /actuator/bus-refresh: 刷新所有节点
节点使用者:
继续使用Ribbon项目测试,
先增加bus-kafka的依赖
org.springframework.cloud spring-cloud-starter-bus-kafka
修改配置文件
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建议了解下。