Spring Cloud第十二篇 | 消息总线Bus

​本文是Spring Cloud专栏的第十二篇文章,了解前十一篇文章内容有助于更好的理解本文:html

  1. Spring Cloud第一篇 | Spring Cloud前言及其经常使用组件介绍概览git

  2. Spring Cloud第二篇 | 使用并认识Eureka注册中心web

  3. Spring Cloud第三篇 | 搭建高可用Eureka注册中心spring

  4. Spring Cloud第四篇 | 客户端负载均衡Ribbonbootstrap

  5. Spring Cloud第五篇 | 服务熔断Hystrix架构

  6. Spring Cloud第六篇 | Hystrix仪表盘监控Hystrix Dashboardapp

  7. Spring Cloud第七篇 | 声明式服务调用Feign负载均衡

  8. Spring Cloud第八篇 | Hystrix集群监控Turbin运维

  9. Spring Cloud第九篇 | 分布式服务跟踪Sleuth分布式

  10. Spring Cloud第十篇 | 分布式配置中心Config

  11. Spring Cloud第十一篇 | 分布式配置中心高可用

1、前言

    因为在没有使用消息总线的时候,咱们若是须要修改某个配置,若是涉及修改的微服务节点比较多,咱们须要手动的一个节点一个节点的刷新很是麻烦,在微服务架构的系统中,咱们一般会使用轻量级的消息代理来构建一个共用的消息主题让系统中全部微服务实例都链接上来,因为该主题中产生的消息会被全部实例监听和消费,因此咱们称它为消息总线。在总线上的各个实例均可以方便地广播一些须要让其余链接在该主题上的实例都知道的消息,例如配置信息的变动或者其余一些管理操做等。

    因为消息总线在微服务架构系统中被普遍使用,因此它同配置中心同样,几乎是微服务架构中的必备组件。Spring Cloud做为微服务架构综合性的解决方案,对此天然也有本身的实现,经过使用Spring Cloud Bus能够很是容易地搭建起消息总线,同时实现了一些消息总线中的经常使用功能,好比配合Spring Cloud Config实现微服务应用配置信息的动态更新等,架构如图所示:    

    目前版本,Spring Cloud Bus仅支持两款中间件产品,RabbitMQ和Kafka,本案例使用RabbitMQ实现Spring Cloud Bus的应用

    RabbitMQ安装步骤以及使用自行百度啦。。。

2、整合消息总线bus

一、修改之前的springcloud-config-server,springcloud-config-client块添加消息总线依赖,actuator依赖在前几篇案例中已经在父模块(springcloud-learn)中引入,此处不须要再次引入

<!--spring cloud bus 整合rabbitmq -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>

二、rabbitmq服务地址:http://47.112.11.147:15672/  rabbitmq用户名为:admin密码为:123456

三、在springcloud-config-server模块基础上往application.yml添加bus和rabbitmq的相关配置以及暴露bus-refresh端点

spring: cloud: bus: #控制bus消息总线是否能用 enabled: true #打开bus追踪 trace: enabled: true rabbitmq: addresses: 47.112.11.147 port: 5672 username: admin password: 123456 virtual-host: / management: endpoints: web: exposure: include: ["info","health","bus-refresh"]

四、在springcloud-config-client模块基础上往application.yml添加rabbitmq相关配置就好了

spring: rabbitmq: addresses: 47.112.11.147 port: 5672 username: admin password: 123456 virtual-host: /

五、启动配置中心服务端(springcloud-config-server)查看bus相应的转换器Exchange以及Type对应的topic,而且同时在控制台上经过日志能够看到bus-refresh端点暴露出来了

RabbitMQ的Topic模式如图所示:

若是不懂RabbitMQ的话也不影响你的Bus使用

查看rabbitmq控制台看到bus相应对列建立了

查看绑定关系,springcloud bus相应对列已经绑定到了springcloud bus转换器上了

六、启动配置中心客户端(springcloud-config-client)能够看到该对列也绑定到spirngcloud bus转换器上了

七、咱们在复制springcloud-config-client的配置,新建文件bootstrap-configclient8882.yml配置文件以下,创键启动类启动SpringcloudConfigClient8882Application

