当微服务及其实例增长的时候,配置文件也随之变多。有一个想法就是将多个配置文件进行统一管理,而每个微服务只是从配置中心获取自己的配置文件。spring config 就为我们提供了这样一个机制。允许我们有一个统一的配置中心。配置中心本身作为一个服务,其本身的配置文件里需要定义仓库地址。如下
server:
port: 3355
spring:
application:
name: cloud-config-center #注册进eureka服务器的微服务名
cloud:
config:
server:
git:
uri: git@github.com:InAHurry/spring-cloud-config.git
search-paths:
- spring-cloud-config
skip-ssl-validation: true
label: master
rabbitmq:
host: 192.168.56.7
port: 5672
username: guest
password: guest
eureka:
client:
register-with-eureka: true
fetch-registry: true
service-url:
defaultZone: http://peer1:7001/eureka,http://peer1:7002/eureka
#配置刷新端点
management:
endpoint:
bus-refresh:
enabled: true
endpoints:
web:
exposure:
include: 'bus-refresh'
该服务作为配置中心server端,其他服务作为client端,所以client应该写明自己从哪里获取配置,即其配置信息类似如下:
server:
port: 3344
eureka:
client:
fetch-registry: true
register-with-eureka: true
service-url:
defaultZone: http://peer1:7001/eureka,http://peer2:7002/eureka
spring:
application:
name: config-client
cloud:
config:
label: master
name: spring-cloud-config
profile: dev
uri: http://localhost:3355 #配置中心地址
rabbitmq:
host: 192.168.56.7
port: 5672
username: guest
password: guest
management:
endpoints:
web:
exposure:
include: "*"
那么我们在github仓库中修改了配置文件之后如何使得所有客户端都能拿到最新配置信息呢?比较好的做法是利用spring bus 来进行完成相关功能。spring bus 用于各分布式系统之间的信息交互,支持rabbitmq和kafuka来进行消息传递。rabbitmq高可用 数据安全。kafuka高吞吐 高并发。rabbitmq 官网上有多种实例应用。基本都是以 生产者 -服务端队列-消费者 来展开,有发布订阅、woker queues、routing 、top(动态路由)、以及rpc等模型。在springcloud 广播所有客户端配置使用的是topic 模型,即其exchange(交换机)类型是topic。通过对exchange申明不同的关键字,客户端便可以将队列绑定同样的关键字,即可收到信息。
由于有了总线支持,则当修改了git repository中的配置文件之后,在给config server发送一个post resfresh请求后,个客户端即可主动从配置中心获取最新配置。post refresh 请求一般为curl -X http:localhost:配置中心的端口号/actuator/bus-refresh ,对于只想更新部分微服务的配置文件,则只需要后面加上其微服务名称:端口号即可 例如curl -X http:localhost:配置中心的端口号/actuator/bus-refresh/需要更新的微服务名称:端口号