Spring Cloud Chapter 12. | Bus Message Bus

This article is Spring Cloud column Chapter 12. articles about before eleven article content contribute to a better understanding of the article:

  1. Spring Cloud first post | Spring Cloud Foreword and common components Glance

  2. The second Spring Cloud | use and understanding of Eureka registry

  3. Spring Cloud Part III | Eureka registration center set up high availability

  4. Spring Cloud Part IV | Client load balancing Ribbon

  5. Spring Cloud Part V | Services blown Hystrix

  6. Spring Cloud Part VI | Hystrix Hystrix Dashboard dashboard monitor

  7. Spring Cloud VII | declarative service call Feign

  8. Spring Cloud Part VIII | Hystrix cluster monitor Turbin

  9. Spring Cloud Chapter 9. | distributed service tracking Sleuth

  10. Spring Cloud Tenth Canto | Distributed Configuration Center Config

  11. Spring Cloud Chapter 11. | distributed high-availability configuration center

I. Introduction

    Since when do not use the message bus, if we need to modify a configuration, if it involves modified micro-service node more, we need to manually refresh a node of a node is very troublesome, in the micro-services architecture system, we usually uses lightweight message broker to build a common theme to make micro-news service instance all systems are connected up, because the message that topic will be generated in all instances of listening and consumption, so we call it the message bus. Each instance on the bus can easily broadcast a number of other instances need to make the connection on the subject are aware of the news, for example, or some other configuration change management and other operational information.

    Since the message bus service is widely used in micro-architecture system, so it is the same configuration as the center, almost micro-services architecture prerequisites. Spring Cloud as a micro-service architecture integrated solutions, which naturally have their own achieve by using Spring Cloud Bus can be easily erected message bus, while achieving some news bus commonly used functions, such as with the Spring Cloud Config dynamically updates the widget service application configuration information and the like, as shown in FIG architecture:    

    The current version, Spring Cloud Bus supports only two middleware products, RabbitMQ and Kafka, in this case using RabbitMQ achieve Spring Cloud Bus Application

    RabbitMQ installation procedure and the use of self-Baidu it. . .

Second, the integration of message bus bus

1, modify previous springcloud-config-server, springcloud-config-client message block added bus dependent, dependent Actuator first few cases have been introduced in the parent module (springcloud-learn), the need to introduce here again

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

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

3、在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"]

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

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

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

RabbitMQ的Topic模式如图所示:

如果不懂RabbitMQ的话也不影响你的Bus使用

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

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

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

7、我们在复制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"]

8、码云仓库值默认如下

访问http://localhost:8881/index

访问http://localhost:8882/index

9、修改仓库内容

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

10、再次访问客户端8881,882显示如下

三、指定刷新范围

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

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

    In addition to the destination parameter may be positioned outside of a specific example, it can also be used to locate a particular service. The principle of location-based services is through the use of Spring PathMatecher (path matching) to achieve, such as / actuator / bus-refresh / springcloud-config-client: **, the request triggers all instances of customers service to refresh.

1, before the warehouse information:

For example: modified as follows

2, the http: // localhost: 8888 / actuator / bus-refresh / springcloud-config-client: 8882 send a POST request

3, 8881,8882 access client services as follows

IV Summary

    Use / actuator / bus-refresh is sent to one of our config-client also can refresh configuration (provided that the bus-refresh endpoint of the client's needs exposed), but this is just another instance of this instance is not the same, it additional It assumes the function of refresh configuration. So, we will send a request to refresh the post configuration tasks handed over config-server configuration service center to handle, so that all service instances are equal, the message sent by the configuration notification message bus service center to update the entire cluster configuration. In this way, a service instance will not have to undertake the task trigger configuration updates. As far as possible so that each node in the cluster service is conducive to such future operation and maintenance work.

 

Detailed reference case Source: https://gitee.com/coding-farmer/spirngcloud-learn

 

Guess you like

Origin www.cnblogs.com/coding-farmer/p/12080563.html