消息总线(Bus)
Spring Cloud Bus
将分布式系统的节点与轻量级消息代理链接。可以用于通知状态更改(例如配置更改)或其他管理指令。一个关键的地方是,Bus
就像一个分布式执行器,用于扩展的Spring Boot
应用程序,同时还可以用作应用程序之间的通信通道…
- Bus
Spring Cloud Bus
是通过添加Spring Boot自动配置(Auto Configuration),如果它在class path
中被检测到,则可以工作。所有启用Spring Cloud Bus
的都需要添加spring-cloud-starter-bus-amqp
或spring-cloud-starter-bus-kafka
依赖管理,并且Spring Cloud负责其余部分。确保代理(RabbitMQ或Kafka)可用和配置:在本地主机上运行,您不应该做任何事情,但如果您远程运行使用Spring Cloud连接器或Spring Boot定义经纪人凭据的约定,例如Rabbit
官方文档:http://cloud.spring.io/spring-cloud-static/Dalston.SR2/#_spring_cloud_bus
- RabbitMQ搭建
RabbitMQ搭建:http://blog.battcn.com/2017/08/20/linux/linux-centos7-ribbitmq/
- 开始
1.拷贝battcn-cloud-config
代码进行改造,其中battcn-config-server
不需要动
2.pom.xml
导入AMQP包
1 |
<dependencies> |
3.添加@RefreshScope
注解
1 |
@RestController |
4.给battcn-config-client
配置rabbitmq
信息
1 |
server: |
- 测试
1.启动consul
2.启动battcn-config-server
和battcn-config-client
3.访问:http://localhost:9001/test 会看到如下内容,表示服正常
1 |
client ====>>> My Name's Order Service,Are you Afraid? |
4.修改battcn-config-server
中config-server-order-default.yml
文件的内容
1 |
order: |
5.只重启battcn-config-server
同时发送POST
请求:http://localhost:9001/bus/refresh 通知服务刷新配置
6.再次访问:http://localhost:9001/test 会看到如下内容,表示服正常
1 |
client ====>>> My Name's Order Service,Are you Afraid?123 |
battcn-config-server
日志
1 |
2017-08-21 20:45:09.048 INFO 11420 --- [nio-9000-exec-3] o.s.cloud.commons.util.InetUtils : Cannot determine local hostname |
battcn-config-client
日志
1 |
2017-08-21 20:45:54.896 INFO 16768 --- [nio-9001-exec-8] s.c.a.AnnotationConfigApplicationContext : Refreshing org.springframework.context.annotation.AnnotationConfigApplicationContext@7dc4513: startup date [Mon Aug 21 20:45:54 CST 2017]; root of context hierarchy |
通过日志可以分析出,battcn-config-server
重新加载了classpath:/config-server-order-default.yml
文件,并且客户端重新读取了[name='configService', propertySources=[MapPropertySource [name='classpath:/config-server-order-default.yml']]]
,有兴趣的可以DEBUG
源码看详细的处理过程…
- 疑问解答
-
在测试第四步中,之所以修改
yaml
后重启,是因为我们的config
是本地的而不是GIT
仓库,所以项目没法加载,但是这种方式即使关闭了config
,调用过的服务依旧是可以正常使用的,包括旧的配置依旧正常读取使用,Config做了本地缓存 -
博客只演示了一个
battcn-config-client
的情况,多个client
其实效果一样只需要刷新其中一个,剩下的都会跟着刷新,比如battcn-config-client
启动了3个实例,分别是9001,9002,9003
,访问:http://localhost:9001/bus/refresh,三个实例的结果都是一样
- 刷新范围
上面的例子中,我们通过向服务实例请求Spring Cloud Bus
的/bus/refresh
接口,从而触发总线上其他服务实例的/refresh
。但是有些特殊场景下(比如:灰度发布),我们希望可以刷新微服务中某个具体实例的配置。
Spring Cloud Bus
对这种场景也有很好的支持:/bus/refresh
接口还提供了destination
参数,用来定位具体要刷新的应用程序。比如,我们可以请求/bus/refresh?destination=customers:9000
,此时总线上的各应用实例会根据destination
属性的值来判断是否为自己的实例名,若符合才进行配置刷新,若不符合就忽略该消息。
destination
参数除了可以定位具体的实例之外,还可以用来定位具体的服务。定位服务的原理是通过使用Spring
的PathMatecher
(路径匹配)来实现,比如:/bus/refresh?destination=customers:**
(以冒号的路径分隔符:)来确定一个实例是否处理该消息,该配置的请求会触发customers
服务的所有实例进行刷新。
- 优化方案
既然访问任意端口都可以通知全部实例,那么我们利用刷新范围的方式,将battcn-config-server
也添加上spring-cloud-starter-bus-amqp
和 rabbitmq
的配置信息,访问:http://localhost:9000/bus/refresh?destination=battcn-config-client:** 结果一样,battcn-config-client
依然会去读取最新配置
主要做了这些改动:
1.在Config Server中也引入Spring Cloud Bus,将配置服务端也加入到消息总线中来。
2./bus/refresh
请求不在发送到具体服务实例上,而是发送给Config Server,并通过destination参数来指定需要更新配置的服务或实例。
参考博客:http://blog.didispace.com/springcloud7/
