所有代码都在github上:https://github.com/demonruin/cloud2020/tree/master
什么是总线
在微服务架构的系统中,通常会使用轻量级的消息代理来构建一个共用的消息主题, 并让系统中所有微服务实例都连接上来。由于该主题中产生的消息会被所有实例监听和消费,所以称它为消息总线。在总线上的各个实例,都可以方便地广播一些需要让其他连接在该主题上的实例都知道的消息。
基本原理
ConfigClient实例都监听MQ中同一个topic(默认是springCloudBus)。 当一个服务刷新数据的时候,它会把这个信息放入到Topic中,这样其它监听同一Topic的服务就能得到通知,然后去更新自身的配置。
- Spring Cloud Bus消息总线 是 分布式自动刷新配置功能
- Spring Cloud Bus配合Spring Cloud Config使用可以实现配置的动态刷新
- Spring Cloud Bus是用来将分布式系统的节点与轻量级消息系统链接起来的框架,它整合了Java的事件处理机制和消息中间件的功能。
- Spring Cloud Bus能管理和传播分布式系统间的消息,就像一个分布式执行器,可用于广播状态更改、事件推送等,也可以当作微服务间的通信通道
- Spring Cloud Bus目前支持两种消息代理:RabbitMQ和Kafka ,应用的是主题订阅功能topic
本文举例是通过RabbitMQ来实现的,至于rabbitmq的环境安装等请参考docker之rabbitmq安装及图形化界面文章~
Spring Cloud Bus 有两种设计思想:
1、利用消息总线触发一个客户端/bus/refresh,而刷新所有客户端的配置
从客户端去触发
2、利用消息总线触发一个服务端ConfigServer的/bus/refresh端点,而刷新所有客户端的配置(更加推荐)
图二的架构显然更加合适,图一不适合的原因如下:
- 打破了微服务的职责单一性,因为微服务本身是业务模块,它本不应该承担配置刷新职责
- 破坏了微服务各节点的对等性
- 有一定的局限性。例如,微服务在迁移时,它的网络地址常常会发生变化,此时如果想要做到自动刷新,那就会增加更多的修改
基于上面的理解,下面来进行消息总线的自动刷新全局广播的配置实现:
首先项目基于Spring Cloud Config配置中心的配置基础上,再进行添加消息总线的配置,需要准备的项目有configserver3344、configclient3355、configclient3366
自动刷新全局广播:
一、给cloud-config-center3344配置中心服务端添加消息总线支持
1、在pom文件中添加消息总线依赖,注意这里还需要actuator依赖
<!--消息总线 SpringCloud Bus-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>
2、在application.yml中添加配置,添加rabbitmq相关配置和management暴露bus刷新配置端点
server:
port: 3344
spring:
application:
name: cloud-config-center
cloud:
config:
server:
git:
# GitHub上面git仓库地址
uri: https://github.com/demonruin/springcloud-config #git仓库那个 https地址
# uri: git@github.com:demonruin/springcloud-config.git #ssh地址启动会报错,reject HostKey: github.com,所以使用https即可
# 搜索目录
search-paths:
- springcloud-config
#读取分支
label: master
#rabbitmq相关配置,此处一定注意rabbitmq是在spring下面的,不要顶格写配置,会报错
rabbitmq:
host: localhost
port: 5672
username: admin
password: admin
virtual-host: my_vhost #此处加上这个属性配置,要不有可能启动报io错误
eureka:
client:
#表示是否将自己注册进EurekaServer默认为true。
register-with-eureka: true
#是否从EurekaServer抓取已有的注册信息,默认为true。单节点无所谓,集群必须设置为true才能配合ribbon使用负载均衡
fetchRegistry: true
service-url:
#单机
defaultZone: http://localhost:7001/eureka
# 集群
#defaultZone: http://eureka7001.com:7001/eureka,http://eureka7002.com:7002/eureka,http://eureka7003.com:7003/eureka
#暴露监控端点 rabbitmq相关配置,暴露bus刷新配置的端点
management:
endpoints:
web:
exposure:
include: 'bus-refresh' #此处命名 bus-refresh,是同架构图第三步那个名称来的
二、给cloud-config-client3355配置中心客户端添加消息总线支持,因为3355和3366项目除了端口号其他代码都同样,所以就不在啰嗦一遍了,直接新建一个3366即可~,下面步骤也是在cloud-config-client3355的基础上添加的消息总线配置
1、pom添加依赖,同配置中心服务端依赖一样
<!--消息总线 SpringCloud Bus-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>
2、修改bootstrap.yml配置文件,添加rabbitmq相关配置
server:
port: 3355
spring:
application:
name: cloud-config-client
cloud:
#config 客户端配置
config:
label: master # 分支名称
name: config # 配置文件名称
profile: dev # 读取后缀名称 上述3个综合: master分支上config-dev.yml的配置文件被读取http://localhost:3344/master/config-dev.yml
uri: http://localhost:3344/ #配置中心地址
#rabbitmq相关配置,此处一定注意rabbitmq是在spring下面的,不要顶格写配置,会报错
rabbitmq:
host: localhost
port: 5672
username: admin
password: admin
virtual-host: my_vhost #此处加上这个属性配置,要不有可能启动报io错误
eureka:
client:
#表示是否将自己注册进EurekaServer默认为true。
register-with-eureka: true
#是否从EurekaServer抓取已有的注册信息,默认为true。单节点无所谓,集群必须设置为true才能配合ribbon使用负载均衡
fetchRegistry: true
service-url:
#单机
defaultZone: http://localhost:7001/eureka
# 集群
#defaultZone: http://eureka7001.com:7001/eureka,http://eureka7002.com:7002/eureka,http://eureka7003.com:7003/eureka
#暴露监控端点
management:
endpoints:
web:
exposure:
include: "*"
到此,消息总线的配置完成了,下面进行测试:
1、启动RabbitMQ、eureka7001、config-center3344、config-client3355、config-client3366项目
2、第一次请求3344能直接成功http://localhost:3344/config-dev.yml,请求3355和3366也能获取得到值http://localhost:3355/configInfo、http://localhost:3366/configInfo,说明配置中心没问题
3、修改github仓库的数值,再次请求3344能成功,3355和3366没有获取最新值,然后再通过发送POST请求,达到一次请求,处处生效效果 : curl -X POST "http://localhost:3344/actuator/bus-refresh" 请求
4、此时再去刷新3355和3366,已经能成功拿到最新的github值了,实现了一次修改,广播通知、处处生效
动态刷新定点通知:
上面写了 动态刷新 全局广播的功能,但是有时候可能不想全部通知,只想定点通知,比如我只想通知3355,不想通知3366,所以就需要用到我们的定点通知了。
此处其他的配置功能和全局广播的一样,只是在刷新的时候指定具体某一个实例生效而不是全部:
公式:http://localhost:配置中心的端口号/actuator/bus-refresh/{destination}
此处{destination}是指: 微服务名:端口号
/bus/refresh请求不再发送到具体的服务实例上,而是发给config server并通过destination参数类指定需要更新配置的服务或实例
下面我们进行测试:
1、修改github上的值,然后只通知3355,不通知3366,发送post请求,实现定点通知功能
curl -X POST "http://localhost:3344/actuator/bus-refresh/cloud-config-client:3355"
2、此时再去刷新3355已经能获取最新的值了,而刷新3366获取的还是旧值,表明动态刷新,定点通知已经生效
~~~~注意:定点通知虽然能实现定点通知的功能,但是此项是基于微服务不重启的前提下,如果微服务重启了,肯定会能获取的最新的github值的,这点要明白的~