server: port: 8882 spring: application: name: springcloud-config-client cloud: config: #uri则表示配置中心的地址 #uri: http://localhost:8888 #注:config 客户端在没有 spring.cloud.config.name属性的时候,服务端{application} 获取的是客户端 #spring.application.name的值,不然,获取的是 spring.cloud.config.name的值。 #1)、当没有spring.cloud.config.name时,客户端获取的是spring.application.name 所对应的git库中的文件,而且只能 #获取一个文件, #2)、当一个项目中有需求要获取多个文件时,就须要用到spring.cloud.config.name这个属性,以逗号分割 name: configclient profile: dev #label对应了label部分 label: master # username: coding-farmer # password: 123456 discovery: #表示开启经过服务名来访问config-server enabled: true #则表示config-server的服务名 service-id: springcloud-config-server #失败快速响应 fail-fast: true retry: #配置重试次数,默认为6 max-attempts: 6 #初始重试间隔时间,默认1000ms initial-interval: 1000 #间隔乘数,默认1.1 multiplier: 1.1 #最大间隔时间,默认2000ms max-interval: 2000 rabbitmq: addresses: 47.112.11.147 port: 5672 username: admin password: 123456 virtual-host: / eureka: client: service-url: defaultZone: http://localhost:8700/eureka #客户端每隔30秒从Eureka服务上更新一次服务信息 registry-fetch-interval-seconds: 30 #须要将个人服务注册到eureka上 register-with-eureka: true #须要检索服务 fetch-registry: true #心跳检测检测与续约时间 instance: #告诉服务端,若是我10s以内没有给你发心跳,就表明我故障了,将我剔除掉,默认90s #Eureka服务端在收到最后一次心跳以后等待的时间上限,单位为秒,超过则剔除(客户端告诉服务端按照此规则等待本身) lease-expiration-duration-in-seconds: 10 #每隔2s向服务端发送一次心跳,证实自已依然活着,默认30s #Eureka客户端向服务端发送心跳的时间间隔,单位为秒(客户端告诉服务端本身会按照该规则) lease-renewal-interval-in-seconds: 2 # 启用ip配置 这样在注册中心列表中看见的是以ip+端口呈现的 prefer-ip-address: true # 实例名称 最后呈现地址:ip:2002 instance-id: ${spring.cloud.client.ip-address}:${server.port} management: endpoints: web: exposure: include: ["info","health","refresh"]

八、码云仓库值默认以下

访问http://localhost:8881/index

访问http://localhost:8882/index

九、修改仓库内容

而后向springcloud-config-server服务bus-refresh端点发送POST请求http://localhost:8888/actuator/bus-refresh

十、再次访问客户端8881,882显示以下

3、指定刷新范围

    在上面案例中咱们看到当你触发/actuator/bus-refresh端点时,它就会刷新全部实例的服务配置,有时候咱们可能只须要刷新某个具体的实例。

    Spring Cloud Bus对这种场景也有很好的支持,/actuator/bus-refresh/{destination}接口提供了一个destination参数,RESTFUL风格请求,用来定位具体要刷新的应用程序。好比:咱们能够请求/actuator/bus-refresh/springcloud-config-client:8882,此时总线上的各应用实例会根据destination属性的值来判断是否为本身的实例名,若符合才进行配置刷新,若不符合就忽略该消息。

    destination参数除了能够定位具体的实例以外,还能够用来定位具体的服务。定位服务的原理是经过使用Spring的PathMatecher(路径匹配)来实现的,好比/actuator/bus-refresh/springcloud-config-client:**,该请求会触发customers服务的全部实例进行刷新。

一、之前仓库信息为:

例如:修改成以下

二、向http://localhost:8888/actuator/bus-refresh/springcloud-config-client:8882发送POST请求

三、访问客户端8881,8882服务内容以下

4、总结

    使用/actuator/bus-refresh发送到咱们其中一个config-client中也能刷新配置(前提是该客户端的bus-refresh端点须要暴露出来),可是这样这个实例就跟其余实例不同了,它还额外承担了刷新配置的功能。因此,咱们将发送post请求刷新配置的任务交由config-server配置服务中心来处理,这样全部服务实例都是对等的,由配置服务中心发送消息通知消息总线更新整个集群中的配置。这样,服务实例就不须要再承担触发配置更新的任务。尽量让服务集群中的各个节点是对等的未来利于运维工做。

 

详细参考案例源码:https://gitee.com/coding-farmer/springcloud-learn

 

原文出处:https://www.cnblogs.com/coding-farmer/p/12080563.html

相关文章
相关标签/搜索