我们在 springcloud(七):配置中心SVN实例和refresh 中讲到,如果需要客户端获取到最新的配置信息需要执行 Spring Cloud BusSpring cloud bus通过轻量消息代理连接各个分布的节点。这会用在广播状态的变化(例如配置变化)或者其他的消息指令。Spring bus的一个核心思想是通过分布式的启动器对spring boot应用进行扩展,也可以用来建立一个多个应用之间的通信频道。目前唯一实现的方式是用AMQP消息代理作为通道,同样特性的设置(有些取决于通道的设置)在更多通道的文档中。 Spring cloud bus被国内很多都翻译为消息总线,也挺形象的。大家可以将它理解为管理和传播所有分布式项目中的消息既可,其实本质是利用了MQ的广播机制在分布式的系统中传播消息,目前常用的有Kafka和RabbitMQ。利用bus的机制可以做很多的事情,其中配置中心客户端刷新就是典型的应用场景之一,我们用一张图来描述bus在配置中心使用的机制。 根据此图我们可以看出利用Spring Cloud Bus做配置更新的步骤:
项目示例我们选择上一篇文章springcloud(八):配置中心服务化和高可用版本的示例代码来改造,MQ我们使用RabbitMQ来做示例。 客户端spring-cloud-config-client改造 1、添加依赖
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-bus-amqp</artifactId> </dependency> 需要多引入 2、配置文件
## 刷新时,关闭安全验证 management.security.enabled=false ## 开启消息跟踪 spring.cloud.bus.trace.enabled=true spring.rabbitmq.host=192.168.9.89 spring.rabbitmq.port=5672 spring.rabbitmq.username=admin spring.rabbitmq.password=123456 配置文件需要增加RebbitMq的相关配置,这样客户端代码就改造完成了。 3、测试依次启动spring-cloud-eureka、spring-cloud-config-server、spring-cloud-config-client项目,在启动spring-cloud-config-client项目的时候我们会发现启动日志会输出这样的一条记录。
2017-05-26 17:05:38.568 INFO 21924 --- [ main] o.s.b.a.e.mvc.EndpointHandlerMapping : Mapped "{[/bus/refresh],methods=[POST]}" onto public void org.springframework.cloud.bus.endpoint.RefreshBusEndpoint.refresh(java.lang.String) 说明客户端已经具备了消息总线通知的能力了,为了更好的模拟消息总线的效果,我们更改客户端spring-cloud-config-client项目的端口为8003、8004依次启动,这样测试环境就准备好了。启动后eureka后台效果图如下: 我们先分别测试一下服务端和客户端是否正确运行,访问: { "name": "neo-config", "profiles": [ "dev" ], "label": null, "version": null, "state": null, "propertySources": [ { "name": "https://github.com/ityouknow/spring-cloud-starter/config-repo/neo-config-dev.properties", "source": { "neo.hello": "hello im dev" } } ] } 说明server端都正常读取到了配置信息。 依次访问: 现在我们更新
执行完成后,依次访问:
改进版本在上面的流程中,我们已经到达了利用消息总线触发一个客户端
因此我们将上面的架构模式稍微改变一下 这时Spring Cloud Bus做配置更新步骤如下:
这样的话我们在server端的代码做一些改动,来支持 1、添加依赖<dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-config-server</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-bus-amqp</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-eureka</artifactId> </dependency> </dependencies> 需要多引入 2、配置文件server: port: 8001 spring: application: name: spring-cloud-config-server cloud: config: server: git: uri: https://github.com/ityouknow/spring-cloud-starter/ # 配置git仓库的地址 search-paths: config-repo # git仓库地址下的相对地址,可以配置多个,用,分割。 username: username # git仓库的账号 password: password # git仓库的密码 rabbitmq: host: 192.168.0.6 port: 5672 username: admin password: 123456 eureka: client: serviceUrl: defaultZone: http://localhost:8000/eureka/ ## 注册中心eurka地址 management: security: enabled: false 配置文件增加RebbitMq的相关配置,关闭安全验证。这样server端代码就改造完成了。 3、测试依次启动spring-cloud-eureka、spring-cloud-config-server、spring-cloud-config-client项目,改动spring-cloud-config-client项目端口为8003、8004依次启动。测试环境准备完成。 按照上面的测试方式,访问server端和三个客户端测试均可以正确返回信息。同样修改
执行完成后,依次访问:
其它局部刷新某些场景下(例如灰度发布),我们可能只想刷新部分微服务的配置,此时可通过 例如: destination参数也可以用来定位特定的微服务。例如: 跟踪总线事件一些场景下,我们可能希望知道Spring Cloud Bus事件传播的细节。此时,我们可以跟踪总线事件(RemoteApplicationEvent的子类都是总线事件)。 跟踪总线事件非常简单,只需设置 { "timestamp": 1495851419032, "info": { "signal": "spring.cloud.bus.ack", "type": "RefreshRemoteApplicationEvent", "id": "c4d374b7-58ea-4928-a312-31984def293b", "origin": "stores:8002", "destination": "*:**" } }, { "timestamp": 1495851419033, "info": { "signal": "spring.cloud.bus.sent", "type": "RefreshRemoteApplicationEvent", "id": "c4d374b7-58ea-4928-a312-31984def293b", "origin": "spring-cloud-config-client:8001", "destination": "*:**" } }, { "timestamp": 1495851422175, "info": { "signal": "spring.cloud.bus.ack", "type": "RefreshRemoteApplicationEvent", "id": "c4d374b7-58ea-4928-a312-31984def293b", "origin": "customers:8001", "destination": "*:**" } } 这个日志显示了 这样,我们就可清晰地知道事件的传播细节。
|
|