The Config in the previous section solves the problem of complex configuration files, but it has a drawback, that is, when the server-side code is modified, that is, things in Gitee are modified, the service needs to be started again before the modification can take effect.

In order to solve this problem, SpringCloud has introduced BUS. For those of you who have studied networking, this article is the final chapter in the SpringCloud introductory series.

The introduction of Bus

Build an empty parent BUS module, modify the POM file of the parent module, import the corresponding dependencies for the use of its child modules.

<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-bus-amqp</artifactId>
    </dependency>

    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-config</artifactId>
    </dependency>
</dependencies>

When I see spring-cloud-starter-bus-amqp, I know that I need RabbitMQ. In practice, I usually use Docker with WSL2, download the RabbitMQ image and open it. Everyone can show their own skills, but it will be ok to download it anyway.

To determine whether the download was successful, just visit http://localhost:15672 and the following screen will be successful

The user name and password are both “guest”. After logging in, you will see the following interface

A bus-config-client9601 sub-module is first established under the bus parent module.

The configuration file

Get content from the server, so it is necessary to set the relevant content of the server, that is, spring.cloud.config.xxx, and also set the relevant content of Bus, RabbitMQ, Actuator, Eureka, etc. The final configuration file is as follows:

server.port: 9601 spring: application: name: bus-config-client cloud: config: profile: dev label: master uri: http://localhost:8101 # server address: # enable bus enabled: true trace enabled: true rabbitMQ: # set rabbitMQ information Cone endpoints: Web: Exposure: Include: Cone endpoints: Web: Exposure: Include: Eureka client: fetch-registry: true register-with-eureka: true service-url: defaultZone: http://localhost:8001/eureka/ instance: instance-id: bus-config-client9601

All other configuration files are obtained directly from the server via conifg

But since we are a different project, we need to create a bus-config-client-dev.properties file in the Gitee repository.

Again, the configuration file name: {spring.application.name}-{profile}

The main start class

The main startup class is still relatively simple

@SpringBootApplication @EnableEurekaclient @RestController @RefreshScope public class BusConconfigClient9601 {@SpringBootApplication @EnableEurekaclient @RestController @RefreshScope @Value("${name}") private String name; public static void main(String[] args) { SpringApplication.run(BusConfigClient9601.class, args); } @getMapping ("/get") public String getName() {return "hello, "+ name; }}

test

Start with a simple test by opening the Eurekaserver8001 service, ConfigServer8101 service, BusConfigClient9601[9602(by modifying the startup class configuration file)] service

Go to localhost:9601/ GET, modify the configuration file in Gitee, and then send the POST request

http://localhost:9601/actuator/bus-refresh, visit the get interface again.

The re-read of the file can also be clearly seen in the IDEA control panel interface

In order to refresh

The refresh just now is actually a refresh of all the clients on the main line, but because of the relatively few projects can not reflect, so create a new BusClient9701 submodule.

The main startup classes and configuration files are not much to say. They are basically copies of the BusConconfigClient9601 module

server.port: 9701
spring:
  application:
    name: bus-client
  cloud:
    config:
      profile: dev
      label: master
      uri: http://localhost:8101
    bus:
      enabled: true
      trace:
        enabled: true
  rabbitmq:
    host: localhost
    port: 5672
    username: guest
    password: guest
management:
  endpoints:
    web:
      exposure:
        include: bus-refresh

#eureka:
#  client:
#    fetch-registry: true
#    register-with-eureka: true
#    service-url:
#      defaultZone: http://localhost:8001/eureka/
#  instance:
#    instance-id: bus-client9701

Comment out eureka-related items here to show that the refresh of config has nothing to do with eureka

@SpringBootApplication @EnableEurekaclient @RestController @RefreshScope // public class BusClient9701 { @Value("${name}") private String name; public static void main(String[] args) { SpringApplication.run(BusClient9701.class, args); } @GetMapping("/get") public String getName() { return "hello, " + name; }}

You can refresh the specified microservice by using http://[IP address :port number]/ Actuator /bus-refresh/[spring.application.nema microservice name]

Any microservice on the bus can be refreshed, that is
ip:portThere are no restrictions

Leaving the microservice opened above intact, open a new BusClient9701 service, which will eventually open as follows

Since the configuration file and then access the port to see the results of the GIF diagram is relatively large, here look at the IDEA console results can be.

The output on BusClient9701 in the console may report errors or warnings because Eureka was not registered, but was introduced.

Refresh of all bus service, send a post request at http://localhost:9701/actuator/bus-refresh. You can see that all the microservices get the server resources again.

Refresh the bus of the specified name service, send a post request to refresh the name http://localhost:9701/actuator/bus-refresh/bus-config-client for bus – config – client services. You can see that only the bus-config-client microservice gets the server’s resources again.

Refresh a specific port on a microservice, Send a post request to http://localhost:9701/actuator/bus-refresh/bus-config-client:9602 to refresh the name for the bus – config – micro service of client service of port is 9602. You can see that only the microservice named bus-config-client with port 9602 will get the server’s resources again.

Again, the above refreshed URL can be refreshed as long as it is a micro service on the bus.
ip:portThere are no restrictions

http://localhost:9701/actuator/bus-refresh/bus-config-client:9602 and http://localhost:9601/actuator/bus-refresh/bus-config-client:9602 The effect of (http://localhost:9602/actuator/bus-refresh/bus-config-client:9602) is the same.

This is the end of SpringCloud’s introductory series. It’s not easy to create SpringCloud. If you have any help, please feel free to share your SpringCloud collection.

The following is a personal public number, interested can pay attention to, perhaps is your treasure public number oh, basic 2,3 days 1 more technical articles!!